ROT ROT - oh GROB!
in [HP48]
|
Prev: HP28S (ROM)
Next: Duct Sizing Program
From: Howard Owen on 25 Jan 2006 15:22 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: \<< \->GROB PICT ROT ROT GOR \>> 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 version: \<< \-> 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. Regards, Howard
From: Darnzen on 25 Jan 2006 20:05 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?
From: Fr?re-Pierre on 25 Jan 2006 20:38 <Darnzen(a)gmail.com> wrote in message news:1138237520.920141.285390(a)g47g2000cwa.googlegroups.com... > 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 25 Jan 2006 20:56 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. Regards, Howard
From: Arnaud Amiel on 26 Jan 2006 06:14
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 48G Arnaud |