WP 34s stack preservation

[signals]

First, I'd like to say "Thanks!" to everyone who has been involved with the WP 34s project. I don't know how I missed it until now, but I just discovered it recently. Better late than never... I elected to buy one pre-made from hpcalc.org because I need a calculator, not another project to add to the pile, but it is supposed to be here tomorrow and I'm very excited.

I've never owned a traditional RPN calculator before. I bought an HP 48sx sometime around 1991 and used it exclusively ever since. Well, at least until its screen died and I replaced it with a 48g from eBay. Now, it is dying, and I'm in need of a new one. I no longer need all of the fancy graphing and such, I'll use a computer for that. All I need is a quick number cruncher and the WP 34s seems like a perfect fit. Unfortunately, the finite stack is difficult for me to get my mind around and I'm having trouble figuring out best practice for preserving the stack when a program is called. It's easy in the RPL world; just remove anything you put on the stack, and it will be the same as when you started.

Anyway, I've discovered the STOS and RCLS commands and have been storing the stack into local registers at the start of my program and recalling them at the end. It works, but I have to allocate 4 extra LRs that I probably don't need to hold a possible 8 level stack. So, I've been wondering, what is the correct way to do this?

I know there's a SSIZE? command which will tell me the stack size, and theoretically, I could use that to decide how many LRs I need for the STOS command, but I as soon as I call SSIZE? the stack lifts, and I've lost T (or D.) Then I have to add my local LR usage to the number so I can call LocR, and I lift the stack again for the addition and lose the original Z.

I could use global registers, but that violates the "leave the calculator as you found it" behavior that I expect when running a program. Am I just stuck with blowing 8 LRs on stack preservation? Or am I missing something obvious? How is this usually handled?

Go easy on me. I've never touched a keystroke programmable RPN calculator until a few days ago, so I'll be the first to admit that I probably just don't know something basic. As good as the manual is (and it is good) the sheer amount of information in it is overwhelming and it will probably take me a few weeks, and a few dumb questions, to grok it all.

Thanks.

[Marcus von Cube]

LocR if called twice resizes the local register area. So you can allocate 8 registers first and reallocate to 4 registers if the stack size allows it. Here is what should work:

Code:

LocR 8
STOS .00
SSIZE?
LocR->X

If you need more local registers just add the amount to X before the final call to LocR. Access to the stack contents before this sequence is easy: just recall from .00 to .07. If you want to return a specific value to the caller on the stack, store it to the corresponding register before the final RCLS .00.

I must admit that I didn't test the code.

[signals]

Wow, thanks! That's exactly the strategy that was eluding me, and I hadn't even thought about modifying the contents of the registers that held the stack before calling RCLS. That will save a bunch of steps.

I can't remember the last time I had this much fun programming (or trying to program) a computer...

[Marcus von Cube]

(04-01-2015 06:31 PM)signals Wrote:  I can't remember the last time I had this much fun programming (or trying to program) a computer...

Now you can imagine how much fun it was to create the 34S. The local register stuff and the variable memory boundaries in the 34S design are my work.

[signals]

Very impressive!

When I posted the original question, I was wondering why STOS didn't just push the stack into the call stack frame like LocR does so you didn't have to worry about stack size. Obviously, now that you've explained it to me, it is because it wouldn't be available for STO/RCL commands if done that way.

It's clear that an awful lot of thought was put into the design of this calculator, and that it was made by people who actually wanted to use it. I'm sure the HP engineers who created the 35 and its succesors would be very impressed with your work.