The Museum of HP Calculators

HP Forum Archive 16

 CHS and Stack LiftMessage #1 Posted by Les Wright on 11 Feb 2007, 5:21 a.m. Here is an interesting observation I have made as I have tried to port a certain program across several RPN calculators. The routine returns the result, R, and its complement, 1-R in registers X and Y, and you view them both with x<>y as you wish. On occasion, the program may return 0 and I want to compute the complement 1 - R = 1 and end with 0 in the Y register and 1 in the X register. I have noticed differences across calculators in the treatment of these closing steps if 0 is in the X register: ENTER CHS 1 + On the HP41, HP42, and HP33S, the steps do what I want--they copy the result into Y, change the sign of the X register (null effect when this is 0) and add 1 to the X register, leaving the correct complementary values in the X and Y register. The important point here is that CHS seems to enable stack lift no matter whether the contents of the X-register are zero or not. However, I have discovered that CHS only seems to enable stack lift on the 11C and 34C when the operand in the X register is not zero. If it is zero, CHS seems to do nothing, and when the 1 is added to the 0 in the X register the register is overwritten and the stack is dropped, so that the Y register holds not zero, as desired, but whatever was in Z register before the addition took place. If the value in the X register is anything but zero, the four steps above have the desired behaviour. Adding an extra step seems the only way to fix it: ENTER ENTER 1 - CHS I thought this was a very interesting difference. I don't know if the behaviour in the 11C and 34C is a bug or a feature, but it certainly would be less confusing if it enables stack lift for nonzero operands it would do so for zero too! Les

 Re: CHS and Stack LiftMessage #2 Posted by Les Wright on 11 Feb 2007, 6:15 a.m.,in response to message #1 by Les Wright Oh, I should note the 15C behaves like the 11C in this regard. Les

 Re: CHS and Stack Lift with zeroMessage #3 Posted by Karl Schneider on 11 Feb 2007, 4:54 p.m.,in response to message #1 by Les Wright Hi, Les -- Interesting find! (Although I'm sure that it's been found before...) I'd say that the HP-34C/11C/15C/16C response is of an unintended type that H-P eliminated permanently with the Pioneer series. It slipped into the three aforementioned Voyager-series models after the HP-41 debuted, likely due to reuse of ROM code from the HP-34C for the "advanced" Voyagers. The original thinking may have been, "Ignore any command to negate zero", but such processing may sabotage a program that negates a value that might happen to equal zero. On all HP RPN (not RPL)-based calc's, ENTER disables stack lift. However, there is different behavior in various lines of calculators following CHS with zero in the x-register: ```calulator line CHS on post-CHS | CHS on post-CHS result of zero stack lift | keyed-in zero stack lift | HP-34C/11C/15C/16C ignored unchanged | ignored disabled HP-10C/12C ignored enabled | ignored disabled HP-41 ignored enabled | ignored disabled HP-32S/32SII/42S ignored enabled | accepted disabled ``` "ignored" means that the value is not changed and the negative sign is not displayed. Regarding "keyed-in zero", one can enter [0][+/-][2][6] on any Pioneer-series model, and see "-026", which is converted to -26.00. On the other ones listed, 26.00 is the result. Another workaround for the "Spice and Voyager" models that does not disturb the stack is a conditional test: ```ENTER CHS x=0? ABS (re-enables stack push) ``` Here's an example for f(x) = xe1-x on the HP-34C/11C/15C: ``` program input x result | program input x result | LBL A 0 (erroneous) | LBL A 0 0.000 ENTER 1 1.000 | ENTER 1 1.000 CHS 2 0.736 | CHS 2 0.736 1 | x=0? + | ABS e^x | 1 * | + RTN | e^x | * | RTN ``` "erroneous" means that the function will not be calculated properly, so the user cannot generally expect a correct result. However, this user function will work properly without the workaround using the HP-15C SOLVE and INTEG, because those built-in functions load the stack with the input argument. -- KS Edited: 13 Feb 2007, 1:02 a.m. after one or more responses were posted

 Re: CHS and Stack Lift with zeroMessage #4 Posted by bill platt on 11 Feb 2007, 5:11 p.m.,in response to message #3 by Karl Schneider Karl: I like your tables. They are very useful. Regards, Bill

 Re: CHS and Stack Lift with zeroMessage #5 Posted by Karl Schneider on 11 Feb 2007, 6:15 p.m.,in response to message #4 by bill platt Hi, Bill -- Quote: Karl: I like your tables. They are very useful. Regards, Bill Thanks for the compliment, but they would have more useful if they had been entirely correct. :-) Please review my post again to find corrected tables and an example. Regards, -- KS

 Re: CHS and Stack Lift with zeroMessage #6 Posted by Les Wright on 11 Feb 2007, 8:11 p.m.,in response to message #3 by Karl Schneider Karl, the workaround is perfect when it is important not ot molest the rest of the stack, but at the cost of two extra steps. In my case, what is happening in X and Y is all that concerns me, so adding the extra ENTER, performing a subtraction instead of addition, and relocating the CHS to the end costs just an extra step and is probably a bit faster. And the 34C and 11C are slow enough as it is! Many thanks, Les

 CHS and Stack Lift with zero previously mentioned by GersonMessage #7 Posted by Vieira, L.C. (Brazil) on 14 Feb 2007, 8:02 a.m.,in response to message #3 by Karl Schneider Quote:Interesting find! (Although I'm sure that it's been found before...) Cheers. Luiz (Brazil)

 Re: CHS and Stack Lift with zero previously mentioned by GersonMessage #8 Posted by Karl Schneider on 14 Feb 2007, 3:24 p.m.,in response to message #7 by Vieira, L.C. (Brazil) Hi, Luiz -- Thank you for the recent Archive link. I'd forgotten about that thread, because I don't have an HP-12C Platinum, and don't intend to buy one. However, the problem listed in the thread is not quite the same one as Les posed. The issue is the post-CHS status of stack lift behavior when zero is in the x-register and the the pre-CHS status was "disabled". The 12CP problem was that CHS did rot re-instate stack lift for any value in the x-register. Trent Mosely seems to have the models whose performance is of interest to me. From last year's thread: Quote: Just for the fun of it I tried the program on my red LED models (25C, 31E, and 67) and the bug showed up of all places on the 25C! tm Correction. There is NO bug in the 25C on this issue. The Owner's Handbook clearly states on page 111 that a number keyed in following CHS does not affect the stack in other words it overwrites it. tm Thanks, -- KS

 Re: CHS and Stack LiftMessage #9 Posted by Mike T. on 11 Feb 2007, 8:35 p.m.,in response to message #1 by Les Wright I think that the HP33C behaves in the same way (as you might expect) - any one able to try this on an HP10C. I don't have mine handy right now... It was a later model and past experience indicates that it behaves subtly differently (bug fixes?). Mike T.

 Re: CHS and Stack LiftMessage #10 Posted by Miguel Toro on 12 Feb 2007, 7:28 p.m.,in response to message #9 by Mike T. Hello, I think this is my second post here. I just read this post and tried the examples in my 10C and it behaves as expected, so it enables stack lift as the 41, 42 and 33S. Mine has the S/N 2242A10747. Regards, Miguel

 15C bug? [CHS and Stack Lift with zero]Message #11 Posted by Karl Schneider on 14 Feb 2007, 4:05 a.m.,in response to message #1 by Les Wright In Les' recent finding (or rediscovery): Quote: ENTER CHS 1 + On the HP41, HP42, and HP33S, the steps do what I want--they copy the result into Y, change the sign of the X register (null effect when this is 0) and add 1 to the X register, leaving the correct complementary values in the X and Y register. The important point here is that CHS seems to enable stack lift no matter whether the contents of the X-register are zero or not. However, I have discovered that CHS only seems to enable stack lift on the 11C and 34C when the operand in the X register is not zero. If it is zero, CHS seems to do nothing, and when the 1 is added to the 0 in the X register the register is overwritten and the stack is dropped, so that the Y register holds not zero, as desired, but whatever was in Z register before the addition took place. If the value in the X register is anything but zero, the four steps above have the desired behaviour. I've confirmed that this undesired behavior is present on the HP-34C, HP-11C, HP-15C, and HP-16C. It is not present on the HP-10C or HP-12C. The HP-35 responds differently. I'd like to ask anyone to try Les' test on an HP-67 or HP-33C in particular, on the HP-25/25C and on other Spice-series models for comparison. I suspect that the undesired behavior may have been "inherited" in reused ROM code from the more-advanced predecessors. Thanks! -- KS Edited: 14 Feb 2007, 4:13 a.m.

 Re: 15C bug? [CHS and Stack Lift with zero]Message #12 Posted by Walter B on 14 Feb 2007, 7:00 p.m.,in response to message #11 by Karl Schneider My 33C (S/N 2241...) and 32E (2116...) behave like the 34C. 27 (1609...) and 21 (1507...) respond differently.

 Re: 15C bug? [CHS and Stack Lift with zero]Message #13 Posted by Karl Schneider on 15 Feb 2007, 4:27 a.m.,in response to message #12 by Walter B Hi, Walter -- Quote: My 33C (S/N 2241...) and 32E (2116...) behave like the 34C. 27 (1609...) and 21 (1507...) respond differently. Thank you for the tests. This may narrow it down. Now, if someone could try it with an HP-67: ```9 ENTER ENTER 0 ENTER CHS 1 is the stack correct or incorrect? 9 9 0 9 0 0 1 1 ``` -- KS

 Re: 15C bug? [CHS and Stack Lift with zero]Message #14 Posted by Walter B on 15 Feb 2007, 6:40 p.m.,in response to message #13 by Karl Schneider Hi, Karl, please note the stack will contain 1 0 9 9 in all 4 models I tested using 9 ENTER ENTER 0 ENTER CHS 1 Using non-zero values, e.g. 9 ENTER ENTER 2 ENTER CHS 1 instead, the stack of the Spices shows 1 -2 2 9 , of the Woodstocks 1 2 9 9 . Addendum: HP67 (S/N 1803...) shows 1 0 0 9 and 1 -2 2 9, respectively. HP45 performs like the Woodstocks, while HP35 displays -1 0 9 9 and -1 2 9 9. Regards, Walter Edited: 15 Feb 2007, 7:11 p.m.

 1970's calc's: CHS and Stack Lift with zeroMessage #15 Posted by Karl Schneider on 16 Feb 2007, 2:18 a.m.,in response to message #14 by Walter B Hi, Walter -- Thank you for conducting the tests on the 1970's models of HP calculators. (My LED-based models include only an HP-35 and an HP-34C.) It certainly seems that, while the pre-1976 models either had some performance issues or had not had their functional specification exactly defined, the HP-67 got it right. Then, a new flaw was introduced in the Spice series, which was then passed on to the "upper level" Voyagers. Could I ask you for one more test on the HP-67? 9 ENTER ENTER ENTER CLx CHS 1 Is the resulting stack ``` x y z t x y z t 1 0 9 9 or 1 9 9 9 ? ``` Here, the latter would be the desired response, because CLx is intended for clearing the x-register so that a new value can be input. Certainly, the CHS would be superfluous on a value of zero, but is it simply ignored? Was any distinction made between stack lift disabled by ENTER and stack lift disabled by CLx? Thanks, -- KS

 This might be called the "First 15c bug" ?Message #16 Posted by Gene on 16 Feb 2007, 8:44 a.m.,in response to message #15 by Karl Schneider Perhaps, after all these years? A very obscure one, at that...if it deserves to be called one at all.

 that is wanting it both waysMessage #17 Posted by bill platt on 16 Feb 2007, 10:45 a.m.,in response to message #15 by Karl Schneider If you want the latter behavior in your example, then you get that with the 11C/15c behavior. The problem is that you then have inconsistent behavior relative to the CHS call. Of course your keystroke sequence in the case is not one that would ever be of value logically. It reminds me a bit of synthetic programming. which some 41 experts relish but which is really totally abstruse and outside normal logical design intent. (OR apparent design intent. Who knows what HP engineers really wanted--perhaps they wanted undocumented synthetic possibility).

 Yes, a *bug* in the HP-15C and others [CHS/stack lift]Message #18 Posted by Karl Schneider on 17 Feb 2007, 2:52 a.m.,in response to message #17 by bill platt Hi, Bill -- Quote: If you want the latter behavior in your example, then you get that with the 11C/15C behavior. The problem is that you then have inconsistent behavior relative to the CHS call. More precisely, it would be inconsistent "lift-enabling" behavior after CHS, regarding ENTER and CLx. Quote: Of course your keystroke sequence in the case (9 ENTER ENTER ENTER CLx CHS 1) is not one that would ever be of value logically. Quite right -- "CLx CHS" on a Voyager-series model would exemplify a user error in interactive mode, and would have no practical use in a program. (Recall that CHS on a zero will not display a negative sign on a Voyager-series model; at least one non-zero digit must be present.) It would be nice if such an error could be ignored, but not at the expense of inconsistent stack-lift-enabling behavior, as exhibited by the Spice- and Voyager-series models for CHS performed upon a result of zero, versus upon a result other than zero. On the HP-15C, lift-enabling rules for the various commands were also established for complex-valued numbers. There is a footnote on page 211 of the HP-15C Owner's Handbook: Quote: "All digit entry functions are also neutral during digit entry. After digit entry termination, CHS and EEX are lift-enabling; CLx is disabling." This verbiage, along with my own examination and Walter B's HP-67 results lead me to a clear conclusion: The failure to re-enable a disabled stack lift upon CHS performed on a result of zero was a bug on at least these identified Spice- and Voyager-series models: HP-32E, HP-33E/C, HP-34C, HP-11C, HP-15C, HP-16C. This behavior is inconsistent with the logically-correct response first established with the predecessor HP-67, maintained in the HP-41 series, and later restored in the Pioneer series (HP-32S, HP-32SII, HP-42S). This bug was likely introduced into the Spice series and possibly transferred to the three Voyager-series models by re-use of ROM code. The bug may also be present on the HP-31E, HP-37E and HP-38E/C. Thanks to all. I'd say that we've got a bit of new material for Craig Finseth's pages regarding these particular modestly-afflicted calculator models. -- KS Edited: 18 Feb 2007, 2:46 a.m.

 Re: 1970's calc's: CHS and Stack Lift with zeroMessage #19 Posted by Walter B on 16 Feb 2007, 6:24 p.m.,in response to message #15 by Karl Schneider Hi Karl, HP67 shows 1 0 9 9 in this case. Woodstocks and Spices show 1 9 9 9. Regards, Walter Edited: 16 Feb 2007, 6:36 p.m.

 Re: 15C bug? [CHS and Stack Lift with zero]Message #20 Posted by bill platt on 16 Feb 2007, 10:51 a.m.,in response to message #14 by Walter B Quote: ```Using non-zero values, e.g. 9 ENTER ENTER 2 ENTER CHS 1 instead, the stack of the Spices shows 1 -2 2 9 ``` This is also the result for *both* 11c/15c and the Pioneers *and* the 12c. That the Woodstock comes up with 1 2 2 9 is yet a third variation. I don't understand it though. When you press CHS on a woodstock, don't you see a little minus sign light up in REEEED LEDs? Why did it disappear on pushing 1 onto the stack?

 Re: 15C bug? [CHS and Stack Lift with zero]Message #21 Posted by Walter B on 16 Feb 2007, 6:33 p.m.,in response to message #20 by bill platt Hi Bill, Quote: When you press CHS on a woodstock, don't you see a little minus sign light up in REEEED LEDs? Yes, I do. Quote: Why did it disappear on pushing 1 onto the stack? In fact, it didn't tell me, but it's gone :)

 Re: 15C bug? [CHS and Stack Lift with zero]Message #22 Posted by Cameron Paine on 14 Feb 2007, 8:23 p.m.,in response to message #11 by Karl Schneider Intriguing forensics. I have long held the belief, perhaps shared with many of you (other than Eric) that the Voyagers were specialisations of a common core of code. Karl's observation suggests that 10C and 12C shared one set of common code while 11C, 15C and 16C shared a different set. Thinking of their application, I'd have thought 10, 11 and 15 might share code and that 12 and 16 would be unique. Perhaps the code was always written from scratch and what we're seeing is two schools of design thought about the "correct" behaviour. It could also be that there's a "jump if zero" instruction in the CHS handler that branches to the "wrong" target and that the coder responsible didn't see the unintended consequence. This would mean that it's an accident of implementation that wasn't picked up during testing (because no one thought to test the "ridiculous" boundary case of 0 CHS). Cameron

 Re: 15C bug? [CHS and Stack Lift with zero]Message #23 Posted by Karl Schneider on 15 Feb 2007, 3:01 a.m.,in response to message #22 by Cameron Paine Hello, Cameron -- Quote: I have long held the belief, perhaps shared with many of you (other than Eric) that the Voyagers were specialisations of a common core of code. Karl's observation suggests that 10C and 12C shared one set of common code while 11C, 15C and 16C shared a different set. That may be overstating it; there is plenty of overlap in built-in functionality between these five models. However, it's noteworthy that the the 10C and 12C had a crude programming paradigm (no LBL, GSB, or insert/delete editing, limited conditional tests and no flags) and lacked the backarrow/backspace key. The 11C, 15C, and 16C had all these features. Although there is still much commonality, the 10C and 12C may have some ROM code lifted from previous models lacking the features, while the 11C, 15C and 16C may have "borrowed" more heavily from the more-sophisticated predecessors. That's my theory, anyway... Quote: Perhaps the code was always written from scratch and what we're seeing is two schools of design thought about the "correct" behaviour. I doubt that very much code was written from scratch unless necessary; too much work and testing went into algorithms and microprocessor instructions not to be re-used. The way I see it, only one way is correct: CHS on a result of zero (not a zero entered from keyboard) should re-enable stack lift. In a program, a "final value" of zero should not be processed differently than any non-zero final value. Quote: It could also be that there's a "jump if zero" instruction in the CHS handler that branches to the "wrong" target and that the coder responsible didn't see the unintended consequence. This is quite plausible, I think. The origin of this, though, probably lies in an earlier model. "Which one?" is the question. Whence came the flawed gene? -- KS

 Re: CHS and Stack LiftMessage #24 Posted by bill platt on 15 Feb 2007, 12:07 a.m.,in response to message #1 by Les Wright I must say, I am curious to hear what Valentin thinks of this. I just read my 11c manual and compared it to the 32sii manual, and I must say, these two statements are quite clear: ```"Digit Entry Termination "Most operations...terminate digit entry...(The 'CHS', '.', 'EEX', and '<' operations do not terminate digit entry). "Stack Lift ... "Neutral Operations "...Some operations, like 'CHS' and 'FIX' are neutral; that is, they do not alter the previous status of stack lift... "The following operations are neutral on the HP-11C: "...'CHS'* "*'CHS' is neutral during digit entry of a number from keys, as in 1, 2, 3, 'CHS' to enter -123; or 123'EEX'6'CHS' to enter 123 X 10^6. Otherwise, 'CHS' enables the stack." ``` Pay especial attention to this last statement. That's the crux of the matter. It should have enabled the stack to lift. (It is interesting that it doesn't read, "enables the stack LIFT.") It enables the stack to lift with *any other number* left in the X-register that is changed in sign by a 'CHS' command. That seems like a bug, doesn't it? But I am in shock. It just feels really squirmy to see any bugs in the 15c and 11c! I wonder if this bug has ever inadvertently bitten me? There are those occasional programs that drive you crazy..that just don't ever seem to debug... Interestingly, the 32sii manual doesn't go into this special detail regarding whether 'CHS' is applied to digit entry or to a pre-existing X-register number. Rather, 'CHS' is merely lumped into the "stack-lift enabling" category by omission from the neutral table. Edited: 15 Feb 2007, 12:09 a.m.

Go back to the main exhibit hall