I apologize in advance if this question has been asked and answered previously. I did read the fine manual, and attempted to search the archives, but could not find the answer. The question is, is it intentional behavior that register L is not updated when applying the INC function to the value in the stack X register. In other words, this happens:

Keystroke X display

1 1

ENTER 1

2 2

+ 3

INC X 4

RCL L 2 (equals the “2” used in the plus operation above, which was not the last value in X)

Instead of this:

Keystroke X display

1 1

ENTER 1

2 2

+ 3

INC X 4

RCL L 3 (equals the “3”, which was the last value in X prior to the INC X function)

Thanks.

...

If I'd document it the way it works (i.e. not loading L), it would be a feature ;-) After all, LASTx is primarily for error recovery IMHO, so not loading L in INC doesn't hurt, it's just not documented. Or is there any *need* for loading L here?

Well, I "needed" it when I determined that it did not operate that way :-)

LASTx’s primary use may be error recovery, but seeing as how functions like RCL+L, RCL-L, X<>L, etc. are allowed, it is also useful for general data manipulation. So should INC X, which is after all a function that could be called “X+1”, load L just like any* other function operating on X?

* - I did not do an exhaustive search to determine if there are any other situations where something is done to the value in X that does not load L.

...

This behaviour is intentional. Likewise for DEC. The only register it might make sense for is X and if we did it then, we'd have an exception which is bad. Better for these to just not touch L unless it is their argument.

- Pauli

One of these days I intended to use **INC X** in a program, but I quit because it didn't update the **L** register. I shifted to the HP-42S instead and used **NOT**, even though this is equivalent to **1 + +/-** (for integers in the valid range). I think both **DEC** and **INC** should update the **L** register, but only when they act on **X**, if this is not difficult to implement.

What does the 41C/42S do with "STO+ ST X" and the LastX register?

This is the same case.

- Pauli

I see your point. Fortunately on the HP-42S we have "RCL+ST X", which behaves differently regarding the LastX register :-)

Gerson.

On the 34S RCL register arithmetic sets L appropriately too :-) This makes sense since X is always changes. For STO arithmetic (and INC and DEC), X isn't always changed so L is left alone. There is some logic here :-)

- Pauli

I see your points. Probably a trivial issue, one that will never impact me again. I just wanted to make sure it was intentional.

In this case, I was to trying create x(x+1) without disturbing the stack by the following steps:

INC X

RCLxL

But the following does the job:

X^2

RCL+L

...

*Edited: 3 Oct 2012, 7:40 a.m. *

Quote:

This behaviour is intentional. Likewise for DEC...

Than it should be stated in section "last x behaviour" if one exists. Similar to stack lift/disable characteristic of different functions. Intuitively I would think DEC would load L with X.

I certainly wouldn't argue about such a minor point but my SandMath's INCX and DECX functions do store X in L.

If you consider Inc() and Dec() to be -trivial- functions then x is their argument.

However DSE/ISG ST X do not save it, so that's supporting your approach.

Either way is good, a consistent implementation is better... but "consistency is in the eye of the beholder"

Cheers,

'AM

Remember the 34S's INC and DEC take a register argument and increment or decrement that. In fact, the share code with DSE/ISG/DSZ/iSZ/DSL/ISE.

If we'd implemented an explicit INCX/DECX, it would have saved X into L.

Additionally, my experience with INC/DEC supports the don't touch L viewpoint. I've written plenty of programs where leaving L intact was a benefit. Of course, most programs really don't care either way.

- Pauli

To add to Pauli's comment, what about INC->nn where nn contains 100? Updating LastX would be dependent on the data, not only on the command alone. Looks like a Pandoara's box to me which should be better left unopened.

Quote:

Than it should be stated in section "last x behaviour" if one exists. Similar to stack lift/disable characteristic of different functions. Intuitively I would think DEC would load L with X.

There isn't such a section yet, but it may change ;-) OTOH, stack lift should be documented completely.

We should also get sections for carry and overflow in integer mode like the 16c manual has.

- Pauli

For carry please see p. 55 :-)

That's seven of the carry altering functions. See the 16c manual page 98 for some more. That is still not a comprehensive list.

- Pauli

Literally copying old manuals is little fun :-( So I may point to that manual instead ...

I find 55 commands that change carry and/or overflow. The 16c manual only lists 16 commands.

Command Carry Overflow

+ X X

- X X

times X

/ X zero

LCM X

X^2 X

X^3 X

+/- X

ABS X

DBL[times] zero

DBL/ X zero

DBLmod zero

DBLrmdr zero

SL X

SR X

ASR X

RR X

RL X

RRC X

RLC X

SQRT X

y^x X X

LG2 X

2^x X X

LOG X

10^x X

(-1)^x X

FIB X

RECV1 X

LN X X

E^x X X

CUBERT X X

x! X X

GAMMA X X

LOGXY X X

COMB X X

PERM X X

XROOT X X

INC X X

DEC X X

ISZ X X

DSZ X X

ISG X X

DSE X X

ISE X X

DSL X X

STO+ X X

STO- X X

STO[times] X

STO/ X zero

RCL+ X X

RCL- X X

RCL[times] X

RCL/ X zero

- Pauli

*Edited: 4 Oct 2012, 5:41 a.m. *