|Activation Records on Stack Based Machines email@example.com (2004-01-22)|
|Re: Activation Records on Stack Based Machines firstname.lastname@example.org (2004-01-31)|
|Re: Activation Records on Stack Based Machines email@example.com (2004-01-31)|
|Re: Activation Records on Stack Based Machines firstname.lastname@example.org (Basile Starynkevitch \[news\]) (2004-01-31)|
|Re: Activation Records on Stack Based Machines email@example.com (Joachim Durchholz) (2004-02-01)|
|Re: Activation Records on Stack Based Machines firstname.lastname@example.org (2004-02-01)|
|Re: Activation Records on Stack Based Machines email@example.com (Rodney M. Bates) (2004-02-04)|
|From:||firstname.lastname@example.org (Dick Wesseling)|
|Date:||1 Feb 2004 12:51:49 -0500|
|Organization:||Posted via Supernews, http://www.supernews.com|
|Posted-Date:||01 Feb 2004 12:51:49 EST|
email@example.com (leibniz) writes:
> 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.
"stack based" can mean a lot of things. Maybe you should be a bit more
specific about your VM.
> I've searched/read
> about activation records, but all I found was register-based machines
> way of pushing activation records on the stack....
This is one possible definition of "stack based".
> ... Where do I place the
> return value of a function, save program counter, allocate space for
> local variables...etc. Can someone give me pointers on how that can be
> done on stack-based machines? Or even documents that explain how
> Python, Java, or any other language that uses a stack-based VM
> implements activation records?
Forth is the classical example of a stack based VM. There are no
activation records. All computations are done on a single parameter
stack. Functions are invoked by evaluating their input parameters on
the parameter stack and then calling the function. The called function
finds its input parameters on top of the parameter stack and leaves
its result(s) on the parameter stack. Removing the input parameters
from the stack is typically a side-effect of the function. Forth uses
a dual stack. Return addresses are stored on a separate return stack
so that they do not complicate parameter stack manipulations.
The Java stack on the other hand is based upon activation records
which are typically allocated in a garbage collected heap. The Java
compiler knows the size of an activation record and this information
is used for allocating an activation record that is large enough to
hold the input parameters, storage for local variables and stack space
for intermediate values. Upon invocation of a method the methods
parameters are *moved* from the callers AR to the methods AR. (Compare
Forth which does not copy or move). This is very similar to what you
have read about register-based machines. If your source language or
target VM are similar to Java you can (from the top of my head) the
Java Virtual Machine Specification.
Return to the
Search the comp.compilers archives again.