HP-41 Byte Table
12-27-2018, 07:54 PM
Post: #1
 JurgenRo Member Posts: 176 Joined: Jul 2015
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
12-27-2018, 08:31 PM
Post: #2
 Thomas Okken Senior Member Posts: 1,765 Joined: Feb 2014
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.
12-27-2018, 09:02 PM
Post: #3
 Sylvain Cote Senior Member Posts: 1,765 Joined: Dec 2013
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
12-27-2018, 09:05 PM
Post: #4
 JurgenRo Member Posts: 176 Joined: Jul 2015
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!
12-27-2018, 09:11 PM (This post was last modified: 12-27-2018 09:19 PM by JurgenRo.)
Post: #5
 JurgenRo Member Posts: 176 Joined: Jul 2015
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
12-27-2018, 09:18 PM
Post: #6
 Thomas Okken Senior Member Posts: 1,765 Joined: Feb 2014
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.)
12-27-2018, 09:22 PM (This post was last modified: 12-27-2018 09:25 PM by JurgenRo.)
Post: #7
 JurgenRo Member Posts: 176 Joined: Jul 2015
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! One will never stop learning when dealing with the 41
12-27-2018, 10:46 PM
Post: #8
 JurgenRo Member Posts: 176 Joined: Jul 2015
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
12-28-2018, 04:43 PM
Post: #9
 Sylvain Cote Senior Member Posts: 1,765 Joined: Dec 2013
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
12-28-2018, 05:14 PM
Post: #10
 hth Senior Member Posts: 413 Joined: Mar 2014
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.
12-28-2018, 08:34 PM
Post: #11
 JurgenRo Member Posts: 176 Joined: Jul 2015
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!
12-28-2018, 08:44 PM
Post: #12
 JurgenRo Member Posts: 176 Joined: Jul 2015
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 41 Appreciate your input!
12-28-2018, 09:17 PM
Post: #13
 Sylvain Cote Senior Member Posts: 1,765 Joined: Dec 2013
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
12-28-2018, 11:27 PM (This post was last modified: 12-28-2018 11:28 PM by JurgenRo.)
Post: #14
 JurgenRo Member Posts: 176 Joined: Jul 2015
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 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!
12-28-2018, 11:44 PM
Post: #15
 Thomas Okken Senior Member Posts: 1,765 Joined: Feb 2014
RE: HP-41 Byte Table
12-28-2018, 11:57 PM (This post was last modified: 12-28-2018 11:59 PM by JurgenRo.)
Post: #16
 JurgenRo Member Posts: 176 Joined: Jul 2015
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!!
12-29-2018, 03:43 PM (This post was last modified: 12-29-2018 03:44 PM by Sylvain Cote.)
Post: #17
 Sylvain Cote Senior Member Posts: 1,765 Joined: Dec 2013
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.
12-29-2018, 08:30 PM
Post: #18
 JurgenRo Member Posts: 176 Joined: Jul 2015
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!
 « Next Oldest | Next Newest »

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