Post Reply 
HP-41 Byte Table
12-27-2018, 07:54 PM
Post: #1
HP-41 Byte Table
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
Find all posts by this user
Quote this message in a reply
12-27-2018, 08:31 PM
Post: #2
RE: HP-41 Byte Table
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.
Visit this user's website Find all posts by this user
Quote this message in a reply
12-27-2018, 09:02 PM
Post: #3
RE: HP-41 Byte Table
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
Find all posts by this user
Quote this message in a reply
12-27-2018, 09:05 PM
Post: #4
RE: HP-41 Byte Table
(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!
Find all posts by this user
Quote this message in a reply
12-27-2018, 09:11 PM (This post was last modified: 12-27-2018 09:19 PM by JurgenRo.)
Post: #5
RE: HP-41 Byte Table
(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
Find all posts by this user
Quote this message in a reply
12-27-2018, 09:18 PM
Post: #6
RE: HP-41 Byte Table
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.)
Visit this user's website Find all posts by this user
Quote this message in a reply
12-27-2018, 09:22 PM (This post was last modified: 12-27-2018 09:25 PM by JurgenRo.)
Post: #7
RE: HP-41 Byte Table
(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
Find all posts by this user
Quote this message in a reply
12-27-2018, 10:46 PM
Post: #8
RE: HP-41 Byte Table
(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
Find all posts by this user
Quote this message in a reply
12-28-2018, 04:43 PM
Post: #9
RE: HP-41 Byte Table
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
Find all posts by this user
Quote this message in a reply
12-28-2018, 05:14 PM
Post: #10
RE: HP-41 Byte Table
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.
Find all posts by this user
Quote this message in a reply
12-28-2018, 08:34 PM
Post: #11
RE: HP-41 Byte Table
(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!
Find all posts by this user
Quote this message in a reply
12-28-2018, 08:44 PM
Post: #12
RE: HP-41 Byte Table
(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 41Smile Appreciate your input!
Find all posts by this user
Quote this message in a reply
12-28-2018, 09:17 PM
Post: #13
RE: HP-41 Byte Table
(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
Find all posts by this user
Quote this message in a reply
12-28-2018, 11:27 PM (This post was last modified: 12-28-2018 11:28 PM by JurgenRo.)
Post: #14
RE: HP-41 Byte Table
(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!
Find all posts by this user
Quote this message in a reply
12-28-2018, 11:44 PM
Post: #15
RE: HP-41 Byte Table
This thread on the Old Forum contains a bug list: http://www.hpmuseum.org/cgi-sys/cgiwrap/...ead=163751
Visit this user's website Find all posts by this user
Quote this message in a reply
12-28-2018, 11:57 PM (This post was last modified: 12-28-2018 11:59 PM by JurgenRo.)
Post: #16
RE: HP-41 Byte Table
(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!!
Find all posts by this user
Quote this message in a reply
12-29-2018, 03:43 PM (This post was last modified: 12-29-2018 03:44 PM by Sylvain Cote.)
Post: #17
RE: HP-41 Byte Table
(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.
Find all posts by this user
Quote this message in a reply
12-29-2018, 08:30 PM
Post: #18
RE: HP-41 Byte Table
(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
Find all posts by this user
Quote this message in a reply
Post Reply 




User(s) browsing this thread: 1 Guest(s)