A Faster whatIs
Tue, 3 Dec 2002 23:24:14 +0200
> I toyed with changing whatIs a few years ago. Instead of your
> table-based approach, I was thinking of using a bitwise encoding. My
> idea was to use one bit to select int/not int and that everything else
> would be interpreted as a triple of the form:
Alastair, as far as I can see, your bit-field approach is really the way to
go. It would add small efficiencies in lots of places, and it just
generally makes sense on the 32 bit word size we now use. I suppose
we need someone who is both qualified and has time for this
kind of thing (probably a group of zero) to bite the bullet and
(a) figure out if it is worth the effort and (b) actually make the changes.
I have scratched my brain considering other ways the execution
machine could be optimized (within the same basic architecture).
Mark (et al) really seem to have made every machine cycle count. It
really is quite a pleasure seeing how the damn thing has been so
streamlined. Perhaps a C-- backend could be directed to do more
intelligent register dragging than the MSC C compiler; a GLOBALfst on
machines other than 68Ks. But I am speculating...
On a more down to earth note, it is not clear to me if the changes I
made are worth integrating into the code, for the 10% speed increase
they give. I'll leave it up to Sigbjorn's judgment.
Oh, one more thing: if the following line was removed and "memory"
was statically allocated, we would gain a little speed (on x86
architectures anyway). Since NUM_ADDRS is fixed and can't be changed
by the user, there appears to be no down side to making this change.
machine.c: memory = (Memory)farCalloc(NUM_ADDRS,...
Thanks for your interest, and thanks to the others who responded to
my original email.