Bug in the HP-41 with R/S and stack lift

[hth]

I found another bug in the HP-41. It enables stack lift when starting a program which means that the following program:

Code:


8
ENTER
9

If you interrupt the program (press the R/S key) at the 9 line, you have just executed ENTER and have the stack lift disabled. If you now press R/S again to continue running, you will end up with:

Code:


8
8
9

on the stack.

[hth]

This also happens with the CLD function.

Code:


8
ENTER
CLD
9

Also results in:

Code:


8
8
9

on the stack.

I am not sure if it is a bug with CLD, it may be documented behavior.

[Didier Lachieze]

I don't think it's a bug, according to the HP-41C Owner's Handbook and Programming Guide, Appendix C:

Quote:All operations on the HP-41C other than those listed below (under Disabling Operations and Neutral Operations) enable the stack lift.

R/S and CLD are not listed in the Disabling or Neutral Operations, so they are working as per the manual.

[hth]

So you think pressing R/S to stop a program, immediately followed by R/S again to resume, and this may cause the program to have different behavior than if you had let it run, is not a bug?

[toml_12953]

(10-31-2020 07:36 AM)hth Wrote:  So you think pressing R/S to stop a program, immediately followed by R/S again to resume, and this may cause the program to have different behavior than if you had let it run, is not a bug?

Since it works the way the manual says it does, it is not a bug. It's not a good thing to have happen but it's not a bug. There's a difference.

[Didier Lachieze]

That's an interesting corner case, because in general I think that you would not want R/S to be neutral with regard to stack lift. When starting a program sequence with R/S I expect stack lift to be enabled, otherwise the following sequence would provide a different result if the user enters 0 or just press CLx before pressing R/S:

Code:

STOP
2
+

in the first case the result would be 0+2, in the second case it would be Y+2.

I'm wondering how this is managed on other HP RPN calculators, either before or after the 41C.

[Sylvain Cote]

Since it is documented, I agree it is not a bug, but IMHO STOP (R/S) should have been stack lift neutral.

[J-F Garnier]

(10-31-2020 11:47 AM)Didier Lachieze Wrote:  That's an interesting corner case, because in general I think that you would not want R/S to be neutral with regard to stack lift. When starting a program sequence with R/S I expect stack lift to be enabled, otherwise the following sequence would provide a different result if the user enters 0 or just press CLx before pressing R/S:

Code:

STOP
2
+

in the first case the result would be 0+2, in the second case it would be Y+2.

Good point, actually PROMPT is very often used to enter values followed by R/S.

On the other hand, sequences like "8 ENTER 9" were almost never used by 80's HP-41 users, who just used "8 9" (doesn't save a byte but is marginally faster) so the R/S stack lift enable effect is rare (although yes it can happen so it's good to know it).

J-F

[rprosperi]

It's an interesting observation for sure, though I'm curious how you are able to so precisely press [R/S] upon the 9 step (in the original example). I assume the amazingly unlikely ability to do this deliberately, or maybe the more likely chance that this never occurred on a susceptible stack configuration during testing led to it being simply something HP did not encounter.

This behavior being consistent with the manual is IMHO probably a coincidence and while therefor not technically a 'bug' in the classic sense, I would agree that it was not what HP intended.

How on earth did you find this and how many attempts did it take to characterize it?

[hth]

I think that normally you want stack lift to be enabled when pressing R/S, as it allows two identical numbers to be entered on the stack like:

Code:


42
ENTER
RUN

You expect this to be two numbers when starting the program and it should be allowed for the program to push a number the first thing it does without disrupting your two entered values. That is consistent with any built in function like PLUS.

The manual is not the law, it merely documents the behavior of the implementation.

What is a bug (in my view) is that it does something wrong, unintentional by design or possibly something weird you would never expect.

I still think it is a bug, but it is by design and not really fixable as it would break other desired behavor. The cure would hurt more than the problem.

It is true that you seldom have stack lift disabled in a running program. Only CLX and ENTER do it and they are not so common in programs unless you are a newbie.

How I found it? Well, I did not manage to trip it by accident. I was debugging a replacement for the R/S key (for the Boost module) and single stepped the whole thing in VS Code and stepped into the NWGOOS (new goose, LoL) and noticed that it ends with a jump to NFRPU (normal function return, set push flag) like most functions. It just clicked in my head, what happens if a program looks like this and I stop and restart it at the "wrong point"? It took about 10 tries using a trivial (made for the purpose) program to trip the unexpected behavior.

[rprosperi]

I fully agree with you! In the manual or not, actually a bug or not, either way it simply isn't 'right' but as you say it had to stay that way, if they even noticed it.

Thanks for explaining how you found it. Although a sensible explanation I guess the odds of your reply being 'I just randomly found it by mistake' seemed a lot higher than 'I found it debugging a replacement for the [R/S] key', LOL.

[Paul Dale]

Didn't the HP-25 not enable stack lift when R/S was used to start a program? This difference has confused me in the past.


Pauli

[Didier Lachieze]

On the HP-25 R/S doesn't terminate digit entry which can also be confusing as discussed here.

[Paul Dale]

Thanks Didier, that's the one.

[ijabbott]

Can this be reproduced on HP-42S?

With a cleared stack, for:

Code:

LBL "AAA"
8
ENTER
9

I tried single-stepping past the 'ENTER' and then pressing 'R/S' and ended up with the stack contents:

Code:

0 
0
8
9

[Thomas Okken]

(11-01-2020 03:35 PM)ijabbott Wrote:  Can this be reproduced on HP-42S?

On the HP-42S, R/S does not enable stack lift, neither when used to interrupt a running program nor when used to start or resume program execution.

The STOP command, in a program, does enable stack lift, though.

[vassilisprevelakis]

(10-31-2020 05:10 AM)hth Wrote:  I found another bug in the HP-41. It enables stack lift when starting a program which means that the following program:

Code:


8
ENTER
9

Actually you do not need the ENTER since the HP41 numbers are fully merged.
You'd need the ENTER in previous calculators (e.g. HP-67) where numbers were
not merged, so you needed a way to separate them.

So, if you take out the ENTER, the program will work correctly even if interrupted.

**vp

PS OK I know this does not address your point, but I thought I'd point this out anyway :-)

[Ángel Martin]

Bug or not it's certainly peculiar - to the point of not "feeling" right... but it isn't the only case out there. For instance I keep assuming that ST+ puts the X value in LastX, which it does not.... counter-intuitive for me.

[vassilisprevelakis]

(11-02-2020 01:15 PM)Ángel Martin Wrote:  Bug or not it's certainly peculiar - to the point of not "feeling" right... but it isn't the only case out there. For instance I keep assuming that ST+ puts the X value in LastX, which it does not.... counter-intuitive for me.

You are sooo right, even if I like it just fine that ST+ does not mess with LASTx
(after all how would it deal with ST+ L :-)

With RPN, HP tried to make things "intuitive" rather than consistent, but clearly not everybody agrees on what is intuitive so RPN is better described as ad hoc, and you have to expect surprises.

I guess the rule is that if one wants consistency, RPL is the way to go.

**vp

PS I like surprises.

[Ángel Martin]

(11-02-2020 01:29 PM)vassilisprevelakis Wrote:  I guess the rule is that if one wants consistency, RPL is the way to go.

OMG, pls. gimme many many more inconsistencies !! ;-)