Making a chart of GSB/XEQ/GTO/LBL/RTN functionality and quirks

[Dave Britten]

I'm working on an Excel table that compares the behavior, functionality, and quirks of GSB/XEQ, GTO, LBL, and RTN across all the programmable models. This is the checklist I've got so far:

GSB/XEQ
Max depth (including user-invoked routine)
Call stack overflow is error (Do any models throw an error, or do they all silently discard the oldest call?)
SST executes entire subroutine call
Labels
Line numbers
GSB/XEQ indirect to label
GSB/XEQ indirect backward steps
GSB/XEQ indirect forward steps

GTO
Labels
Line numbers
GTO indirect to label
GTO indirect backward steps
GTO indirect forward steps
RTN with empty call stack
Stop in place
Stop at top of program

LBL
Duplicate labels allowed
Label search starts from program pointer
Label search starts from top of program
Label searches cached

Special Notes
GTO nonexistent label jumps to top of program
A-E key to nonexistent label starts at top of program
Programmed A-E to nonexistent label jumps to top of program, next RTN stops program
R/S without A-E skips first RTN
Tests skip two steps if false
3rd subroutine call returns to 1st routine
GTO 00 stops program
SST of GSB allows only one RTN
GTO 00 acts like RTN
GTO and XEQ require a label and line number

Are there any other features or peculiarities I should list? I know some older models don't terminate an x-register entry on R/S (e.g. the 25), but I'm not sure if any keep a pending entry open on GTO/GSB, so I don't know where best to categorize that yet.

[Didier Lachieze]

A few other things I can think about:

GSB/XEQ
Dedicated execution keys - soft keys (A-B, A-E, a-e)
Dedicated execution keys in user mode - soft keys in user mode (A-E, F-J, a-e)
Programs assignable to keys in User mode
Programs assignable to custom menu

GTO
GTO .line_number to move to line number in program editing mode
GTO .global_label to move to global label in program editing mode
GTO .. to move to a new program space / pack memory

LBL
Local labels
Single digit global numeric labels
Two digit local numeric labels
Single letter global labels
Single letter local labels
Alphanumeric labels
Short local labels

Special notes
f PRGM in run mode acts as GTO 00
END acts as RTN
Keyboard shortcut (single key) to numeric labels (01-10)
Keyboard shortcut (menu) to global alpha labels

[Dave Britten]

Thanks, there's some great ideas there I hadn't thought of.

This is what I've got so far: (I still need to get all the details for the 33S and 35S)

https://1drv.ms/x/s!AiGfAbjKNtXngYN0Dj2S...g?e=s8VLMy

This is purely meant to cover the nuances of flow control - LBL, GTO, GSB/XEQ, RTN - not any other functions like tests or loop control functions. Handy when porting a program from one calculator to another and you need a quick reference to see if differences in the max subroutine depth, or the behavior when executing past the end of the program will need to be accounted for, for example.

I'm making the bold assumption that the 25 and 25C, 29C and 19C, and 67 and 97 are identical pairs. If anybody can point out areas where they differ in one of these regards, I'll split them up or add an extra note.

Also, I'm not sure if there's enough surviving information on the 95C to fill out all of this, but I might give it a shot.

[Didier Lachieze]

(06-03-2020 02:36 PM)Dave Britten Wrote:  This is what I've got so far: (I still need to get all the details for the 33S and 35S)

https://1drv.ms/x/s!AiGfAbjKNtXngYN0Dj2S...g?e=s8VLMy

This looks great! You've already put a lot of details in the table.

A small comment: GSB/XEQ Indirect to line numbers is not working correctly on the HP 15C and was removed from the manual as discussed here, as you may remember

[Dave Britten]

(06-03-2020 03:23 PM)Didier Lachieze Wrote:  

(06-03-2020 02:36 PM)Dave Britten Wrote:  This is what I've got so far: (I still need to get all the details for the 33S and 35S)

https://1drv.ms/x/s!AiGfAbjKNtXngYN0Dj2S...g?e=s8VLMy

This looks great! You've already put a lot of details in the table.

A small comment: GSB/XEQ Indirect to line numbers is not working correctly on the HP 15C and was removed from the manual as discussed here, as you may remember

Thanks for reminding me of that! I've obviously not done a great deal of 15C programming in the intervening 9 years.

