hypothetical: more return stack levels on 11C, 15C, 16C

[brouhaha]

How often do people run into the limit on return stack levels on the HP-11C, HP-15C, or HP-16C?

Does anyone have an actual use case where more return stack levels (perhaps double the current number) on those calculators would be particularly useful? Possibly in conjunction with having more program steps available, and possibly more labels?

For a while now, I've been hacking on the 15C and 16C microcode, lately mostly focusing on 16C improvements. I've already got the 16C memory increased from 203 bytes to 1547 bytes (combined program and registers, with up to 999 program steps), and added trig, inverse trig, logs, and exponentials (in float mode only).

Increasing the return stack size wouldn't be too difficult, but increasing it substantially (like Free42) would slow down GSB and RTN, so I'd most likely only add a small number of extra levels. This means that it wouldn't be too useful for recursion, but it would be useful for cases where the normal calculator is a little short on subroutine levels.

On the other hand, it's remotely possible that some programs exist that actually depend on the behavior with the limited stack.

I've considered this for the 41C/CV/CX also, but any significant changes to the 41 microcode and memory utilization run the risk of breaking synthetic programs that directly muck around with the status registers, and might also interfere with some microcoded ROM module functions. For exmaple, I'd have to test it with SOLVE and INTEG in the Advantage Pac.

[Valentin Albillo]

.
Hi, Eric,

What follows is IMHO, others may vary:

(01-18-2024 09:29 PM)brouhaha Wrote:  Does anyone have an actual use case where more return stack levels (perhaps double the current number) on those calculators would be particularly useful?

The HP-15C has 7 nested subroutine levels. In 40+ years, I've never ever used more than 3-4, and even those only once in a blue moon.

Quote:Increasing the return stack size wouldn't be too difficult, but increasing it substantially (like Free42) would slow down GSB and RTN, so I'd most likely only add a small number of extra levels.

Completely unneeded. Unless you're itching to do it just because, I suggest leaving it alone. "If it ain't broke, don't fix it."

Quote:This means that it wouldn't be too useful for recursion, but it would be useful for cases where the normal calculator is a little short on subroutine levels.

There aren't such cases, unless artificially, specifically constructed for the purpose.

Quote:On the other hand, it's remotely possible that some programs exist that actually depend on the behavior with the limited stack.

Again, I very much doubt it, unless artificially, specifically constructed for the purpose.

Quote:I've considered this for the 41C/CV/CX also, but any significant changes to the 41 microcode and memory utilization run the risk of breaking synthetic programs that directly muck around with the status registers, and might also interfere with some microcoded ROM module functions. For exmaple, I'd have to test it with SOLVE and INTEG in the Advantage Pac.

See above. "If it ain't broke, don't fix it." "And you'll risk breaking it.", I might add.

With all due respect, I suggest you use your time and effort on something more productive and worthy, there's bound to be tons of things that would benefit from your attention.

Best regards.
V.

[brouhaha]

Thanks for your comments, Valentin! I think you're probably right, that there is little point to enlarging the subroutine stack. I brought it up because it would be fairly easy to do, but I wasn't sure whether anyone would have a use for it.

I could just as easily _reduce_ the size of the return stack, but I'm reasonably confident that no one wants that.
:-)

All of my microcode 15C and 16C changes so far have remained compatible with the original Voyager hardware, aside from needing more memory. At one point I put together an ugly kludge to patch the ROM of an original 15C, and add RAM.

Now that the calculators are ARM-based, I could do modifications beyond that, e.g. adding custom Nut instructions. If anyone wanted a really large return stack, to support recursion (but not needed for tail recursion), it could be done in that way with negligible performance penalty. I doubt that anyone will especially want that either.

Anyhow, it's been interesting contemplating the idea.

[Namir]

Eric,

I do salute your thinking out-of-the-box anyway. Nobel prize winner Linus Pauling said, "Good ideas come out of a lot of ideas". We do need to be bold and think outside the box, like you did. Some ideas are hits, some are not. What is important is the exercise of asking questions!

Namir

[pinkman]

Eric,
Very impressed by your ability to patch microcode, thanks again for the 15/16CE.

If you need more ideas, here is mine for the 15C/CE: print a character on a PSE or a R/C instruction.

