Bug in the HP-41 with R/S and stack lift - Printable Version +- HP Forums (https://www.hpmuseum.org/forum) +-- Forum: HP Calculators (and very old HP Computers) (/forum-3.html) +--- Forum: General Forum (/forum-4.html) +--- Thread: Bug in the HP-41 with R/S and stack lift (/thread-15815.html) Pages: 1 2 |
RE: Bug in the HP-41 with R/S and stack lift - Thomas Okken - 11-02-2020 08:09 PM (11-02-2020 01:15 PM)Ángel Martin Wrote: I keep assuming that ST+ puts the X value in LastX, which it does not.... counter-intuitive for me. Why? The register arithmetic functions are guaranteed not to change the value of X (unless you count ST+ X etc.), so why would they copy X into LASTx? RE: Bug in the HP-41 with R/S and stack lift - Valentin Albillo - 11-02-2020 08:59 PM (11-02-2020 01:15 PM)Ángel Martin Wrote: I keep assuming that ST+ puts the X value in LastX, which it does not.... counter-intuitive for me. Counter-intuitive ? Why ? In general, only instructions that do change X are expected to copy the previous value of X to the LastX register. As STO operations do not change the value in X (except if X is the addressed register, of course) they should not copy the contents of the X register to LastX. That would be counter-intuitive, and wrong. On the other hand, RCL+, RCL-, RCLx and RCL/ do change X and thus the previous X is indeed copied to LastX, as it should. You're getting old, Ángel. Best regards. V. RE: Bug in the HP-41 with R/S and stack lift - Gene - 11-03-2020 12:34 AM STO + X and RCL + X differ in what way? Last X ? RE: Bug in the HP-41 with R/S and stack lift - Thomas Okken - 11-03-2020 12:43 AM (11-03-2020 12:34 AM)Gene Wrote: STO + X Correct. Both replace X with 2*X, but RCL+ ST X copies the original X to LASTx while STO+ ST X does not. RE: Bug in the HP-41 with R/S and stack lift - Ángel Martin - 11-03-2020 06:37 AM (11-02-2020 08:59 PM)Valentin Albillo Wrote:(11-02-2020 01:15 PM)Ángel Martin Wrote: I keep assuming that ST+ puts the X value in LastX, which it does not.... counter-intuitive for me.You're getting old, Ángel. No dispute here ;-) I meant to write ST+ X hopefully it now makes sense to y'all pack of wolves ... RE: Bug in the HP-41 with R/S and stack lift - Valentin Albillo - 11-03-2020 06:23 PM . Hi, Ángel: (11-03-2020 06:37 AM)Ángel Martin Wrote:(11-02-2020 08:59 PM)Valentin Albillo Wrote: You're getting old, Ángel. For the record, I'm older. Quote:I meant to write ST+ X Ah, now it makes sense. Quote:hopefully it now makes sense to y'all pack of wolves ... I might be a wolf but certainly a mindreader I'm not. Best regards. V. RE: Bug in the HP-41 with R/S and stack lift - Didier Lachieze - 11-05-2020 05:57 PM (10-31-2020 06:03 PM)hth Wrote: 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: I agree, this is how it works on the 41C. But I checked several HP calculators (physical ones or emulators) and I was surprised to find that on most of the calculators tested from the HP-65 to the HP-35S, R/S is neutral vs. stack lift, with two exceptions: HP 41C and WP 34S where R/S enables the stack lift. I used the following program: 2 + STOP Before running the sequence with R/S, the stack was initialized with : 3 ENTER CLx So the stack is initialized with 0 in X, 3 in Y and stack lift is disabled. If R/S is neutral vs stack lift, then when running the sequence 2 + STOP, the 2 will replace the 0 in X without lifting the stack, then it will be added to the 3 in Y for a result of 5 If R/S enables stack lift, then when running the sequence 2 + STOP, the 2 will be entered in X and lift the stack, pushing the 0 in Y, and the 3 in Z, then the 2 in X will be added to the 0 in Y for a result of 2 Here are the results with also what is mentioned (or not) in the manual for each calculator : Code: Result Stack Lift when Manual description Manual Section RE: Bug in the HP-41 with R/S and stack lift - hth - 11-23-2020 06:12 PM Interesting list, I have stewed on it for a while. It is clear that the majority is neutral and the HP-41 is a bit of an oddball here. I kind of think this was not intended behavior and would have been changed if pointed to early on in development. I think the case of stopping, viewing something, restore and resume operation should not affect program result (only visuals on the display as it clears any message shown). I will leave this and not mess with it for now. It has not been seen as a problem in the past and people seem quite divided about it. RE: Bug in the HP-41 with R/S and stack lift - Roland57 - 11-23-2020 06:36 PM (11-05-2020 05:57 PM)Didier Lachieze Wrote: Here are the results with also what is mentioned (or not) in the manual for each calculator : On page 82 of the hp55 Owner’n Handbook there is an interesting statement: “Pressing any key( even accidentally) halts program execution. If a program has been stopped by pressing a key, be careful not to restart program execution in the middle of a digit entry key sequence within the program or between a prefix key and the corresponding operation. Use BST or SST to reposition the program pointer in either of these cases” (bold typeface by me) I think, it describes the discussed problem clearly. Roland |