Re: Activation Records on Stack Based Machines

I think a useful way to think about these is that there is a stack of
activation records and a runtime operand stack for evaluating
expressions. In a stack machine, they are interspersed. Expression
evaluation pushes operands and pops results, on top of the topmost
activation record.


What is particularly convenient is that in calls, the two overlap.
Pushing actual parameters at the call site just evaluates each
expression and leaves it on the stack, as if the function or procedure
to be called were going to be a built-in operator.


But then the call process itself reinterprets the parameters as
part of the activation record it constructs, pushing the rest of
the activation record on top of them. This means the activation
record layout has to be designed so parameters are at negative
displacements, while everything else is positive. (Speaking fron
the point of view that "negative" means toward the bottom of the
stack. If the stack grows toward decreasing addresses, reverse
the signs.)


For functions with results, you either have to push space for this
beneath the parameters, or else have a return mechanism that can copy
the result down, after popping the activation record, including
parameters.


It also works nicely for nested calls (a function call in an actual
parameter to another call.)


leibniz wrote:
> I'm actually new to code generation techniques dealing with
> function invocation/declaration. I am working on a small imperative
> language that uses a stack based virtual machine. I've searched/read
> about activation records, but all I found was register-based machines
> way of pushing activation records on the stack.

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