Re: Activation Records on Stack Based Machines

anton@mips.complang.tuwien.ac.at (Anton Ertl)
31 Jan 2004 00:51:29 -0500

          From comp.compilers

Related articles
Activation Records on Stack Based Machines io@spunge.org (2004-01-22)
Re: Activation Records on Stack Based Machines torbenm@diku.dk (2004-01-31)
Re: Activation Records on Stack Based Machines anton@mips.complang.tuwien.ac.at (2004-01-31)
Re: Activation Records on Stack Based Machines basile-news@starynkevitch.net (Basile Starynkevitch \[news\]) (2004-01-31)
Re: Activation Records on Stack Based Machines joachim.durchholz@web.de (Joachim Durchholz) (2004-02-01)
Re: Activation Records on Stack Based Machines ftu@fi.uu.nl (2004-02-01)
Re: Activation Records on Stack Based Machines rbates@southwind.net (Rodney M. Bates) (2004-02-04)
| List of all articles for this month |

From: anton@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.compilers
Date: 31 Jan 2004 00:51:29 -0500
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
References: 04-01-129
Keywords: architecture
Posted-Date: 31 Jan 2004 00:51:29 EST

io@spunge.org (leibniz) writes:
> 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?


You can read the Java VM specification book. One problem for you is
that it wants to leave a number of options open (e.g., switching the
stack on calls), and therefore is not at all detailed in how this
would work in an implementation where you decide not to switch stacks
or do other funny things.


A very simple example similar to the JVM comes with Vmgen
(http://www.complang.tuwien.ac.at/anton/vmgen/).


Here's the relevant comments and code (with some cleanups to avoid
unnecessary distractions) from the vmgen example, a JVM implementation
could be very similar.


\ The stack is organized as follows:
\ The stack grows downwards; a stack usually looks like this:


\ higher addresses
\ --------------------- bottom of stack
\ locals of main
\ return address (points to VM code after call)
\ +->oldfp (NULL)
\ | intermediate results (e.g., 1 for a call like 1+foo(...))
\ | arguments passed to the called function
\ | locals of the called function
\ | return address (points to VM code after call)
\ +--oldfp <-- fp
\ intermediate results <-- sp
\ ---------------------- top of stack
\ lower addresses


\ The following VM instructions also explicitly reference sp and
\ therefore may have to do something about spTOS caching.


call ( #target #iadjust -- targetret aoldfp )
targetret = IP;
SET_IP(target);
aoldfp = fp;
sp = (Cell *)(((char *)sp)+iadjust);
fp = (char *)sp;


return ( #iadjust target afp i1 -- i2 )
SET_IP(target);
sp = (Cell *)(((char *)sp)+iadjust);
fp = afp;
i2=i1;


- anton
--
M. Anton Ertl
anton@mips.complang.tuwien.ac.at
http://www.complang.tuwien.ac.at/anton/home.html


Post a followup to this message

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