HP Forums

Full Version: Dual Stack Design Question
You're currently viewing a stripped down version of our content. View the full version with proper formatting.

Hello All,

I am thinking about updating and old HP41-based design of a Windows application for a programmable RPN calculator. My question is this regarding the stack. How do you feel about having a secondary stack to push and pop intermediate results. HP designed the older calculator with a fixed 4-register autmatic stack. We often used it to store intermediate results when calculations allowed this. Otherwise, we store results in memory registers and recall them when we need to. How about a SECONDARY stack (say with 10 registers) to which we push intermediate results and pop them back (to the main stack) when we need them???


How about a single stack of arbitrary depth?

The nice thing about two stacks is that you can seperate them logically. So the main stack is my normal RPN/RPL parameter passing, intermediate result thing, and this other guy is what I say it is. Say that now it's a place to accumulate a list of values (you can do this with a real list in RPL.) and later it's a place to store successive results of an iterative process. I then don't have to juggle parameters as much because they stay undisturbed on the "main" stack. Forth gives you multiple stacks in many implementations.

How about a stack data type? You then allocate or abandon them as needed. Good (perhaps psychic 8) GC would be needed.



Edited: 6 Feb 2006, 3:10 p.m.

A somewhat longer stack (or virtually infinite, only limited by the total memory-space allocated to it) would do fine. For normal calculations 4 stack positions is fairly enough though, also for temporarely storing results to be used later.

Sounds like Forth, it has an arbitrarily deep regular stack and a return stack. The return stack normally deals with program flow control but you can use for anything that you'd like. http://www.forth.org/svfig/Len/softstak.htm I used to do a bunch of programming in a forth-like language of my own design but rarely found the need to use the return stack for intermediate calculation results.

I think we have been through this discussion before.

If you want compatibility with existing programs you cannot change the stack size (will break assumptions of how the stack will look like after RDN, R^ and stack drop).

So how about a pointer into a "large" register bank that tells
you where your 4+1 stack is located. You can have a command (say STACK nnn) that sets the stack pointer.

Default is STACK 000. If you want to create a new stack use STACK 005.


You may even have a PUSHST and POPST that "push" and "pop" your entire stack into a stack-of-stacks. But why stop at that? Why not save additional processor state (e.g. flags), program file, etc so that you can push you entire HP41 CPU state into the stack, carry out your task and then pop it. Note that you will need some way of accessing data from that stack so that you can retrieve arguments and return results. In this way you can implement a "native" HP-41 command that retains stack contents, LASTx, ALPHA, flags etc, that is not part of the spec of the command.


BTW the first technique is used in RISC processors like the MIPS.