RPN programming model survey

[brouhaha]

Recent discussion of program editing options for a hypothetical enhanced 12C resulted in my doing a survey of the programming models of the programmable HP RPN calculators, i.e., how memory is partitioned, whether keyed steps are inserted or overwritten, whether steps can be deleted, whether labels are used for branching, etc.

I've put the information I compiled here:
http://www.brouhaha.com/~eric/hpcalc/pro...odel.xhtml

Corrections and comments are welcome.

[Joe Horn]

The 35s might be unique in that it not only allows "GTO LBL+line number" programming, but also has the "feature" of automatically renumbering all the line numbers after GTO's when program lines are inserted or deleted. That sounds nice, but it's actually a horrible idea, because if GTO Znnn is in the program, and you delete program line Znnn, the GTO now points to the wrong line (namely, what had been the line after Znnn before the edit). Every time I try to debug by trial and error on the 35s, the GTO's get all out of whack. Horrible idea.

[Valentin Albillo]

(01-15-2023 02:45 AM)Joe Horn Wrote:  The 35s might be unique in that it not only allows "GTO LBL+line number" programming, but also has the "feature" of automatically renumbering all the line numbers after GTO's when program lines are inserted or deleted. That sounds nice, but it's actually a horrible idea, because if GTO Znnn is in the program, and you delete program line Znnn, the GTO now points to the wrong line (namely, what had been the line after Znnn before the edit). Every time I try to debug by trial and error on the 35s, the GTO's get all out of whack. Horrible idea.

Agreed. After being stung many times by wrongly renumbered GOTOs plus unreliable checsums and other nasty bugs, including unrecoverable locks ultimately resulting in losing all (hard-to-key-in) programs and wasting tons of my time, I gave up and tossed the HP-35s in a drawer, where it rests unused for the last 15 years. A pity, I initially liked it but its many important bugs and flaws ultimately killed it for me.

That's what happens when HP forgets about decent quality controls and further doesn't ever fix the bugs: what shoud have been a very nice calc goes down in shame, directly to oblivion. Another example woul be the "über-buggy, utterly unreliable toy", many of them also indefinitely gathering dust, but that's another story.

Regards.
V.

[rprosperi]

(01-15-2023 01:48 AM)brouhaha Wrote:  I've put the information I compiled here:
http://www.brouhaha.com/~eric/hpcalc/pro...odel.xhtml

Corrections and comments are welcome.

Handy chart Eric, thanks for sharing.

The 33S is missing and close to the 35S, but without some of the nasty behavior and bugs found there; when I get home, I'll send you data to complete the table for it.

Also, can you please add a link to get to this on the above page, where we can find it in the future without saving this exact link?

Thanks!

[Gene]

(01-15-2023 02:45 AM)Joe Horn Wrote:  The 35s might be unique in that it not only allows "GTO LBL+line number" programming, but also has the "feature" of automatically renumbering all the line numbers after GTO's when program lines are inserted or deleted. That sounds nice, but it's actually a horrible idea, because if GTO Znnn is in the program, and you delete program line Znnn, the GTO now points to the wrong line (namely, what had been the line after Znnn before the edit). Every time I try to debug by trial and error on the 35s, the GTO's get all out of whack. Horrible idea.

Gene: As far as I know, EVERY programmable model (TI or HP) that uses GTO line numbers (Znnn) will point to the wrong line once you delete line Znnn.

001 LBL A
002 GTO 003
003 SIN
004 COS

On ANY model SR-52, SR-56, TI-58, HP-25, if you delete line 003 SIN, line 04 will now become line 003 COS which is now what you originally intended.

I know the checksum is an awful bug, but if you program with line number GTO instructions, life is tough.

And I am open to being shown a model where the above 4 step program will work properly if line 003 is deleted.

The 35s "locks" in a destination "instruction" with the GTO line number and if the step number changes, the instruction is still pointed to.

Yes, that can be a pain, but the alternative is IMO worse.

I say that as an SR-52 programmer. Absolute GTO is a very mixed bag.

:-)

Gene

[Joe Horn]

(01-15-2023 07:41 PM)Gene Wrote:  Gene: As far as I know, EVERY programmable model (TI or HP) that uses GTO line numbers (Znnn) will point to the wrong line once you delete line Znnn.

The difference with the 35s is that, unlike other models, it tries to compensate for the deletion when you try to replace the deleted line. Example on the 35s:

A001 LBL A
A002 2
A003 3
A004 4
A005 GOTO A003

Now delete line A003 and replace it with 3.333 and see that the program has become this:

A001 LBL A
A002 2
A003 3.333
A004 4
A005 GOTO A004

I don't think any other model screws things up that badly.

Yes, I know that this particular example's problem can be avoided by inserting 3.33 after line A003, then backstepping and deleting A003 ... but that's a workaround for a bad design, IMHO.

[DGM]

Joe, in my opinion, the deletion of a line and then inserting it again behaves exactly as it should, because the programming that changes the line number cannot possibly guess that you were going to insert it again. It isn’t psychic

[brouhaha]

(01-15-2023 02:01 PM)rprosperi Wrote:  The 33S is missing and close to the 35S, but without some of the nasty behavior and bugs found there; when I get home, I'll send you data to complete the table for it.

I added them, but since I'm not very familiar with them, it would be great if you could check it for me.

Quote:Also, can you please add a link to get to this on the above page, where we can find it in the future without saving this exact link?

I'm not sure I fully understand, but if what you wanted is a link from my page to this forum thread, I've added that.

[rprosperi]

(01-16-2023 01:59 AM)brouhaha Wrote:  I'm not sure I fully understand, but if what you wanted is a link from my page to this forum thread, I've added that.

Thanks.

Sorry I wasn't clear, I meant to please add a link to this new page on your base "Hewlett-Packard Calculators" page that lists your various other topics (i.e. here: http://www.brouhaha.com/~eric/hpcalc/).

[brouhaha]

(01-16-2023 02:27 PM)rprosperi Wrote:  I meant to please add a link to this new page on your base "Hewlett-Packard Calculators" page that lists your various other topics (i.e. here: http://www.brouhaha.com/~eric/hpcalc/).

OK, done. Thanks for the suggestion.

[David Hayden]

Line number addressing is a pain. The 35s attempts to make it better, but it still falls short for the reasons already mentioned. Labels are a lot easier to use.

I think the 35s method would have worked okay if the GTO adjustment had worked across labels. Sadly, it does not, probably for performance reasons.

In other words, I think the workflow should have been like this:
1. Write and debug your program using label addressing.
2. Once the program works right, delete all the internal labels. The calculator converts the GTO/XEQ [label] to GTO/XEQ [line number]

The wouldn't be perfect. It might still be hard to develop large programs, but short of adding more labels, I think it would have been a great addition.

Oh, and local registers/flags similar to the WP34s should be required on any new programmable RPN calculators .

[Maximilian Hohmann]

Hello!

(01-26-2023 03:08 PM)David Hayden Wrote:  2. Once the program works right, delete all the internal labels. The calculator converts the GTO/XEQ [label] to GTO/XEQ [line number]

But what if you want to modify your program at some later stage? What you suggest is more or less an assembler or compiler that leaves you alone with the binary code once you compiled the source.

Regards
Max