Local variables in RPN programmable?
#1

I've been thinking of a way to add local variables to an RPN programmable calculator. Does anyone know if this has been done before, or discussed and ruled out as a bad idea? If not then I'll write it up in a Datafile article, and maybe use it as an excuse to try playing with the 34S source code.

Thanks,
Dave

#2

This is something I've been thinking about for the successor to the 34S. I'd be interested in see what you've come up with.

I'm not aware of it being done before but it is an essential step towards coding built in functions as keystroke programs.


- Pauli

#3

I few years ago, I presented an RPN2 emulator at HHC2009. This Excel-based emulator supported modular code that used RPN. The variables and labels of each module lived in their own namespace (defined by the name of the host module). Thus it was possible to write libraries of modules, each with a distinct name, that used the same "local" variables without conflict with similarly named variables that live in other modules.

Namir

#4

It'd be nice to push the stack on a stack and pop the entire stack back. Could be automatic on RTN.

LBL FOO
...
...
...
GSB BAR
...
...
...
LBL BAR
CLONE STACK, COPY STACK, SAVE STACK, etc...
...
...
...
RTN x (or RTN xy, etc...)
If we had an infinite stack I'd just need a 4DUP, 2DUP, etc... Perhaps just a FORTH-like stack setup.
#5

I'm definitely thinking about an unlimited depth stack. The big issue with cloning the stack is you want to take arguments from it and return results to it -- these aren't suitable to using a clone.

I'm also thinking about tagging commands as to the number of input and output arguments and setting/disabling stack lift etc. This allows automatic last X, undo etc to occur which in turn means commands don't need to worry about any of this themselves. It just happens.


- Pauli

#6

How about a separate unlimited stack for environments. It could hold a lot of things besides local variables, and the position of something in the stack does not depend on what you're doing on the data stack.

#7

Namir,

I wasn't at HHC2009 but I think I saw your presentation on the DVDs. It sounds familiar.

If the local variables are stored with the library then doesn't that mean they take up space even when the program isn't running? Also, how does it handle recursion? I suppose recursive calls in an RPN calculator are pretty rare since the return stack is so limited, but it would be nice to allow it.

Dave

#8

Pauli,

You've got email.

Dave

#9

The life of local variables depends on the implementation. In the Excel-based RPN2 emulator the variables come into scope when you store data in them. They remain for the rest of the program life (and beyond in the Excel-based implementation allowing you to inspect the last values in the variables).

As for recursion. I did not support it.

Namir

#10

Gee, sounds like RPL is being reinvented.

#11

I'll take your word for it. I don't speak RPL, but I do speak Forth, and I know they have a lot in common.

#12

Quote:
I suppose recursive calls in an RPN calculator are pretty rare since the return stack is so limited, but it would be nice to allow it.

I've an idea how to implement this on WP 34S, maybe my next venture into the sources. The idea is to share the return stack with program memory. If you need a large return stack, put your program in flash and clear program memory: This will give you more then 500 levels. :-)
#13

New stack semantics would be one way to implement locals, but there's another approach that would be consistent with classic RPN semantics. Like all programmable HP calculators, the 34S has addressable registers. Why not dynamically allocate space for a local register in a subroutine whenever the user uses a particular naming style. So register -10, for example, would be local to the current scope and all child scopes, if not overridden, and would go away when out of scope.

edit: I imagine this might be impossible to implement on the WP-34S, with its already full memory, This suggestion would be applicable to a follow-on machine with more resources.


Edited: 28 Oct 2011, 11:36 a.m. after one or more responses were posted

#14

Quote:
Gee, sounds like RPL is being reinvented.

Sounds that way to me too. IMO, one of the evils of RPL is the large amount of anonymous data that an unlimited stack can carry. RPN uses addressable registers. Local variables in an RPN calculator should use the same approach.

#15

In WP 34S all data is global. Increasing the size of the return stack was a piece of cake (not yet committed, still testing) but we don't have any local data. An idea could be to treat the memory between and of program space and current return stack pointer as addressable memory, probably indirect only with negative indexes. There you need a thorough checking of the available space and corresponding pointers.

#16

I didn't see your post before editing the parent, Marcus. Would it be possible to add the required bounds checking given current memory constraints on the WP 34S?

#17

I'm thinking about it. We might add a command LOCAL n which reserves n registers on the return stack. It needs to place a special marker on the return stack so that a RTN can pop the data. This will be a non trivial modification.

#18

I'm not planning anything like RPL. Commands will still have arguments after them e.g. The looping and branching constructs of RPL will be absent.


- Pauli

#19

"Reinventing RPL" is probably over the top. It's just that this discussion triggered one of my RPN/RPL pet peeves. Anonymous data that moves is a Bad Thing, I believe. Four or even eight levels deep in a stack is manageable, more or less. More levels, especially with a rich bestiary of object types, overflows the mental list I maintain mapping stack levels to values. Register addresses, though limited in their ability to convey their contents at any given time, at least can be statically mapped to meaningful names.

Regardless of my personal hobby horse, I do believe that relying on the stack for local variables is an approach associated with RPL, and not RPN. That doesn't tie anyone's hands in terms of implementing it in an RPN machine, but it might muddy the water a little.

#20

We will be coming up with a sensitive solution, I'm sure. All fully RPN, just a 'few' more data registers to play with as long as the program space isn't full or the program runs out of flash memory.



Possibly Related Threads…
Thread Author Replies Views Last Post
  HP: Dump the predefined variables! bluesun08 12 3,655 11-19-2013, 02:18 PM
Last Post: bluesun08
  HP Prime - local variables retain their initial type BruceH 4 1,818 11-10-2013, 12:42 PM
Last Post: Michael de Estrada
  Shutdown with the Apps key and more than 10 variables in a program. Davi Ribeiro de Oliveira 10 3,749 11-05-2013, 01:26 PM
Last Post: Han
  [PRIME] RPN: another attempt at returning more than one value to the RPN stack Marcus von Cube, Germany 5 2,382 11-05-2013, 02:44 AM
Last Post: Marcus von Cube, Germany
  HP Prime: Number of external Variables Davi Ribeiro de Oliveira 0 979 11-01-2013, 08:10 PM
Last Post: Davi Ribeiro de Oliveira
  HP Prime variables Davi Ribeiro de Oliveira 3 1,600 10-31-2013, 02:24 AM
Last Post: cyrille de Brébisson
  HP Prime - deleting variables bluesun08 1 1,189 10-29-2013, 06:36 PM
Last Post: Joe Horn
  HP Prime: CAS Variables - -How to save? Helge Gabert 2 1,754 10-27-2013, 11:26 PM
Last Post: Helge Gabert
  HP Prime Programming Tutorial #1: LOCAL, RETURN Eddie W. Shore 6 2,944 10-26-2013, 08:42 PM
Last Post: Miguel Toro
  HP Prime Solver Variables Issue Anibal Morones Ruelas 8 2,987 10-19-2013, 09:45 AM
Last Post: Harold A Climer

Forum Jump: