Best way implement an RPN stack?


How would you implement an RPN stack today?

I can see a couple of scenarios:

1. The classic 4 level stack with "last X" register, duplicate T on drop, and stack lift disable flag.

2. As (1), but with more elements on the stack, in that case, how many?

3. Using a traditional stack pointer and using Forth stack semantics with DUP, ROT, SWAP and ROLL.

I never felt the 4 level stack was a big problem when I used the HP-41 back in the eigthies. After getting used to an HP-48 I feel a little bit more constrained by it these days.

What do you prefer?


The problem with being a collector and having piles of calculators around is that we can pick what is best for what we are doing.

I prefer the traditional 4-level for anything that takes advantage of the repeating t-register.

I prefer the unlimited stack for anything where it is nice to have a running record of results or inputs.

One RPN computer application I used to have (but lost on a format and reload) had a selecteble 4 or 8 level repeating t-register stack. (XYZPQRST)


I prefer a stack like on the 41, where you are entering directly into the X register. Typing a number and pressing ENTER^ pushes it up into Y, not like the 20b (and i believe the 35s) where typing a number and pressing ENTER^ puts it into X, and a second ENTER^ is needed to put it into Y.

However, I think two new registers could be added: D and F. D would hold the depth of the stack, and F would fill the entire stack with a singe value. Typing 35 STO F would fill all levels of the stack with 35, making it easier to use repeating T values with any depth stack.


The 35s is normal RPN, not RPL. It functions exactly the same as the 41, 65, 67, 10c series etc


The 34s (AKA 30b repurposing project) features a selectable stack size of either 4 or 8 levels with top level repetition. And it includes a FILL command copying x into all stack levels at once. There is a bit reserved for stack depth indication.

Edit: Forgot mentioning that complex FILL will copy the complex number x+iy into the respective levels, of course. Gracias à Angel for reminding me d;-)

Edited: 20 Oct 2010, 2:57 p.m.


Great minds think alike: there's a REPLX function on the SandMath (and ZRPL on the 41Z module for complex stack) that does the stack fill with the value in X (or Z).

Edited: 20 Oct 2010, 2:01 p.m.


Never really got into RPN. Having used a 38g for a while, and now that I am teaching myself 48sx, I prefer the unlimited stack.


Call me a tradicionalist but I side with the 4-level stack choice. To me it's just enough, and I've got so used to the T-replication that I won't consider doing without it.

Although you can say that T-replication is just a palliative to the awckward RPN-style programming, and that a (more advanced) RPL machine won't need it. That's probably a true statement.

When I wrote the 41Z I had to mimic all the real stack functionallity for the complex stack (buffer-based). That's when I really got to admire its design, I'm afraid it's for good in my case.





I am in the process of implementing a RPN environment for the HP 39gs and I went with the 4 level replicating T stack of the 41. I considered following the design of the newer RPL machines but for a simple calculating environment I think I prefer the 4 level stack.


I am in the process of implementing a RPN environment for the HP 39gs...

The questions naturally present themselves:

1. How can you do this?
2. Why would you do this? (i.e., why not get a 48gii, 49g+, or 50g)


1. It is relatively easy. There are examples out there that do this only a little too slow to be useful. I already have a HPBasic implementation that is sufficiently responsive to be usable but I have stopped further development on it and am rewriting it all in Sys RPL.

2. Because I can and I enjoy the challenge. I own all three of the calculators you mentioned in addition to nearly every scientific/graphing calc HP has ever produced. For daily use I generally employ a HP48S/X or G/X as I prefer their keyboards to that of the 49g+, etc.

The HPBasic implementation so far handles basic 4 banger arithmetic, full 4 position stack manipulation including T replication (X<>Y, RollUp, RollDown, LastX, currently stack store / recall are not available), basic trig and log functions (no hyperbolics yet--would be easy to add), 30 storage registers, mode settings for std, fix, sci, and eng. Angle mode settings (DEG, RAD, GRAD) would be easy to add as would any other 1 or 2 variable functions (such as hyperbolics). The current HPBasic implementation is around 9K (source) and 19K after the first run.

For the sRPL implementation I plan on providing all the above plus hyperbolics, combinations, permutations, etc. (basically any scientific functions that the 39gs is capable of), 100 storage registers with full store arithmetic (this is already working) and in the future I might also implement rcl arithmetic.



I am frequently amazed at the level of nuts & bolts expertise shown on this forum. I just struggle to learn how to use my 48sx. And here people are writing ML programs, debugging calculator internals with oscilloscopes, writing new firmware for repurposing, etc., etc.

Makes my head spin.


I feel exactly the same way. I'd love to know more about these wonderful little beasts, but scarcely know where to start ...

This forum is simultaneously inspiring and intimidating. :)


