Threaded Mode | Linear Mode

JurgenRo · 12-27-2018, 07:54 PM

I'm currently re-reading the famous "Synthetic Programming on the HP-41C/CV" by W.C. Wickes. In chapter "2B. The Byte Table", p. 14, the author spots the oddities of the table starting with row B. For example as for row E he asks " Why are there 16 different XEQ prefixes". Unfortunately he does not give a satisfactory answer for those. Moreover, in chapter "2C. Register, Please", p. 17, in the routine (2C-2) the "XEQ 45" is coded starting with the Byte E0. But again, he does not give an explanation why the processor codes this "XEQ" starting with byte E0 but not with on of the bytes E1, E2, ... EF, which actually seem to me as suitable as the E0 byte. Can anyone of the Masters of the 41 (SP) explain the system behind the 16 GTOs, EXQs ... please?
Thank you and Best Wishes,
Juergen

Thomas Okken · 12-27-2018, 08:31 PM

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.

Sylvain Cote · 12-27-2018, 09:02 PM

Great explanation Thomas!

You can find here HP explanation published in the Corvallis Division Column of the PPC Journal V6 N5 P.20 & 21 August 1979 : HERE

JurgenRo · 12-27-2018, 09:05 PM

(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!

JurgenRo · (This post was last modified: 12-27-2018 09:19 PM by JurgenRo.)

(12-27-2018 09:05 PM)JurgenRo Wrote:
(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!

... especially, I'm thinking of constructing those by synthetic means. By SP, as far as I understand SP, I would have the choice to construct the XEQ by 16 means: E0, E1, ...., EE, EF. So, the question arises: which one of those 16 should I construct? ;-)Or is there no difference between those at all? And, aditionally, by which rules does the processor chose on of those "XEG--" ... I hope you understand my point Undecided

Thomas Okken · 12-27-2018, 09:18 PM

They don't carry the same jump distance. That low nybble of the opcode is part of the offset!

If you construct a GTO or XEQ with an incorrect offset, the instruction will jump to an incorrect location, and undesired behavior will most likely result. You should construct your GTO and XEQ instructions with their offsets set to zero, and let the calculator find the label and calculate the offset when it first executes the code.

(I guess you do want pre-compiled offsets when you're generating code for use in ROMs, but I've never dealt with that.)

JurgenRo · (This post was last modified: 12-27-2018 09:25 PM by JurgenRo.)

(12-27-2018 09:18 PM)Thomas Okken Wrote: They don't carry the same jump distance. That low nybble of the opcode is part of the offset!

If you construct a GTO or XEQ with an incorrect offset, the instruction will jump to an incorrect location, and undesired behavior will most likely result. You should construct your GTO and XEQ instructions with their offsets set to zero, and let the calculator find the label and calculate the offset when it first executes the code.

(I guess you do want pre-compiled offsets when you're generating code for use in ROMs, but I've never dealt with that.)

Ahhhh, ok, I see what you mean! Finally!! "That low nybble of the opcode is part of the offset!": that's what I missed. Thanks a lot again, Thomas! Smile

One will never stop learning when dealing with the 41 Wink

JurgenRo · 12-27-2018, 10:46 PM

(12-27-2018 09:02 PM)Sylvain Cote Wrote: Great explanation Thomas!

You can find here HP explanation published in the Corvallis Division Column of the PPC Journal V6 N5 P.20 & 21 August 1979 : HERE

Thank you very much, Sylvain, great reading! Just overlooked the role of the low nybble as explained by Thomas, simply didn't read book and article as exact as it deserved - sorry for that!
All the best, Juergen

Sylvain Cote · 12-28-2018, 04:43 PM

Small details ...

there are 15 (2 bytes) GTO's (00 to 14) and matching labels (00 to 14) not 16
if LBL is out of reach (>112 bytes), the second byte will stay at 0x00 and label scan will be done each time
LBL search is always going forward until the end of the program, then go to start of the program and forward search again
you can have multiple LBL XX (00 to 14) and GTO XX (00 to 14) in your program (see example below)

Multiple labels example

Code:

program        uncompiled               compiled                 notes

01 LBL "ABC"   C0 00 F4 00 41 42 43     C0 00 F4 00 41 42 43     

02 LBL 00      01                       01                       

03 X<>Y        71                       71                       

04 GTO 00      B1 00                    B1 10                    goto line 06, forward 1 byte (0 register & 1 byte)

05 1/X         60                       60                       

06 LBL 00      01                       01                       

07 SIN         59                       59                       

08 GTO 00      B1 00                    B1 A1                    goto line 02, backward 9 bytes (1 register & 2 bytes)

09 END         C4 02 09                 C4 02 09

hth · 12-28-2018, 05:14 PM

If you edit your program using synthetic means in program mode, do not worry about which nibble you use unless you have an early machine (bug 8 I think). The HP41 decompiles the program after editing, as any program editing may have altered offsets. Decompiling means that it resets all offsets to unknown (0) when exiting program edit mode (by PRGM key or turning it off). The branch offsets are (re)created as needed when executing the program.

JurgenRo · 12-28-2018, 08:34 PM

(12-28-2018 04:43 PM)Sylvain Cote Wrote: Small details ...

there are 15 (2 bytes) GTO's (00 to 14) and matching labels (00 to 14) not 16

if LBL is out of reach (>112 bytes), the second byte will stay at 0x00 and label scan will be done each time

LBL search is always going forward until the end of the program, then go to start of the program and forward search again

you can have multiple LBL XX (00 to 14) and GTO XX (00 to 14) in your program (see example below)

Multiple labels example

Code:

program uncompiled compiled notes 01 LBL "ABC" C0 00 F4 00 41 42 43 C0 00 F4 00 41 42 43 02 LBL 00 01 01 03 X<>Y 71 71 04 GTO 00 B1 00 B1 10 goto line 06, forward 1 byte (0 register & 1 byte) 05 1/X 60 60 06 LBL 00 01 01 07 SIN 59 59 08 GTO 00 B1 00 B1 A1 goto line 02, backward 9 bytes (1 register & 2 bytes) 09 END C4 02 09 C4 02 09

Thank you very much, Sylvain! This is important, valuable information really! Appreciate it indeed! Still so much to find out after so many years!

JurgenRo · 12-28-2018, 08:44 PM

(12-28-2018 05:14 PM)hth Wrote: If you edit your program using synthetic means in program mode, do not worry about which nibble you use unless you have an early machine (bug 8 I think). The HP41 decompiles the program after editing, as any program editing may have altered offsets. Decompiling means that it resets all offsets to unknown (0) when exiting program edit mode (by PRGM key or turning it off). The branch offsets are (re)created as needed when executing the program.

Hi hth, I'm using a CX, so it does not have the bug, I guess. Nevertheless, useful information! This is really a time travel for me: re-larning what I knew almost 40 ago and - even more delighting - learning new things that I never knew on the amazing 41 Smile

Appreciate your input!

Sylvain Cote · 12-28-2018, 09:17 PM

(12-28-2018 08:44 PM)JurgenRo Wrote: Hi hth, I'm using a CX, so it does not have the bug, I guess. Nevertheless, useful information!

Jurgen,
This is not a bug but the normal behavior of all 41 models (C/CV/CX).
Each time a program is modified or packed, the 41OS clear all the compiled jumps.
The recompilation is done for all encountered GTO's on next execution time.
Sylvain

JurgenRo · (This post was last modified: 12-28-2018 11:28 PM by JurgenRo.)

(12-28-2018 11:25 PM)JurgenRo Wrote: [quote='Sylvain Cote' pid='109582' dateline='1546031875']
Jurgen,
This is not a bug but the normal behavior of all 41 models (C/CV/CX).
Each time a program is modified or packed, the 41OS clear all the compiled jumps.
The recompilation is done for all encountered GTO's on next execution time.
Sylvain

Hi Sylvain, thanks for clarification. I'm aware of the "automatic decompilation/compilation" as necessity to get jump-instructions right after, say, modifying an existing program which contains GTOs or XEQs. I was just referencing to hth's remark " ... do not worry about which nibble you use unless you have an early machine (bug 8 I think) ...". I'm using a CX, so I do not worry Wink

Anyway, I'm not aware what old machine's "bug 8" actually is doing. But because I have an older 41C as well, I'd clearly be curious to know what this bug does. So, any information about this bug (or, for that matters, any bug of the 41) would be highly appreciated! Thanks again, Sylvain!

Thomas Okken · 12-28-2018, 11:44 PM

This thread on the Old Forum contains a bug list: http://www.hpmuseum.org/cgi-sys/cgiwrap/...ead=163751

JurgenRo · (This post was last modified: 12-28-2018 11:59 PM by JurgenRo.)

(12-28-2018 11:44 PM)Thomas Okken Wrote: This thread on the Old Forum contains a bug list: http://www.hpmuseum.org/cgi-sys/cgiwrap/...ead=163751

Great! Thanks, hth!!

Sylvain Cote · (This post was last modified: 12-29-2018 03:44 PM by Sylvain Cote.)

(12-28-2018 11:27 PM)JurgenRo Wrote: I was just referencing to hth's remark " ... do not worry about which nibble you use unless you have an early machine (bug 8 I think) ...".

Oops, I did not get this correctly, sorry.

(12-28-2018 11:27 PM)JurgenRo Wrote: Anyway, I'm not aware what old machine's "bug 8" actually is doing.
But because I have an older 41C as well, I'd clearly be curious to know what this bug does.
So, any information about this bug (or, for that matters, any bug of the 41) would be highly appreciated!

Look at the bottom of the Craig A. Finseth's, HP-41C page: HERE
It list the bugs and the ones that was corrected by ROM versions.

JurgenRo · 12-29-2018, 08:30 PM

(12-29-2018 03:43 PM)Sylvain Cote Wrote:
(12-28-2018 11:27 PM)JurgenRo Wrote: I was just referencing to hth's remark " ... do not worry about which nibble you use unless you have an early machine (bug 8 I think) ...".
Oops, I did not get this correctly, sorry.

(12-28-2018 11:27 PM)JurgenRo Wrote: Anyway, I'm not aware what old machine's "bug 8" actually is doing.
But because I have an older 41C as well, I'd clearly be curious to know what this bug does.
So, any information about this bug (or, for that matters, any bug of the 41) would be highly appreciated!
Look at the bottom of the Craig A. Finseth's, HP-41C page: HERE
It list the bugs and the ones that was corrected by ROM versions.

Great, thanks a lot, Sylvain! Smile