DM42 and labels

[rprosperi]

(05-19-2020 10:53 PM)Sylvain Cote Wrote:  

(05-19-2020 09:17 PM)rprosperi Wrote:  I guess I didn't realize that a RTN, with no pending return stack just does a STOP.

Same behaviour on all RPN programmable since HP-67.

Not so. On some (many?, few?) machines, when you reach a RTN, it goes back to step 000 first, and then stops.

Here's an HP-34C program fragment:

Code:

01 LBL-A
02 5
03 0
04 0
05 0
06 ENTER
07 6
08 X (multiply)
09 RTN
10 1
11 CHS
12 *
13 RTN

GTO .000
[R/S]

Change to PRGM mode, what line number are you on?

Give it a try...

Edit-1: HP-41 stops upon hitting the RTN, with the PC on the next statement, as also seen on the 42S

How about other machines???

Edit-2: HP-15C goes to step 000 and stops, like the 34C

Edit-3: HP-67 stops upon hitting the RTN, with PC on the next statement

Who else has machines to test? Maybe a pattern will emerge, but it seems this behavior was not at all consistent across various model lines.

[Mike (Austria)]

Quote:Who else has machines to test? Maybe a pattern will emerge, but it seems this behavior was not at all consistent across various model lines.

Well lacking a physical collection, various microcode emulators (my revived goXX apps, Nonpareil, Sydney Smith's online emulators, and Teenix Multicalc) will have to suffice.

Discounting changes dictated by the calculator model (absence of / numerical / alpha labels) my test program looks like
LBL A ; 1 ; RTN ; LBL B ; 2 ; RTN ; LBL C ; 3 ; RTN ; LBL D ; 4 ; RTN

With one exception, all models that I could test behave either of the following ways, no matter how the program is started ( GTO xx ; R/S vs. GSB xx or XEQ xx ):
RTN resets to step 0: 34c, 11c, 15c, 16c, 32sii (physical)
RTN stops at next step: 29c, 67, 33c, 41c(vx), 42s

As expected the comparison confirms that 29c and 67 are close relatives, and the 41 and 42 were designed to make 67 users feel at home. The 33c has subroutines but no labels. The 15c (along with the other 1xc models) cannot deny its 34c heritage. In all tested emulators, RTN executed from the keyboard in run mode resets to step 0.

So far for the boring stuff. For a little surprise we need to go back to the beginning. When above program is entered into the 65, behavior depends on how you start the program. Hit any of the A-D keys, and execution stops at RTN as expected (e.g. A -> 1). However, when execution is started with R/S, the first RTN is ignored, and the program stops only at the next RTN (e.g.: GTO A ; R/S -> 2). I did not find mention of this anomaly in the 65 manual, which on page 62 states,

"The RTN at the end of the program stops calculator execution, halts the stepping of the program pointer, and returns control to the keyboard"

Yet another example for the pleasure of playing with old calculator models. Thanks Bob for the suggestion. Maybe someone with a physical 65 wants to verify this?

Best, Mike

[SlideRule]

(05-24-2020 08:52 PM)Mike (Austria) Wrote:  … When above program is entered into the 65, behavior depends on how you start the program … I did not find mention of this anomaly in the 65 manual …

An extract from HP-65 User News, of some interest to the phenom?
[attachment=8511]

BEST!
SlideRule

[Didier Lachieze]

(05-24-2020 08:52 PM)Mike (Austria) Wrote:  When above program is entered into the 65, behavior depends on how you start the program. Hit any of the A-D keys, and execution stops at RTN as expected (e.g. A -> 1). However, when execution is started with R/S, the first RTN is ignored, and the program stops only at the next RTN (e.g.: GTO A ; R/S -> 2). I did not find mention of this anomaly in the 65 manual, which on page 62 states,

"The RTN at the end of the program stops calculator execution, halts the stepping of the program pointer, and returns control to the keyboard"

Yet another example for the pleasure of playing with old calculator models. Thanks Bob for the suggestion. Maybe someone with a physical 65 wants to verify this?

Confirmed on my 1603S HP-65. This seems to be linked to the peculiar way the HP 65 manages the program memory through a circulating shift register, and main/secondary pointers. The 65 User’s manual from July 74 explicitly forbids to start with R/S a program ending by RTN (page 93/94):

"The rule for using R/S is simple: Pair a R/S with R/S. In other words, if you plan to initiate execution of your program with R/S, a R/S must be used as a program step to halt the program. Similarly, if your program begins with a label (A thru E), and ends with a RTN you must start it with the program control key identified by the label."

This is also described in the HP-65 User News V1N1 in the Q&As page 4. (EDIT: SlideRule beat me to it)

[rprosperi]

Wow, thanks to all 3 of you for more comments. I had no idea things were really this different, I simply had been playing with a 34C the day Sylvain's note was posted and knew I had seen different behavior.

It's interesting to see the 'blood lines' of the machines, likely pointing to design/code re-use on various projects.

Most interesting (excepting the 65 of course) is that the 33C and 34C behave differently. It seems to imply the 34C was not just an improved 33E, but probably was a fresh start (or major redesign at least) to accommodate the new features (integrate, solve, etc.) introduced in that model.

For the 65, thanks for the pointer Didier. I know I've read that complete manual, more than once, and yet this interesting little section did not stick. It's somewhat rare to see in these manuals such a firm "rule" explaining how things should be done, but with no real explanation for why, or consequences of not following the rules.

Who knew this could be interesting?

Mike summed it up best "Yet another example for the pleasure of playing with old calculator models."

Thanks!

[Dave Britten]

The 65 is a very odd duck with regards to RTN and subroutines (forgivable, considering it was the first programmable handheld, and it technically doesn't use RAM for program storage as it's not random-access memory). A few of its quirks:

As noted, the first RTN encountered does nothing when starting a program by pressing R/S (this does not apply to restarting a program that stopped itself with R/S). Execution will continue to the second RTN.

Pressing a subroutine key (A-E) when the corresponding label isn't defined in program memory will start execution from step 1 and behave normally. This is frequently taken advantage of in 65 programs that either need to save two steps by not explicitly defining one of the keyboard-activated subroutine labels, or by simply placing RTN as the first step in memory so that unassigned subroutine keys don't cause unintended program execution if pressed by the user.

A programmed subroutine call (A-E) without the corresponding label defined results in a brief delay while the calculator searches for the label, and then execution begins at step 1. However, the RTN does not properly return to the calling routine.

There are similar quirks involving GTO to labels that don't exist, and I think they mostly result in execution branching to step 1 with out any strange side-effects to RTN (I could be wrong). There's a rather extensive article in 65 Notes V2N1 (Jan 1975) that goes into detail about how the 65 behaves. The important part is that it's all consistent and predictable, and can be taken advantage of by a crafty programmer.

[rprosperi]

(05-26-2020 05:06 PM)Dave Britten Wrote:  Pressing a subroutine key (A-E) when the corresponding label isn't defined in program memory will start execution from step 1 and behave normally. This is frequently taken advantage of in 65 programs that either need to save two steps by not explicitly defining one of the keyboard-activated subroutine labels, or by simply placing RTN as the first step in memory so that unassigned subroutine keys don't cause unintended program execution if pressed by the user.

Thanks for the additional tips and notes Dave. I have not spent enough time with 65!

I love the little tricks you noted in the quoted section above! Great examples of the time-honored PPC mindset of using bugs or abnormal features as ways to get something done that couldn't otherwise be done.

[Dave Britten]

(05-26-2020 11:40 PM)rprosperi Wrote:  

(05-26-2020 05:06 PM)Dave Britten Wrote:  Pressing a subroutine key (A-E) when the corresponding label isn't defined in program memory will start execution from step 1 and behave normally. This is frequently taken advantage of in 65 programs that either need to save two steps by not explicitly defining one of the keyboard-activated subroutine labels, or by simply placing RTN as the first step in memory so that unassigned subroutine keys don't cause unintended program execution if pressed by the user.

Thanks for the additional tips and notes Dave. I have not spent enough time with 65!

I love the little tricks you noted in the quoted section above! Great examples of the time-honored PPC mindset of using bugs or abnormal features as ways to get something done that couldn't otherwise be done.

Another clever trick stems from label searches always beginning from the current program pointer position, and RTN leaving the pointer sitting where it stopped. You can have RTN at the top of program memory, followed by labels A, B, C, and D in your program with each routine ending with GTO a nonexistent label to park back at the top of program memory. Then have a LBL E that's followed only by RTN, and a second set of labels A-D after that. After pressing E, pressing A-D will call one of the second instances of the labels. They all have to be fairly small routines, but you can get 8 user-defined keys in your program this way.

Techniques like these, and the fact that the 65 skips two instructions when a condition is false (because GTO is unmerged, meaning you can also do "x>y 1 -" to decrement x if it's greater than y) can actually make it sort of tricky to port 65 programs to newer models at times. With only 100 steps, you can bet that programmers frequently took advantage of these idiosyncrasies!