Glenn, don't be intimidated by things you see here. I bought a 16c around 1981 or 83, but I never learned how to program it. I was a mainframe programmer in those days and I couldn't see the point of programming a "calculator." But about 10 years ago I got a simple 12c, with a minimal set of programming statements, and I learned what it means to program in RPN, and I've been fascinated with it ever since. And you would be surprized what you can do with a program size limitation of 99 bytes!

So if you're interested in simple RPN programming, get a 12c and have at it. Today's ARM-based 12c runs about a million times faster than the 12c of 10 years ago (I'm exaggerating somewhat).



I am in the process of implementing a RPN environment for the HP 39gs

Wow! Great news to hear. The 39gs is the only HP model I use with any regularity any more. My eye sight is no longer what it once was, and the keyboard of the 39gs is extremely legible compared to other HP calculators. While I have adapted to the loss of RPN I would adopt it again if it became available for the 39. If you need a beta tester or have any other needs let me know. I could become quite avid about your project. Good luck.

Edited: 20 Oct 2010, 5:45 p.m.


Thanks! I agree about the legibility of the HP39gs keyboard. It is definitely better than that of the 48gII and in my opinion easier to read for my tired old eyes than the 50g.

I do have a working version of the HPBasic implementation as noted in an earlier post. Unfortunately I have not bothered to document anything (either code or use) yet and the code is a little messy as I wrote it (rewrote it) for speed rather than legibility or easy maintenance. However, other than the rather convoluted keyboard handling for the numeric input, stack lift enable/disable etc. it is pretty straight forward. Adding additional functionality would be easy so if someone was interested in adding hyperbolics or giving me some feedback on the keyboard layout I have chosen I would be happy to share what I currently have. I can also share some of the ideas that I have for the sRPL version I am working on now. Just send me an email offline. Be forewarned, however, that there is a good chance that bugs still exist in the stack handling code.

One thing that I would really like to implement and have not yet thought of a clean way to accomplish it would be a fully reassignable keyboard. It should be doable by putting the keycodes in some form of table and providing a way to edit or update the table (could use a list for this) but I fear that performance would suffer too badly to maintain usability so that idea is on hold for the moment.


Edited: 20 Oct 2010, 7:08 p.m.


Hi M.,

How similar/different is your 39GS RPN implementation to Manfred Pfeiffer's "RPN Add-On" (HPBasic) program (found at

I have it loaded on my 40GS and like it a lot, except for the speed, or lack thereof. :-) Sounds like you've addressed that issue in your implementation.



p.s. I feel the 40GS' color-scheme is just about right.


Hi Matt,

Very similar. In fact I got his program and decided I wanted a little more speed which led me to my own project. His is a very good implementation and if it were not for the speed issue I would probably have not started my own effort. I have to admit, that for the HPBasic version, I borrowed the display GROB from his code and edited it rather than dealing with writing it from scratch. The GROB for the sRPL version required a near-complete rewrite.

At this point his is somewhat more complete as I have stopped development to tackle the Sys RPL version. Currently the only reason I use my version instead of his is the speed. My code is able to keep up with keyboard input as fast as I can enter it--single digit repeated at top speed--whereas his will lag in that and many normal usage scenarios.

The only benefit (other than speed) that my HPBasic version offers is the ability to backspace (delete and correct) numbers and 30 registers vs. 10. In general I am of the opinion that more registers are pretty useless in a non-programmable implementation since there is a limit as to how many one can keep track of. To aid somewhat in this I handle the registers in the same manner as the Voyager series. Single numeric digit for the first "bank", period followed by numeric digit for the second "bank", and comma followed by numeric digit for the third "bank". This will be replaced in the Sys RPL version by 100 numbered registers used exactly as in the HP41. In fact, in general, the user interface of the sRPL version will be patterned after the HP41 with, for example, keyboard access to the FIX, SCI, and ENG functions (these along with the storage sub-system are already coded) rather than menus.

I have lots of ideas for the sRPL version that may or may not pan out, but a working RPN implementation with support for all the math functions of the HP39gs seems to be relatively straight forward (once one deals with the numeric entry and stack lift issues).




I feel the 40GS' color-scheme is just about right

I am glad you like it. I have a 40GS also, but I don't use it because of the color-scheme. I know I belong to a minority group of the forum members, but I have to point out a fact that many of you will face eventually.

I can use almost any calculator from any manufacturer in "ideal" lighting conditions. The trouble is that calculators are generally used as a portable device often in less than ideal locations. legibility can really suffer at times when the lighting gets poor.

My eye lenses has no focus problems at all, I have just reached an age where the rods and cones are dying in the back of the retina. I just need more photons on the retina. If everyone is lucky enough to survive to middle age they will probably arrive at a similar point.

