▼
Posts: 875
Threads: 37
Joined: Jul 2005
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.
...
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
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?
▼
Posts: 875
Threads: 37
Joined: Jul 2005
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.
...
Posts: 2,761
Threads: 100
Joined: Jul 2005
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.
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
What does the 41C/42S do with "STO+ ST X" and the LastX register?
This is the same case.
- Pauli
▼
Posts: 2,761
Threads: 100
Joined: Jul 2005
I see your point. Fortunately on the HP-42S we have "RCL+ST X", which behaves differently regarding the LastX register :-)
Gerson.
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
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
▼
Posts: 875
Threads: 37
Joined: Jul 2005
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.
Posts: 3,283
Threads: 104
Joined: Jul 2005
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.
Posts: 3,229
Threads: 42
Joined: Jul 2006
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
▼
Posts: 556
Threads: 9
Joined: Jul 2007
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.
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
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.
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
We should also get sections for carry and overflow in integer mode like the 16c manual has.
- Pauli
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
For carry please see p. 55 :-)
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
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
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
Literally copying old manuals is little fun :-( So I may point to that manual instead ...
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
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.
Posts: 1,253
Threads: 117
Joined: Nov 2005
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
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
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
|
