The Sinclair ZX81 (Z80-based) could do 16 bit arithmetic fine but it had a similar interpreted mechanism for floating point, called the Calculator Stack.<p>You used the single byte RST 28 Z80 instruction followed by opcodes in the special interpreted language, with opcode 34h meaning exit back to Z80 code.<p>The interpreter opcodes were quite powerful, including trigonometric, logarithms, string parsing and memory operations. As the name "Calculator Stack" implies the operands were stored on a stack in memory (persisting between invocations of the interpreter). However a downside was it was very slow - visible pauses when doing certain artithmetic operations.<p>(More here: <a href="http://www.users.waitrose.com/~thunor/mmcoyzx81/chapter17.html" rel="nofollow">http://www.users.waitrose.com/~thunor/mmcoyzx81/chapter17.ht...</a> )
Regarding the opcode dispatch: setting up the RTS in this way is quite expensive, and (if you've got the room) you could be better off assembling a little thunk somewher in memory. 4C 00 >SET (JMP >SET*256). You'd do this on startup.<p>A JMP to this thunk costs 3 cycles, and the JMP in the thunk costs 3 cycles, so that buys you nothing compared to the RTS. And the STx to set up the low byte takes up 3 cycles (zero page) or 4 cycles (elsewhere), which is the same or worse than the PHA. But because the high byte is always set up, you save the 5 cycles spent setting that up.<p>(If you're running from RAM, you don't even need the thunk.)<p>(Also: the opcode dispatch's EOR trick is space-efficient, but takes an extra cycle - and one fewer bytes, I won't deny - compared to doing a TAY after fetching the byte, then a TYA:AND $F0 later. That sequence takes 6 cycles, whereas the LSR:EOR (R15L),Y sequence takes 7 or 8.)
> FOLLOWING CODE MUST BE CONTAINED ON A SINGLE PAGE!<p>(Page == 256 byte block). Because the op dispatch table stores only the low-order byte of the opcode address; the high order byte is fixed in the interpreter. I think the last function could spill past the end of the page; its starting address just has to be in the page.
From the title and URL, I mistakenly thought this was about the Sweet16 Apple IIgs emulator (for macOS) getting an update. That would have been nice, because it's a 32 bit only app and so won't work past macOS 10.14 Mojave. :(