I blame calculator industry for a really poor design effort in respect to legibility. I believe that early in the game, manufacturers were infatuated with the device display and chose a dark body design that accented the display iformation. I think this bad choice has persisted in spite of the disadvantages.

Does anyone remember using slide rules. Did anyone ever see a slide rule with a dark body and rainbow colored indexes. I didn't. Slide rules were almost universally light colored bodies with black index marks. I think they did that because that is the best method to accommodate the human eye. I still have no difficulty reading my 45 year old slide rule.

Calculators seem to generally ignore this principle and people like me suffer the consequences. Calculators could be improved by using a very light body for the keyboard background that will reflect the greatest number of photons to the surrounding legends and to the users eye's.

Most of you are probably not affected - yet, but I suspect some day you will be singing this same chorus.

Just my 2 cents worth on that particular subject


Donald, great points. I love the 12c, but those blue letters on a black key frequently require a magnifying glass and/or flashlight for me to discern them. And on my 65, the blue letters on the white numeric keys are OK, but the conditionals on the black keys always require a magnifying glass.


I discovered this phenomena quite by accident. When I first purchased my HP 41 CV back back in the 80's it came with a light cream colored keyboard overlay, which I installed immediately, and never removed. Many years later I acquired another everyday 41cx and my original 41cv "prized possession" went into the display case.

The new 41cx replacement did not come with that same overlay, and I soon noticed my difficulty with deciphering the keyboard legends. The overlay (I only have one) is now my most essential 41 series peripheral.

I think if you could somehow create a white overlay for your 12C machine you would probably not have to use the magnifier and light solution. Just the small increase of reflected light around the keyboard area is usually all you need to create better legibility.

Edited: 21 Oct 2010, 10:51 a.m.


Calculators seem to generally ignore this principle and people like me suffer the consequences. Calculators could be improved by using a very light body for the keyboard background that will reflect the greatest number of photons to the surrounding legends and to the users eye's.

I see the same silly situation on too many web sites: the web site creator thinks it "arty" "cool" or whatever to use a dark background with (often too-small!) white/light-colored type against the background. I find these very difficult to read.


I find these very difficult to read.

Well in my case it is not "difficult" - it is "impossible".


There was a five level stack on this calculator. The mind reels at the mere thought of keeping track of Bill's & Walter's eight level stacks.
To answer your scenario #2; i'd say that 4 levels have always been enough for me. It was even possible to write an inverse routine for two pairs of coordinates loaded into the stack (without using any storage registers). However; the amount of rolls and X<>Ys meant that it didn't really save any space. Didn't run any faster either. So the classic 4, or the Heathkit 5 would get my vote. - db



The mind reels at the mere thought of keeping track of Bill's & Walter's eight level stacks.

  1. Basic purpose of such an eight level stack is providing 4 levels for complex numbers. Hope this helps your mind ;)
  2. As long as you work in real domain, you may limit the stack to traditional 4 levels. HTH
  3. FYI, MathUPro on my PDA features a 16 level stack. Do they want me keeping track of every item there? No - they want me to know I can push my numbers on it and calculate without worries for stack overflow. I fully agree you will hardly ever need more than 4 levels - let's assume in 99% of all calculations - but do you want to watch your calc since it does something strange with 1% probability? I don't. But that's my personal view and another reason for implementing a selectable stack depth. HTH
  4. As long as it keeps reeling, can you use it for generating energy? ;) ;)



I have no problem keeping track of 4 levels,. 5 would be ok too, but for 8 i would need to have an 8 level display - easy on a computer or 48's screen but...

I see that using a larger stack would pay dividends for the 1% of users doing deep, original, complex work, so being switchable takes care of all of us.

The mind reels slower each year. Have recently changed from generator to alternator to compensate. I hope the 30b project is going well. - d



Thanks for your kind words. I hope your alternator is brushless so no regular maintenance changing worn brushes is required. Referring to the 30b project, please see my posting in the other thread.