I'll add a note that the 15C lets you attempt it, but it doesn't work properly. At least GTO I with negative I still works, since most tight loops will involve a GTO, and that's probably going to be where you get the biggest performance gains.

[Nihotte(lma)]

(06-03-2020 02:36 PM)Dave Britten Wrote:  Thanks, there's some great ideas there I hadn't thought of.

This is what I've got so far: (I still need to get all the details for the 33S and 35S)

https://1drv.ms/x/s!AiGfAbjKNtXngYN0Dj2S...g?e=s8VLMy

Hi Dave Britten and Didier Lachieze !

I think of something else that i had have to use in step by step program run. For the Special Notes.

Does the calculator keep the stack of return call from GSB when you watch (or finally, when you need to reposition the next step to execute) inside the program before resuming the execution.

I think of a sequence like SST, SST... in RUN mode, and then g P/R, followed by SST, ... BST to watch the code, and finally g P/R coming back in RUN mode and SST etc... to resume execution.
On my HP15C, the context of execution is kept, but it's not the same way for others of my calculators (TI, ...).

[Csaba Tizedes]

One addition to your list - RTN: Interrupted Solve "bug" on HP32SII: HP32SII Solver bug (MoHPC) and same(?) on 15C (Interrupted Integrate): HP15C Memory glitch (FB).

When SOLVE or Integrate interrupted the used memory not freed up (on 15C) or the SOLVE "locked" on HP32SII.

Csaba

[Dave Britten]

(06-03-2020 05:06 PM)Nihotte(lma) Wrote:  I think of something else that i had have to use in step by step program run. For the Special Notes.

Does the calculator keep the stack of return call from GSB when you watch (or finally, when you need to reposition the next step to execute) inside the program before resuming the execution.

I think of a sequence like SST, SST... in RUN mode, and then g P/R, followed by SST, ... BST to watch the code, and finally g P/R coming back in RUN mode and SST etc... to resume execution.
On my HP15C, the context of execution is kept, but it's not the same way for others of my calculators (TI, ...).

I think it varies between HPs, too. I know at least one of the manuals I was looking at while making this specifically stated that repositioning the program pointer manually (GTO or XEQ/GSB from the keyboard, or SST/BST in program mode) would clear the RTN stack. I hadn't thought to check if any vary subtly in that behavior.

[Valentin Albillo]

(06-02-2020 03:49 PM)Dave Britten Wrote:  I'm working on an Excel table that compares the behavior, functionality, and quirks of GSB/XEQ, GTO, LBL, and RTN across all the programmable models. This is the checklist I've got so far:

A couple' additions for you ...

• HP-15: to go to step nnn in PRGM Mode: [GTO] [CHS] nnn

(this is because there are labels .0 ... .9)

• HP-41C: to go to step 1nnn in PRGM Mode: [GTO] [.] [1] nnn

(this is for 4-digit step numbers, i.e., step 1234

... and a question: is the HP-71B included in the list ? It also has GOTO/GOSUB, you know ...

V.

[Thomas Okken]

(06-03-2020 02:36 PM)Dave Britten Wrote:  This is what I've got so far: (I still need to get all the details for the 33S and 35S)

https://1drv.ms/x/s!AiGfAbjKNtXngYN0Dj2S...g?e=s8VLMy

One detail... in Free42, return stack overflow is an error.

[Dave Britten]

(06-03-2020 11:41 PM)Thomas Okken Wrote:  

(06-03-2020 02:36 PM)Dave Britten Wrote:  This is what I've got so far: (I still need to get all the details for the 33S and 35S)

https://1drv.ms/x/s!AiGfAbjKNtXngYN0Dj2S...g?e=s8VLMy

One detail... in Free42, return stack overflow is an error.

Ah, thanks for the correction! I doubt anybody's going to hit that error outside of an accidental infinite recursion, though.

[Paul Dale]

(06-04-2020 01:56 AM)Dave Britten Wrote:  I doubt anybody's going to hit that error outside of an accidental infinite recursion, though.

Writes someone who hasn't implemented Ackerman's function


Pauli

[Thomas Okken]

(06-04-2020 01:56 AM)Dave Britten Wrote:  Ah, thanks for the correction! I doubt anybody's going to hit that error outside of an accidental infinite recursion, though.

That's the idea. The risk of accidental infinite recursion (or, indeed, the Ackermann function) is why the return stack even has a depth limit, otherwise I would have made it dynamically growing, limited only by available RAM.