WP 34S - INC X and RCL L (LASTx)

[Gerson W. Barbosa]

Is there a reason INC X doesn't affect the register L (LASTx)? Thanks!

[Marcus von Cube, Germany]

Simplicity. X is just another register. We would need to check for X as a special case (not only for INC).

[Andrés C. Rodríguez (Argentina)]

I think it may be better not to save LastX when just incrementing (or decrementing) a register, to avoid the loss of generality. And, eventually, LastX may well end containing a "1" as the "last" operand added or substracted...

[Gerson W. Barbosa]

I can't think of a situation in which updating LastX after INC or DEC would be inconvenient. On the other hand here it would save two steps:

001 LBL A		001 LBL A

002 1			002 INC X

003 x<>y		003 RCL L

004 +			    ...

005 RCL L

    ...

[Paul Dale]

How about:

001 LBL A

002 ENTER

003 INC Y

    ...

No steps saved :-)

On the other hand, INC not setting LastX has been a boon several times.

- Pauli

Edited: 26 Dec 2011, 4:34 p.m.

[Gerson W. Barbosa]

That'll do, thanks!

Gerson.

[fhub]

Quote:

---

Simplicity. X is just another register. We would need to check for X as a special case (not only for INC).

---

But it's definitely inconsistent! IMO one should really be able to trust that LastX (L) is set to X whenever X is changed. Otherwise we would need a (complete!) table which operations set L and which not.

[Gene Wright]

I do agree that consistency is to be preferred.

What reasons are there for not incrementing X specifically?

[Paul Dale]

Get out your trusty 41c and execute ISG X. Is the old X saved in LastX? No. The same is true on the 34S for all six increment and decrement operations. INC and DEC are there because I've seen way too many cases of "ISG nn NOP" in programs. i.e. they are very useful short cuts. In this way INC and DEC are completely consistent with their kindred commands.

Not setting LastX for these operations has actually been a bonus more times than not. There have been a number of rather clever pieces of code written that rely on this behaviour. As an aside: I've contemplated introducing fast arithmetic operations that allow you to add, subtract, multiply or divide X and a constant argument. These would most likely not save LastX either.

Finally, as Marcus mentioned, I'm very unlikely to introduce LastX saving here, checking for X specially would require extra code which we kind of don't have space for. What about ISG, DSE, X<> or even CLx ? They change X but nobody has ever called for them to set LastX that I'm aware of? Must they too be modified to save LastX even though it breaks backward compatibility with everything?

Sorry, but I think it is consistent the way it is and that it is more useful not setting LastX. I'm going to be difficult to convince otherwise I suspect.

- Pauli

[Gerson W. Barbosa]

Quote:

---

What about ISG, DSE, X<> or even CLx ? They change X but nobody has ever called for them to set LastX that I'm aware of?

---

Perhaps because ISG and DSE are used primarily for loop control, unlike INC and DEC. My opinion is the same as Franz's above, but considering that lots of (built-in?) code have been written with this behavior in mind, better keep it this way.

Gerson.

[Paul Dale]

Quote:

---

Perhaps because ISG and DSE are used primarily for loop control, unlike INC and DEC.

---

Go through the 41c software archive -- ISG and DSE are very commonly used for their +1 or -1 effect and are often followed by a NOP instruction: DEG, empty alpha and the like. Not always of course but surprisingly often -- this is the heritage of INC and DEC.

- Pauli