WP34s: IDIV and the stack

[Dieter]

I am currently experimenting with some calendar routines on the 34s where the IDIV command often comes in handy. Since these routines are supposed to work with four as well as eight steck levels I checked them in either mode. This is where I discovered an unexpected behaviour of the IDIV command. With SSIZE 8 set, register T seems to get copied down to Z as the stack drops while the higher levels A to D do not change at all – just as it would happen in SSIZE 4.

Example:
Fill the stack with eight values...

Code:

88 [ENTER] 77 [ENTER] 66 [ENTER] 55 [ENTER] 44 [ENTER] 33 [ENTER] 22 [ENTER] 11

=>   D: 88
     C: 77
     B: 66
     A: 55
     T: 44
     Z: 33
     Y: 22
     X: 11

...and then do an integer division:

Code:

[IDIV]

=>   D: 88                     D: 88
     C: 77                     C: 88
     B: 66                     B: 77
     A: 55      instead of     A: 66
     T: 44                     T: 55
     Z: 44                     Z: 44
     Y: 33                     Y: 33
     X:  2                     X:  2

In other words: IDIV does not seem to handle the stack correctly in SSIZE 8 mode.
I am using a physical 34s with firmware 3.3 3666 (including printer and timer support).

Dieter

[Bit]

(01-12-2015 06:58 PM)Dieter Wrote:  This is where I discovered an unexpected behaviour of the IDIV command. With SSIZE 8 set, register T seems to get copied down to Z as the stack drops while the higher levels A to D do not change at all – just as it would happen in SSIZE 4.

Confirmed, and it affects other commands, too.

It's related to forcing a four-level stack for XROM code outside of xIN: cmdxout() resets XromFlags.xIN before calling lower() or lift() and stack_size() pretends the stack has only four levels because the PC is still in XROM at that point. The fix is probably not as simple as delaying the reset of XromFlags.xIN because that flag also affects reg_address(). Temporarily zeroing out the PC would probably do the trick but it isn't a very elegant solution.

It's up to Pauli and Marcus to decide how they'd like to resolve the problem. Personally I'd reexamine whether forcing a four-level stack for XROM code is really necessary.

[Paul Dale]

Looks like a bug again, I thought we'd handle this case or at least did.

(01-12-2015 06:58 PM)Dieter Wrote:  This is where I discovered an unexpected behaviour of the IDIV command. With SSIZE 8 set, register T seems to get copied down to Z as the stack drops while the higher levels A to D do not change at all – just as it would happen in SSIZE 4.

(01-12-2015 11:42 PM)Bit Wrote:  It's up to Pauli and Marcus to decide how they'd like to resolve the problem. Personally I'd reexamine whether forcing a four-level stack for XROM code is really necessary.

The four level forced stack was done to save having to special case the solve and integrate code when we introduced variable stack sizes. Most of XROM came a lot later, so it was easier to remain stuck with this decision than to rework solve and integrate to be more stack friendly -- they can't call XIN, so have to do everything themselves and they are not an easy piece of coding.


To me, the fix would be doing the correct stack operations in XOUT, Marcus?


Pauli

[Bit]

(01-13-2015 12:00 AM)Paul Dale Wrote:  Looks like a bug again, I thought we'd handle this case or at least did.

(01-12-2015 06:58 PM)Dieter Wrote:  This is where I discovered an unexpected behaviour of the IDIV command. With SSIZE 8 set, register T seems to get copied down to Z as the stack drops while the higher levels A to D do not change at all – just as it would happen in SSIZE 4.

(01-12-2015 11:42 PM)Bit Wrote:  It's up to Pauli and Marcus to decide how they'd like to resolve the problem. Personally I'd reexamine whether forcing a four-level stack for XROM code is really necessary.

The four level forced stack was done to save having to special case the solve and integrate code when we introduced variable stack sizes. Most of XROM came a lot later, so it was easier to remain stuck with this decision than to rework solve and integrate to be more stack friendly -- they can't call XIN, so have to do everything themselves and they are not an easy piece of coding.


To me, the fix would be doing the correct stack operations in XOUT, Marcus?


Pauli

Another possibility is to have solve and integrate adjust the stack size explicitly. It'd mean a few additional XROM instructions but simplified C code.

[Marcus von Cube]

(01-13-2015 12:00 AM)Paul Dale Wrote:  To me, the fix would be doing the correct stack operations in XOUT, Marcus?

I agree. I've moved the handling of the PC (do_rtn) up in order to get it out of XROM space for subsequent calls to lift() or lower(). I've made a short test with IDIV and it seems to be working now. Some more testing might be required. Solve, integrate, sum and product aren't affected at all because they don't use the xIN/xOUT mechanics but other XROM based commands are.

[walter b]

(01-13-2015 11:47 AM)Marcus von Cube Wrote:  Solve, integrate, sum and product aren't affected at all because they don't use the xIN/xOUT mechanics but other XROM based commands are.

