Re: Storage of Variables

torbenm@diku.dk (Torben AEgidius Mogensen)
23 Jan 2000 10:10:53 -0500

          From comp.compilers

Related articles
Storage of Variables e8johan@etek.chalmers.se (2000-01-21)
Re: Storage of Variables torbenm@diku.dk (2000-01-23)
| List of all articles for this month |

From: torbenm@diku.dk (Torben AEgidius Mogensen)
Newsgroups: comp.compilers
Date: 23 Jan 2000 10:10:53 -0500
Organization: Department of Computer Science, U of Copenhagen
References: 00-01-089
Keywords: storage

e8johan@etek.chalmers.se (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
>parameters on.


>[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
>depth. -John]


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 (torbenm@diku.dk)


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.