Re: Heap Allocated Stack Frame x86 Compiler?

"Paolo Bonzini" <bonzini@gnu.org>
12 Sep 2002 00:29:09 -0400

          From comp.compilers

Related articles
Heap Allocated Stack Frame x86 Compiler? siavash_massoumi@yahoo.co.uk (Bruce) (2002-09-03)
Re: Heap Allocated Stack Frame x86 Compiler? stephen@dino.dnsalias.com (Stephen J. Bevan) (2002-09-08)
Re: Heap Allocated Stack Frame x86 Compiler? firefly@diku.dk (Peter \Firefly\Lund) (2002-09-08)
Re: Heap Allocated Stack Frame x86 Compiler? fjh@cs.mu.OZ.AU (Fergus Henderson) (2002-09-08)
Re: Heap Allocated Stack Frame x86 Compiler? idbaxter@semdesigns.com (Ira Baxter) (2002-09-08)
Re: Heap Allocated Stack Frame x86 Compiler? bonzini@gnu.org (Paolo Bonzini) (2002-09-12)
| List of all articles for this month |

From: "Paolo Bonzini" <bonzini@gnu.org>
Newsgroups: comp.compilers
Date: 12 Sep 2002 00:29:09 -0400
Organization: http://groups.google.com/
References: 02-09-042
Keywords: storage
Posted-Date: 12 Sep 2002 00:29:08 EDT

> It doesn't meddle with the stack pointer at all and the functions have
> been transformed to continuations, i.e. they don't return at all:


GNU Smalltalk's JIT compiler also does this. Frames are allocated as
Smalltalk objects (instances of BlockContext and MethodContext) which
start their life as LIFO (but already on a heap-allocated stack) and
are moved to the heap if and only if the program needs them as part of
a closure's environment. At first they are malloc-ed, but after a
garbage collection they are moved to the main heap (so that I improve
spatial locality).


Execution of JIT-compiled native code starts at an arbitrary point in
memory, then flows from one method to another without touching the x86
stack and without a single CALL instruction being executed.


> all "calls" become jumps and all functions take an extra parameter,
> namely the continuation (the "rest of the program").


In my case, the `inline cache' structure that the caller passes to the
callee contains the pointer to the continuation.


> Why does SML/NJ do this? It is often able to combine several
> invocation records into one, it needs garbage collection anyway to
> work, so using the heap for everything gets rid of a special case, and
> finally, the same method works fine for handling closures. Here it
> also gets rid of a special case.


This is true in my case as well. And I also avoid writing
non-portable code to walk stack frames when I need to `un-LIFO' stack
contexts (since the back-end is GNU lightning, which is not part of
GNU Smalltalk, the point is not moot -- GNU Smalltalk itself has no
reference to particular architectures, lightning has).


Paolo


Post a followup to this message

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