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:
(WhatisTag,ModuleId,Index) ...
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. ---- Stephen Milborrow