|Heap Allocated Stack Frame x86 Compiler? firstname.lastname@example.org (Bruce) (2002-09-03)|
|Re: Heap Allocated Stack Frame x86 Compiler? email@example.com (Stephen J. Bevan) (2002-09-08)|
|Re: Heap Allocated Stack Frame x86 Compiler? firstname.lastname@example.org (Peter \Firefly\Lund) (2002-09-08)|
|Re: Heap Allocated Stack Frame x86 Compiler? email@example.com.OZ.AU (Fergus Henderson) (2002-09-08)|
|Re: Heap Allocated Stack Frame x86 Compiler? firstname.lastname@example.org (Ira Baxter) (2002-09-08)|
|Re: Heap Allocated Stack Frame x86 Compiler? email@example.com (Paolo Bonzini) (2002-09-12)|
|From:||"Paolo Bonzini" <firstname.lastname@example.org>|
|Date:||12 Sep 2002 00:29:09 -0400|
|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
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).
Return to the
Search the comp.compilers archives again.