Re: Heap Allocated Stack Frame x86 Compiler?

> 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

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