I see what you mean. I've become entangled in instruction set differences, with the effect that it makes my remarks inaccurate if not unintelligible.

Unfortunately, there's no easy way to express low-level details such as what I wanted to express in processor-independent pseudocode. My decision to express this notion in 805x assembly language was definitely a poor choice, particularly in light of the fact I was thinking in terms of a totally different processor core. My illustration is, indeed, misleading to those unfamiliar with the underlying concept. Those not so unfamiliar with the concept would likely be confused by the choice to express it as I did.

The reason I picked the 6502, back in the early '80's, was the ability to use a table, to which I pointed with a "zero page" location, with 128 indirect addresses and pre-indexed to the appropriate vector. This allowed me to implement the sequence, "examine inputs, take appropriate action" in a two-instruction dispatch loop, taking less than 2 microseconds at 4.9152 MHz. The 12 MHz 805x, even with the expanded table size, would have taken considerably longer.

Indirect addressing, and particularly indexed indirect or indirect indexed (the distinction being pre- or post- indexing) addressing are powerful features in an instruction set. That's one of the things that made the 650x processors so popular back in the '70's, as it enabled code to be written both smaller and faster than with other, similar, architectures such as MC68xx.

That's not practical in the 805x instruction set, though the basic notion of fetching an address from a table is possible, though either much slower or requiring a somewhat larger table. It would require a table of 128 LJMP instructions, or 384 bytes.

The fact that so few processor cores support this addressing mode is sad, but remains a reality even today. Architectures designed in the day of limited on-chip memory were not often equipped with the facilities supporting the use of tables in this way because it was not perceived as the most efficient way to use what then was a scarce resource, namely on-chip code space. IIRC, the first monolithic CPU to support this addressing mode was the 68000, and it suffered from the fact that its instructions were so long that, with its 16-bit data bus, it required two cycles for each long word fetch, which made many tasks slower than on an 8-bit processor.

That's one weakness inherent in 32 and 16-bit RISC architectures. If you want to operate on a dense table of 8-bit values, you have to isolate each value before you can do that. Now, memory costs almost nothing these days, but time is still at a premium. If only there were a way to ignore 8, 16, or 24 bits of a data object without using extra time ...

RE