From: Howard Owen on
I've found that drawing stack diagrams is essential to understanding
what's going on in RPL, particularly in complicated code. It's one of
the weaknesses of the language in my opinion. Names work a lot better
for keeping track of values. It has something to do with the fact that
when human beings use "language," it means this odd innate device that
assigns symbols (names) to all sorts of things in a not very logical,
but astonishingly effective and useful way. Go figure. That's why my
general practice is to dump stack values into local variables (with \->
name name name \<<) if I'm going to use the value more than once. It
helps me remember what the value represents, and it also saves me from
a ton of stack manipulation. When I feel like I need to use "ROT" for
example, I squint at the code to see if I can't clarify things with
local variables. Here's simple example from "Graphics on the HP48/GX"
called "GLABEL". It puts a text string somewhere on the display:


Let's assume that like me a couple of months back, we have no idea how
this code is supposed to work. But we do have the manuals and a
general idea of how RPL is put together. Let's analyze this code. OK,
so it's expecting something on the stack.. umm.. what? Well, look up
"\->GROB "in the AUR and it says it wants an object in level two

and a size in level 1. Well, by itself that doesn't
clarify anything because the object can be one of several things. But
let's say we know from context it's supposed to convert text, so I
guess the object is a string, and the size is a font size. Indeed,
that's what the AUR says, with the font sizes ranging from 1 to 3. (0
is a allowed too but isn't relevant for strings.) From the name, I
figure it leaves a GROB on the stack level 1. Next we see PICT, which
puts the address of the screen display on the stack. then we ROT ROT.
Dang, ROT take stack level 3 and brings it down to level 1, with former
levels 1 and 2 moving up one. That means there have to be three things
on the stack at this point, and I have only figured out two the GROB
and PICT! What's the third one? Well, GOR is Graphical OR. It's stack
diagram says it has a GROB or PICT in level three, a coordinate pair (a
list of two BINTs representing x and y coordinates) in level two, and
another GROB in level 1. It then logically ORs in the level 1 bitmap
into the level 3 bitmap at the coordinates specified by level 2.
Confusing? For a newbie, you bet! There is a third parameter on the
stack - a coordinate pair - that we missed for starters. So we scribble
out all the stack diagrams we wrote and draw new ones. Finally we can
use this routine. Next month we'll do all this over again, albeit
understanding \->GROB and GOR better, but with the same obscurity as to
what the routine needs on the stack.

Can we be more helpful to our future selves, or to others that may pick
over our code later? Well, we can *name* all three parameters in local
variables. This will tell us right away what the inputs need to be. We
will also not ROT the stack twice to get the parameters in order, which
will save us drawing two addtional stack diagrams. We'll still have to
look up \->GROB and GOR, but you have to
expect that sort of thing learning a new language. Here's a revised

\<< \-> point string font
\<< string font \->GROB \-> bitmap
\<< PICT point bitmap GOR

I like that better! Not only do we know what the parameters are, but we
name the output of \->GROB too. (In a slightly misleading way, but with
more clarity than not, IMO.) Finally, the stack diagrams we have to
draw (or imagine) are much simpler in order to follow the code.

Of course, for simple, short routines, local variables are overkill. I
use local variables whenever I get a little bit confused, and I still
have more work to do on the problem at hand. The idea being that if I'm
a little confused now, I'll be a lot confused later, so it's worth the
effort to clarify things.


From: Darnzen on
I've had the same thought from time to time. Putting the stack into
local variables makes the code much easier to read.

But I have a superstitious belief that the stack commands are somehow

Has anyone done any time studies?

From: Fr?re-Pierre on
<Darnzen(a)> wrote in message
> I've had the same thought from time to time. Putting the stack into
> local variables makes the code much easier to read.
> But I have a superstitious belief that the stack commands are somehow
> faster!
> Has anyone done any time studies?

Manipulating the stack is usually faster than local variables

From: Howard Owen on
There has to be overhead associated with the pairing of local names to
addresses on the stack. I doubt subsequent access to variables is any
faster or slower, but the setup has to cost something. The names use
memory, too, which is admittidly less of a concern on the modern
machines. But you get something for what you pay: programmer
efficiency, rather than runtime efficiency. You have the same
trade-off, perhaps more obviously, with assembly language versus a high
level language.


From: Arnaud Amiel on
Also when you have very complicated stack manipulations, variables
simplify your algorithm (reduces the number of operations) and it
actually runs faster. But this is an extreme case.

I personnaly use stack diagram, mainly has a bad habit taken on a 32K


 |  Next  |  Last
Pages: 1 2 3
Prev: HP28S (ROM)
Next: Duct Sizing Program