WP 34S and 31S bugs and fixes

[Bit]

(01-12-2015 01:14 AM)Paul Dale Wrote:  

(01-12-2015 12:48 AM)Bit Wrote:  This wouldn't be difficult to change if that's desired, see the patch below. Solve and integrate could probably be adapted in a similar way. (STOS/RCLS aren't currently used by any XROM routines so it's safe to change their behavior when called from XROM.)

For consistency, f' and f" should also do the same and likely solve and integrate.

Should the stack or some portion of it be preserved when passed to the user's routine? What if that routine makes changes? Currently, A .. D aren't changed and aren't filled by these and the user can do what they want with them even if they are in the stack.


- Pauli

I think XEQUSR does currently fill the whole stack (including A .. D if using an 8-level stack) before executing the user's routine, but correct me if I'm wrong. do_usergsb() calls usergsb_common() before calling fill(), and usergsb_common() moves the program counter out of the XROM area.

Filling the stack is consistent with what some HP calculators do and IMO it's the right thing to do as the user's routine shouldn't assume anything about the stack other than it contains the input. Restoring the whole stack after the sum etc. functions return would make sense and if the user's routine needs additional storage, it should use registers that aren't part of the stack.

[Paul Dale]

(01-12-2015 01:31 AM)Bit Wrote:  I think XEQUSR does currently fill the whole stack (including A .. D if using an 8-level stack) before executing the user's routine, but correct me if I'm wrong. do_usergsb() calls usergsb_common() before calling fill(), and usergsb_common() moves the program counter out of the XROM area.

I think you're right. It used to only do four registers rather than four or eight but it looks like Marcus changed that with the other XROM support.

Quote:Filling the stack is consistent with what some HP calculators do and IMO it's the right thing to do as the user's routine shouldn't assume anything about the stack other than it contains the input. Restoring the whole stack after the sum etc. functions return would make sense and if the user's routine needs additional storage, it should use registers that aren't part of the stack.

Probably one for Walter.

Consistency across, solve, integrate, f', f", sum and product (current) or saving all of the stack for some but not all (suggestion). Saving the stack uses a lot more temporary registers which was something I worked hard to not do when coding these.

We might also be able to save more of the stack for all these.

The documentation will have to change either way I suspect -- it isn't right now at least.


- Pauli

[Bit]

(01-12-2015 01:51 AM)Paul Dale Wrote:  Consistency across, solve, integrate, f', f", sum and product (current) or saving all of the stack for some but not all (suggestion).

All of the above should behave consistently IMO.

(01-12-2015 01:51 AM)Paul Dale Wrote:  Saving the stack uses a lot more temporary registers which was something I worked hard to not do when coding these.

Another option is to save the stack only when invoked directly by the user (not from a program). That's when the convenience of not losing the stack matters the most, and that's when using some extra temporary registers is least likely to be a problem.

[Paul Dale]

(01-12-2015 02:00 AM)Bit Wrote:  Another option is to save the stack only when invoked directly by the user (not from a program). That's when the convenience of not losing the stack matters the most, and that's when using some extra temporary registers is least likely to be a problem.

It is also inconsistent which won't please Walter


- Pauli

[Bit]

(01-12-2015 02:31 AM)Paul Dale Wrote:  

(01-12-2015 02:00 AM)Bit Wrote:  Another option is to save the stack only when invoked directly by the user (not from a program). That's when the convenience of not losing the stack matters the most, and that's when using some extra temporary registers is least likely to be a problem.

It is also inconsistent which won't please Walter


- Pauli

AFAICS work on the WP 34S has very much been about finding the best compromises to bring the most out of the very limited hardware, and some of those compromises are by necessity not pretty but useful. I suppose the pros and cons of saving the stack will need to be carefully considered.

Can you or anyone estimate how likely it is that we'd run into problems if the mentioned functions always saved the stack?

[Paul Dale]

(01-12-2015 05:44 AM)Bit Wrote:  AFAICS work on the WP 34S has very much been about finding the best compromises to bring the most out of the very limited hardware, and some of those compromises are by necessity not pretty but useful.

Not really. Consistency for the user and numeric accuracy were the two main driving factors.


- Pauli

[walter b]

(01-12-2015 07:08 AM)Paul Dale Wrote:  

(01-12-2015 05:44 AM)Bit Wrote:  AFAICS work on the WP 34S has very much been about finding the best compromises to bring the most out of the very limited hardware, and some of those compromises are by necessity not pretty but useful.

Not really. Consistency for the user and numeric accuracy were the two main driving factors.

Exactly. Straining the HW to its limits was a side effect, also caused by some user requests.

d:-)

[Marcus von Cube]

(01-12-2015 05:44 AM)Bit Wrote:  Can you or anyone estimate how likely it is that we'd run into problems if the mentioned functions always saved the stack?

They will use more memory. This is especially of concern if called recursively (solve an integral of sums of derivatives). It might quickly exhaust the return stack which is holding the local registers.

[Bit]

(01-12-2015 07:20 AM)walter b Wrote:  

(01-12-2015 07:08 AM)Paul Dale Wrote:  

(01-12-2015 05:44 AM)Bit Wrote:  AFAICS work on the WP 34S has very much been about finding the best compromises to bring the most out of the very limited hardware, and some of those compromises are by necessity not pretty but useful.

Not really. Consistency for the user and numeric accuracy were the two main driving factors.

