HP-41 Byte Table

[JurgenRo]

(12-27-2018 08:31 PM)Thomas Okken Wrote:  The HP-41C/CV/CX and 42S store the offset from a GTO or XEQ instruction to its target LBL in the GTO / XEQ instruction. When the GTO or XEQ is first entered into a program, the offset is initially set to zero, meaning "unknown"; when the instruction is executed for the first time, a label search is performed, just like on older programmable HPs, and when the label is found, the difference between its address and the address of the GTO or XEQ is stored in said GTO or XEQ. Any subsequent time the instruction is executed, it can find the label instantly by adding the stored offset to the current instruction's address.

In order to store these offsets, GTO and XEQ need to take up some more space than other instructions with parameters. In the case of GTO 00 through GTO 14, one byte is added, giving an 8-bit offset, and thus a limited range, in exchange for taking up little memory. GTO 15-99, A-J, a-e, and all local XEQ instructions, have one and a half extra bytes, giving a 12-bit offset, enough even for the largest programs. Those twelve extra bits are stored by using four bits in the opcode byte, and and additional byte used entirely for the offset. The four bits in the opcode byte are why you end up with 16 local GTO opcodes and 16 local XEQ opcodes.

Hi Thomas, Sylvain! Thanks for your inputs. But I'm aware of the compilation process you explained. But this does not explain why there are for example 16 identical "XEQ --" in the Byte-Table, namely E0, E1, E2, E3, ..., EE, EF. Each of those functions have identical properties, each of which will carry the same jump distance after compilation. Actually, my question is: is there a difference between an XEQ coded by, say, E0 02 AD and E7 02 AD (note that both carry the identical jump distance information just the occurence in byte table row E differs). Thanks again!