Some sort of low-level pseudo-code would have been a better vehicle, I think, but what I was getting at is the basic concept. It's really very much a "computed go-to" though the computation is done entirely within the table-lookup.

Back in the days of microprocessors, I used a 65C02 to do this in terminals and link encryptors. From there, I loaded an index (probably X) with the port content and used a JMP @TABLE,X which is somewhat more convenient than using the accumulator, since you could then pass a parameter, if necessary, in A without disturbing anything. Since the only thing unique to each vector in the table was the offset, and since that was the product of the state input, it really wouldn't matter.

Producing an actual working example would require more effort than I'm willing to put into this discussison. After all, taking ASCII characters in a video terminal environment as an example, it would require construction of the 256-byte table, each word of which would then have to contain an address specific to the character used as the offset, namely [A], into it. I don't believe I have the old 6502 code I used back in the '80's any longer, though that would probably work. Using that example would, however, require detailed explanation of what each non-displayed character meant and how it was processed.

Consider, though, that each table entry corresponding to a displayable character would point to a single routine, the result of which would be to write [A] to the display memory, which would then be transferred, in hardware, through a character generator, to the pixel-wise display logic. Characters that required other specific action, e.g, control-S or control-Q, would require their own unique processing code. Further, the table would probably be pretty large, as there were, in my 6502 terminal case, IIRC, several layers of the dispatch table, as various processing contexts demanded. The input, after all, came from a keyboard encoder.

The basic concept, however, remains very simple, in that it loads an offset into an index, then jumps via a table indexed by the 7-bit left-justified (LSB=0) input byte. It's difficult to imagine anything simpler. Each subsequent routine must end in an absolute jump to the primary dispatch loop, hence the process results in no net stack usage. There's many a slip 'twixt cup and lip, though, in that it's quite conceivable that the routines to which the table dispatches control could, indeed use some stack. However, since the table is, in each case, one page (256 bytes) in size, direction to another page, as required by context, is easily handled by modifying the upper byte of the pointer to the table base.

The tables can become large and manifold, but the underlying concept is very simple. The code is very simple, too. The table(s) must be constructed in the coding process, and those can become large, but the code itself is straightforward and fast, and, of course, easy to debug.

RE