I don't think there's a best. Four with repeating T is good, adding LastX and LastY to that simplifies lots of things. (Complex, of course, four-space could be nice for physics but I've never seen it proposed.)

What I always wanted in a calculator was the ability to DUP PUSH SWAP and DROP the entire stack (which would include the entire flag register and LastX and LastY, to at least twenty or more stacks) with another command to MERGE the current and past stacks, for a function return, moving the values about.

More exotic was the machine with sixteen registers, r0..rf, where each register was actually the top of a stack. The stacks were maintained in memory using a big LRU cache, and you could do things like push(r0) <-- pop(r1) + r2 (the result was pushed onto r0, r1 popped after the add, r2 was only read.) (Yes, I designed compilers, not hardware.)


How would you implement an RPN stack today?

I can see a couple of scenarios:

1. The classic 4 level stack with "last X" register, duplicate T on drop, and stack lift disable flag.

2. As (1), but with more elements on the stack, in that case, how many?

3. Using a traditional stack pointer and using Forth stack semantics with DUP, ROT, SWAP and ROLL.

I've favored a settable-depth stack of between 4 and 9 elements (set by, e.g., "STKD 7") in the classic RPN operating paradigm. Minimum and default depth would be 4, because less than that is not useful, and 4 ensures compatibility with traditional RPN programs.

4 stack elements is usually enough, though, if the user is thinking ahead and mentally keeping track of pending operations. Too many more than that is difficult to keep straight.

-- KS

Edited: 21 Oct 2010, 1:19 a.m.


Classic (option 1) is my preference. Regards


I'm sure that a 4-level stack is sufficient for "number crunching" work, but after I was exposed to symbolic calculators, there's no going back for me.

Ironically, even though RPN was developed so numerical expressions that used parentheses and order of operations could be evaluated on a simple computer without need for an algebraic parser or memory to store lots of pending operations, I think it works *even better* for symbolic calculations.

And for that sort of application, an unlimited stack becomes necessary.


Agreed. And thanks again Crawl for showing me how to "build" an algebraic object, one step at a time, using RPN arithmetic. Its a beautiful thing.

I later came across this method in An Easy Course in Using the HP 48sx, and perhaps its also in the HP manuals, but I first learned about this from one of your posts.


Thanks a lot for all the comments!

It seems like there is a lot in favor for the 4 level stack.

My first feeling was towards an larger Forth like stack, but I now feel a 4 level stack is way to go when doing keyboard calculations.

A longer stack has its virtues, but a larger display is almost a must in that case.


I havn't had mich time to develop things further but on one of my (unpublished) emulators I implemented a four level stack that automatically grew deeper when used but behave the same as a four level stack (only deeper) when R^ Rv operations were performed.
Perhaps you can have the best of both words..?

Mike T.


I recall with amusement a friend using the original 35. He was never sure the entered number was still there when he keyed a new number, he always had to swap XY a few times to be sure. I learned to use a 4 stack and the repeating t register was useful to most of my keystroke solutions. I did feel sorrow whe engineers programmed simple solutions that were easy with RPN. Visibility of the sttackis possible the most useful feature now. Sam


Did your friend ever check whether T was still there after calling a trigonometric function? That behavior (i.e. overwriting T with Z) would have driven me crazy, I guess.

Best regards


Edited: 21 Oct 2010, 3:48 p.m.


I find that the classic four level stack is the easiest for me. (Choice #1)


While I like both [1] and [3] and can't decide which I prefer I
detest the mix of both as we have in the HP 20b:

  • No stack lift after INPUT
  • +/- changes ANS (aka LASTX)

Probably I wouldn't like the HP 30b neither.

Thinking about option [2] I wonder whether I'd like a
2nd parallel stack (similar to how you can "abuse" the
return stack in Forth). You could push (>R) intermediate
results that are somehow in the way and pop (R>)
them later again when needed. I guess I'd prefer that
to having an 8-level stack.

Best regards


Edited: 22 Oct 2010, 5:33 p.m.

Possibly Related Threads...
Thread Author Replies Views Last Post
  HP 50g - select characters on the stack, copy/paste Sean Freeman 7 2,076 11-20-2013, 07:11 AM
Last Post: Sean Freeman
  Prime: Placing more than 1 item on the RPN stack in a single program? John Colvin 4 1,708 11-19-2013, 08:59 AM
Last Post: Miguel Toro
  emu48 - copy stack doesn't work (as expected) Thomas Radtke 2 1,581 11-11-2013, 02:19 PM
Last Post: Thomas Radtke
  HP Prime Stack operations from within a program John Colvin 1 1,073 11-08-2013, 09:45 PM
Last Post: Helge Gabert
  [PRIME] RPN: another attempt at returning more than one value to the RPN stack Marcus von Cube, Germany 5 1,946 11-05-2013, 02:44 AM
Last Post: Marcus von Cube, Germany
  Prime: Anyway to refresh stack? kris223 5 1,725 10-16-2013, 05:09 PM
Last Post: kris223
  hp prime - sending program results to the stack giancarlo 6 1,600 10-15-2013, 02:00 AM
Last Post: Giancarlo
  HP Prime - RPN stack access from programs? Mike Mander (Canada) 10 2,639 09-30-2013, 11:20 AM
Last Post: steindid
  WP-34S: Stack after divide by 0 Marcel Samek 4 1,084 08-24-2013, 11:57 PM
Last Post: Paul Dale
  Little curiosity: why the fourth stack register is called "T"? Antlab 34 6,614 07-03-2013, 04:49 PM
Last Post: Walter B

Forum Jump: