|Storage of Variables email@example.com (2000-01-21)|
|Re: Storage of Variables firstname.lastname@example.org (2000-01-23)|
|From:||email@example.com (Torben AEgidius Mogensen)|
|Date:||23 Jan 2000 10:10:53 -0500|
|Organization:||Department of Computer Science, U of Copenhagen|
firstname.lastname@example.org (Johan Eriksson Thelin) writes:
> What is the prefered way to store variables? To put them on the
>stack (push, pop) together with return addresses and such, or to
>mantain a local variable heap with nothing but variables and
>[Most languages put locals on the stack because all of the offset
>bookkeeping can be handled at compile time. A common compromise is to
>use a frame pointer that's initialized from the stack pointer at the
>beginning of each routine, with variables referenced relative to the
>frame pointer. That means you don't have to keep track of the stack
However, in functional languages where function closures can be
returned from function calls, you can't use the stack, as variables
may need to be used after the return. In this case, it is common to
put the variables in a separate heap.
Some functional language compilers even do away with the stack
altogether and put put return addresses and such in the heap as well
as variables. This is described in Andrew Appel's "Compiling With
Continuations". I'm somewhat sceptical about this idea, as you lose
some of the locality of reference that a stack has. If you use a
generational garbage collector with a small first-generation, this
problem is reduced, but there is still some loss.
A third alternative is to use a stack but allow allocation in the
middle of the stack as well as on the top. This is the idea behind
Tofte and Talpin's region inference.
Torben Mogensen (email@example.com)
Return to the
Search the comp.compilers archives again.