|Re: RAM = RAM ? Interesting!|
Message #8 Posted by James M. Prange on 19 Nov 2003, 5:56 a.m.,
in response to message #7 by bill platt (les Estats Unis d'Amerique)
Thanks, Paul! That explains why doing "mem" on the 48 does not
return what I would expect, after a "DUP"
Umm, actually, I'm James, but no matter. Yes, there's a lot of "smoke
and mirrors" behind the RPL magic. Quite a bit more than I've thoroughly
Having the stack of pointers only does sometimes conserve memory, and
perhaps more important, it allows the stack manipulation commands to be
fast. And objects in temporary memory are left where they are until a
"garbage collection" is done, at which time objects still referenced by
pointers are packed next to each other to recover the memory used up by
A few other things that sometimes cause unexpected results from MEM are
the last stack, last arguments, and last command lines saves.
One of the subtle things about the RPL calculators' memory usage is that
if you have any pointer to any object within a composite object (a list,
algebraic, or program), then the entire composite is kept in memory. For
example, if you generate a list "on the stack" (really in temporary
memory), and use GET to extract one element from it, then the entire
list is kept in temporary memory for the sake of the pointer to that one
element. Similarly, if an object from a program is left on the stack, then the
entire program is referenced. NEWOB on the element makes it a new object
in temporary memory, with a new pointer to it, so as long as the
original composite or any element of it isn't referenced by any other
pointer, it's eligible for overwriting at the next "garbage collection".
Storing the element in a global or port (but not local) variable, or
including it in another composite or an array, also makes it a new
object and discards the pointer into the original composite.
But if the element of the composite isn't really an object, but a
pointer itself, as in the case of a whole number -9 to +9, then the
pointer is copied to the stack, instead of using a pointer into the
Note that if the composite was stored in a global variable, the memory
was used anyway. But if I recall a list from a global variable, extract
one element from it, and purge the global variable, then the list is
copied into temporary memory for the sake of the pointer, so I've only
recovered a few bytes as long as I keep the pointer.