Exactly. Straining the HW to its limits was a side effect, also caused by some user requests.

d:-)

Fair enough. What I had in mind was primarily the internal C code, which has a lot of very useful but not necessarily elegant solutions. I hope my comment didn't offend anybody, it was meant to be praise.

[Paul Dale]

(01-12-2015 11:39 PM)Bit Wrote:  Fair enough. What I had in mind was primarily the internal C code, which has a lot of very useful but not necessarily elegant solutions. I hope my comment didn't offend anybody, it was meant to be praise.

It became less and less elegant as we crammed more and more in We also traded speed for space a lot.

No offence taken in the least. In fact the possibility to offend didn't even enter my mind!

- Pauli

[Bit]

The CORR function produced a Bad Mode Error in integer mode when you pressed [g] [r], unlike all the other statistical functions, which are just ignored. I've committed a fix.

[walter b]

(01-17-2015 02:34 AM)Bit Wrote:  The CORR function produced a Bad Mode Error in integer mode when you pressed [g] [r], unlike all the other statistical functions, which are just ignored.

Indeed. Thanks for finding! "r" should be ignored as well. (Luckily that's a bug which can't appear on the WP 31S ).

d:-)

[Bit]

Complex catalogs can be invoked in integer mode by holding down [h] and pressing the key for the catalog. I suppose that's not intentional. Walter, let me know if it should be fixed.

[Paul Dale]

(01-17-2015 05:16 AM)Bit Wrote:  Complex catalogs can be invoked in integer mode by holding down [h] and pressing the key for the catalog. I suppose that's not intentional. Walter, let me know if it should be fixed.

Complex DROP and complex CONJ are the only two functions there that might be worthwhile in integer mode. I'd say get rid of the access.


Pauli

[walter b]

(01-17-2015 05:26 AM)Paul Dale Wrote:  

(01-17-2015 05:16 AM)Bit Wrote:  Complex catalogs can be invoked in integer mode by holding down [h] and pressing the key for the catalog.

Complex DROP and complex CONJ are the only two functions there that might be worthwhile in integer mode. I'd say get rid of the access.

I concur.

d:-)

[Bit]

(01-17-2015 05:35 AM)walter b Wrote:  

(01-17-2015 05:26 AM)Paul Dale Wrote:  Complex DROP and complex CONJ are the only two functions there that might be worthwhile in integer mode. I'd say get rid of the access.

I concur.

d:-)

While we're at it:
1. I'd disable the DEG/RAD/GRAD commands as well, because not only is there no need for them in integer mode, there's no indication of the selected angular mode or that anything has been changed.
2. I'm not sure the RND, IP and FP commands make much sense in integer mode.
Please comment.

[Paul Dale]

(01-17-2015 05:47 AM)Bit Wrote:  2. I'm not sure the RND, IP and FP commands make much sense in integer mode.
Please comment.

These were left deliberately, the idea being all functions that made any kind of sense worked in both modes.

They do do something in integer mode, albeit something rather boring.


- Pauli

[Marcus von Cube]

Thanks to Bit for his detective work! I've committed the latest changes.

There is something to consider when removing functions from catalogs in integer mode: In a program they can nevertheless be entered and executed in integer mode because the mode switch and the command entry are independent. Thus, there must always be a runtime check in the command execution to prevent undesired behavior. Many commands are just dummies in integer mode as Pauli has already explained.

[walter b]

(01-17-2015 05:47 AM)Bit Wrote:  1. I'd disable the DEG/RAD/GRAD commands as well, because not only is there no need for them in integer mode, there's no indication of the selected angular mode or that anything has been changed.
2. I'm not sure the RND, IP and FP commands make much sense in integer mode.

As Pauli wrote, we kept everything which might make at least some sense.

We kept even the logs and roots, so RND, IP, and FP don't hurt.

While DEG and GRAD may make some sense, RAD and H.MS don't. And conversions don't either. So, for sake of coherence, DEG, RAD, GRAD, H.MS, and the menu CONV should be disabled in integer mode.

Certainly, "advanced statistics" doesn't make sense, so this should be disabled as well (i.e. the entire menus STAT and PROB). Not so sure about summation*. And one could think about [x_bar] which inevitably goes with [s]. You see, statistics isn't black or white but also grey.

d:-)

(Luckily, my reasoning matches the manual so far AFAICS - I crosschecked after writing the text above.
* I found we also disabled summation - for sake of completeness, I'd guess.)

[Bit]

(01-17-2015 10:06 AM)Marcus von Cube Wrote:  Thanks to Bit for his detective work! I've committed the latest changes.

There is something to consider when removing functions from catalogs in integer mode: In a program they can nevertheless be entered and executed in integer mode because the mode switch and the command entry are independent. Thus, there must always be a runtime check in the command execution to prevent undesired behavior. Many commands are just dummies in integer mode as Pauli has already explained.

I forgot to mention here that I had committed the patch to disable complex catalogs in integer mode.

I didn't investigate the issue fully but at first glance I don't see any problem with the current behavior of operations that can be invoked from programs in integer mode. Most complex functions fail due to the mode check, only a few succeed, like ^cCROSS, and those seem to perform the correct calculations, even though they aren't very useful. Unlike the complex catalogs, which IMO could be confusing if they show up in integer mode, if someone programs those few complex operations that work, they probably know exactly what they're doing.