My idea would be to use a register with an integer value representing the mask of the 7 segments to be printed (from 0 = blank to 127 = “8”). In fact the register could hold a lot of these descriptions but 1 or 2 would be enough, as there are no binary operators on the 15.
The new PSE or R/C instruction should be called using some indicator, such as storing something special in the same register (multiply the integer value by E99?), or branch to an indirect label with an incorrect indirect register I value (eg. 97 or more)...

What do you think?

[floppy]

(01-19-2024 08:11 PM)brouhaha Wrote:  Thanks for your comments, Valentin! I think you're probably right, that there is little point to enlarging the subroutine stack. I brought it up because it would be fairly easy to do, but I wasn't sure whether anyone would have a use for it.

I could just as easily _reduce_ the size of the return stack, but I'm reasonably confident that no one wants that.
:-)

All of my microcode 15C and 16C changes so far have remained compatible with the original Voyager hardware, aside from needing more memory. At one point I put together an ugly kludge to patch the ROM of an original 15C, and add RAM.

Now that the calculators are ARM-based, I could do modifications beyond that, e.g. adding custom Nut instructions. If anyone wanted a really large return stack, to support recursion (but not needed for tail recursion), it could be done in that way with negligible performance penalty. I doubt that anyone will especially want that either.

Anyhow, it's been interesting contemplating the idea.

Just do it. Include that flexibility (first 2 steps more). Perhaps new applications or use will be discovered due to this increase. Personally I would interested to see self calling high convergence algorithm (example AGM or MAGM). It is done on my HP41 with series but self calling could be more nice.

[Bill Duncan]

I can't think of any use case that isn't contrived, except perhaps for some recursive algorithms?

[brouhaha]

For now, I've decided not to change the stack levels. I can revisit that in the future if a good justification comes along.

I need to think more about Thibault's request for displaysegment control. The 41C has a "message flag" that indicates that something special is being displayed, so normally display processing is disabled. The Voyager calculators don't have an equivalent. I can display special stuff during the execution of a running program, and _maybe_ do a special program stop that doesn't refresh the display, until the next keypress. I'm not sure a special display during PSE will work.

Obviously if I have time to study the HP code in enough detail, I could potentially make it do anything the hardware is capable of, but I prefer not to go down a path or really complicated changes.

If all goes well with my rewrite, I hope to publish a demo version of Nonpareil II with a test version of the 16C hacks (expanded memory, trig, inv. trig, logs, exponentials, maybe statistics) in the not-too-distant future.

[David Hayden]

Hi Eric,

I'll be the counter-example and say that an increased return stack could be useful since you're increasing the number of available program steps.

Consider the HP33. Everyone moans about the tiny number of labels, but nobody complains about that number in the 32. Why? Because the 33 has 10's of kilobytes of program space while the 32 only has a few hundred. Basically, more labels are needed to make the extra program space useful. I think it's the same with the return stack. If someone tried to make use of the extra program space, they might run into the return stack limitation.

To me, however, the most useful addition you could make to the 15/16 firmware running with a dot-matrix display is text display of program steps (instead of key codes). I think I saw someone who did something similar in the display driver. They just pattern matched which display segments were on and changed it accordingly.

And that's my 2 cents worth . Thanks for all the work you're putting into this.

Dave

[brouhaha]

Hi David,

Thanks for the suggestions! Dot-matrix display is on my TODO list for real hardware that has such a display. I hadn't thought too much about doing that in Nonpareil II, but clearly if I can do it on some real hardware, I need to do it in simulation as well.

Currently Nonpareil II only has infrastructure for segmented displays, but supporting dot matrix is on the horizon, especially if I add support for the Saturn-based calculators that have such. Once the infrastructure is in place, there's no reason I can't use it for enhanced Voyager models as well.

Best regards,
Eric

[Werner]

(01-18-2024 09:29 PM)brouhaha Wrote:  I've already got the 16C memory increased from 203 bytes to 1547 bytes (combined program and registers, with up to 999 program steps)

(01-23-2024 09:00 PM)David Hayden Wrote:  If someone tried to make use of the extra program space, they might run into the return stack limitation.

The largest set of programs I have ever written (and still continuously improve upon..) for the '41 with its >2200 program bytes uses 4 return stack levels. So, 7 levels for 999 program steps is plenty in my book...

Cheers, Werner