For sake of clarity, please let me quote what's in XROM (from p. 132 of 374 of the current manual):

Quote:Therein live some 30% of all command routines (e.g. f’(x) and f”(x), SLV and SLVQ, ∫, Π and Σ, all statistical distributions, orthogonal polynomials, the functions AGM, Bn, Bn*, ERF, ERFC, FIB, gd and its inverse, NEXTP, Lambert’s W and its inverse, Euler’s Beta, Riemann’s Zeta, and most functions operating in complex domain).

Hope that helps identifying the "other" commands which need testing.

d:-)

[Marcus von Cube]

(01-13-2015 01:04 PM)walter b Wrote:  Hope that helps identifying the "other" commands which need testing.

Thanks for the list. Since only the stack mechanics have been updated it should suffice to test just a few of them, depending on their number of consumed/returned stack levels.

[Bit]

(01-13-2015 02:22 PM)Marcus von Cube Wrote:  

(01-13-2015 01:04 PM)walter b Wrote:  Hope that helps identifying the "other" commands which need testing.

Thanks for the list. Since only the stack mechanics have been updated it should suffice to test just a few of them, depending on their number of consumed/returned stack levels.

I've tested several (but not all) functions, in complex and integer modes, too. Everything looked good. The 31S should eventually get the same treatment as it also exhibits the problem.

[Marcus von Cube]

(01-14-2015 02:38 AM)Bit Wrote:  The 31S should eventually get the same treatment as it also exhibits the problem.

You are right. I forgot that it supports the eight level stack, too. I'll take care later today.

[Marcus von Cube]

(01-14-2015 07:21 AM)Marcus von Cube Wrote:  You are right. I forgot that it (the 31S) supports the eight level stack, too. I'll take care later today.

Today is today...

I did a rebuild but no testing. Please download the emulator and play with it.

[Bit]

(01-14-2015 04:12 PM)Marcus von Cube Wrote:  

(01-14-2015 07:21 AM)Marcus von Cube Wrote:  You are right. I forgot that it (the 31S) supports the eight level stack, too. I'll take care later today.

Today is today...

I did a rebuild but no testing. Please download the emulator and play with it.

It looks good to me.

[BarryMead]

I understand that the 31s has 8 levels of stack, but does it have the IDIV? If so I couldn't find it.
I did test the 3726 version of both calculators and found no more issues with stack behavior, but was
unable to test the IDIV on the 31s emulator, because I could not find this function in the "more" catalog
or any other catalog that I looked in. Am I missing something?

[walter b]

(01-17-2015 04:40 AM)BarryMead Wrote:  Am I missing something?

No, you aren't. The WP 31S provides RMDR and MOD, but no IDIV.

d:-)

[BarryMead]

Were there ANY functions from your list of XROM functions that were expected to exhibit a stack problem similar to the IDIV function in the wp34s, that are also in the wp31s? At first glance I did not notice any that were. I didn't have the 31s pdf open to the functions page when I made my scan however, so I probably
missed some just going from memory.

[Bit]

(01-17-2015 04:53 AM)BarryMead Wrote:  Were there ANY functions from your list of XROM functions that were expected to exhibit a stack problem similar to the IDIV function in the wp34s, that are also in the wp31s? At first glance I did not notice any that were. I didn't have the 31s pdf open to the functions page when I made my scan however, so I probably
missed some from memory.

The function || (OP_PARAL), that calculates (x^-1+y^-1)^-1, used to be affected by this problem.

[BarryMead]

(01-17-2015 05:08 AM)Bit Wrote:  The function || (OP_PARAL), that calculates (x^-1+y^-1)^-1, used to be affected by this problem.

Has this been fixed? I still see the stack copy at the T register not the D register (with SSIZE 8) when I invoke the || function on the 3726 release of the wp34s emulator. I couldn't find the || function on the wp31s emulator or manual.

[Bit]

(01-17-2015 03:19 PM)BarryMead Wrote:  

(01-17-2015 05:08 AM)Bit Wrote:  The function || (OP_PARAL), that calculates (x^-1+y^-1)^-1, used to be affected by this problem.

Has this been fixed? I still see the stack copy at the T register not the D register (with SSIZE 8) when I invoke the || function on the 3726 release of the wp34s emulator. I couldn't find the || function on the wp31s emulator or manual.

I'm not sure why you see the problem in build 3726. I tried the Windows emulator and compiled the Linux/Qt emulator as well, and both worked correctly.

The || function is right above ³√ in the MORE catalog of the 31S.

[BarryMead]

(01-17-2015 03:54 PM)Bit Wrote:  I'm not sure why you see the problem in build 3726. I tried the Windows emulator and compiled the Linux/Qt emulator as well, and both worked correctly.

The || function is right above ³√ in the MORE catalog of the 31S.

Sorry I didn't get enough sleep last night, and my last comment was invalid due to pilot error.