Local variables in RPN programmable? - Printable Version +- HP Forums (https://archived.hpcalc.org/museumforum) +-- Forum: HP Museum Forums (https://archived.hpcalc.org/museumforum/forum-1.html) +--- Forum: Old HP Forum Archives (https://archived.hpcalc.org/museumforum/forum-2.html) +--- Thread: Local variables in RPN programmable? (/thread-203076.html) |
Local variables in RPN programmable? - David Hayden - 10-27-2011 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, Re: Local variables in RPN programmable? - Paul Dale - 10-27-2011 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.
Re: Local variables in RPN programmable? - Namir - 10-27-2011 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
Re: Local variables in RPN programmable? - Egan Ford - 10-27-2011 It'd be nice to push the stack on a stack and pop the entire stack back. Could be automatic on RTN. LBL FOOIf we had an infinite stack I'd just need a 4DUP, 2DUP, etc... Perhaps just a FORTH-like stack setup. Re: Local variables in RPN programmable? - Paul Dale - 10-27-2011 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.
Re: Local variables in RPN programmable? - Garth Wilson - 10-27-2011 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.
Re: Local variables in RPN programmable? - David Hayden - 10-27-2011 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
Re: Local variables in RPN programmable? - David Hayden - 10-27-2011 Pauli, You've got email.
Dave
Re: Local variables in RPN programmable? - Namir - 10-27-2011 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
Re: Local variables in RPN programmable? - Eric Smith - 10-28-2011 Gee, sounds like RPL is being reinvented.
Re: Local variables in RPN programmable? - Garth Wilson - 10-28-2011 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.
Re: Local variables in RPN programmable? - Marcus von Cube, Germany - 10-28-2011
Quote: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. :-) Re: Local variables in RPN programmable? - Howard Owen - 10-28-2011 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
Re: Local variables in RPN programmable? - Howard Owen - 10-28-2011 Quote:
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.
Re: Local variables in RPN programmable? - Marcus von Cube, Germany - 10-28-2011 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.
Re: Local variables in RPN programmable? - Howard Owen - 10-28-2011 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?
Re: Local variables in RPN programmable? - Marcus von Cube, Germany - 10-28-2011 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.
Re: Local variables in RPN programmable? - Paul Dale - 10-28-2011 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.
Re: Local variables in RPN programmable? - Howard Owen - 10-28-2011 "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.
Re: Local variables in RPN programmable? - Marcus von Cube, Germany - 10-29-2011 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.
|