Recall Arithmetic: The haves and have-nots

[Didier Lachieze]

(05-22-2019 09:33 AM)[kby] Wrote:  Can’t really buy that explanation for the -65. Storage arithmetic is not merged so it would not be odd to have recall arithmetic unmerged.

Well, with unmerged recall arithmetic it takes one more step compared to standard recall. For example: RCL + 2 is 3 steps, while RCL 2 + is 2 steps because RCL 2 is a partially merged instruction.
Without recall arithmetic you loose the T-register, but does it justify the full implementation of recall arithmetic? I would say that during the design of the HP-65 (the first programmable pocket calculator) the designers may not have seen any advantage to implementing recall arithmetic.

[[kby]]

(05-22-2019 12:57 PM)Didier Lachieze Wrote:  

(05-22-2019 09:33 AM)[kby] Wrote:  Can’t really buy that explanation for the -65. Storage arithmetic is not merged so it would not be odd to have recall arithmetic unmerged.

Well, with unmerged recall arithmetic it takes one more step compared to standard recall. For example: RCL + 2 is 3 steps, while RCL 2 + is 2 steps because RCL 2 is a partially merged instruction.
Without recall arithmetic you loose the T-register, but does it justify the full implementation of recall arithmetic? I would say that during the design of the HP-65 (the first programmable pocket calculator) the designers may not have seen any advantage to implementing recall arithmetic.

I agree that programmatically it is of limited use. But sometimes keeping something in T in particular is useful because it duplicates downward as the stack drops. Sometimes the extra step might still be worth it.

That said it should also not have cost “a lot” unless the ROMs were full. It should not have taken anything special to implement the programming had the sequence already “just worked” like STO+-*/ does—no extra op-codes, no extra instruction buffers. The actual code for the ROMs to implementthe sequence should have been fairly trivial to port from the -45, one would think.

[Thomas Okken]

(06-19-2015 06:29 PM)Dave Britten Wrote:  Fortunately, you can emulate it easily enough. RCL- n becomes X<> n, STO- n, X<> n.

Not quite: RCL arithmetic affects LASTx, while STO arithmetic does not.

(On the HP-42S, at least -- I'm not familiar with how RCL arithmetic works on the other models mentioned earlier.)

[fred_76]

The 35S has it and it is much faster than :

RCL A
+

You can also do more complex tasks in the equation mode but it s extremely slower.

[Joe Horn]

(05-22-2019 10:47 PM)Thomas Okken Wrote:  RCL arithmetic affects LASTx, while STO arithmetic does not.

(On the HP-42S, at least -- I'm not familiar with how RCL arithmetic works on the other models mentioned earlier.)

It was fun checking these:
RCL arithmetic also DOES change LASTX on the HP 35s, 33s, 32SII, and 45 (and DM42 of course).
RCL arithmetic does NOT change LASTX on the 15C or 15C LE.
STO arithmetic does NOT change LASTX on any of the above models.
(I don't have any other models with recall arithmetic).

[Valentin Albillo]

(05-27-2019 01:02 AM)Joe Horn Wrote:  STO arithmetic does NOT change LASTX on any of the above models.

Of course it doesn't. Why would you expect STO arithmetic to change LASTX since the value in X is unaffected ?

Unless you're thinking of something like ST+ ST X, a la HP-41.

V.
.

[Joe Horn]

(05-27-2019 02:23 AM)Valentin Albillo Wrote:  

(05-27-2019 01:02 AM)Joe Horn Wrote:  STO arithmetic does NOT change LASTX on any of the above models.

Of course it doesn't. Why would you expect STO arithmetic to change LASTX since the value in X is unaffected ?

That's quite right, and I wasn't expecting it to. My posting was a reply to Thomas Okken's post in which he wrote, "RCL arithmetic affects LASTx, while STO arithmetic does not." Since he wrote this about the HP-42S, I extended his observation to the other models.