|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:||"Peter \"Firefly\" Lund" <firstname.lastname@example.org>|
|Date:||8 Sep 2002 22:51:36 -0400|
|Organization:||Department of Computer Science, University of Copenhagen|
|Posted-Date:||08 Sep 2002 22:51:35 EDT|
On 3 Sep 2002, Bruce wrote:
> Is there a compiler available that will create native x86 code that
> makes no use of the stack. Instead it could dynamically allocate space
> for a stack frame on the heap and then set the EBP and ESP registers
> and then use the stack as normal.
Why do that? If you go to the trouble of allocating the invocation
record "manually" it should be because you think you can do better
than the built-in stack operations. Why use ESP, then?
> I searched the internet but all I can find are langauges such as
> python and PicoC that run on top of virtual machines.
> A C compiler would be ideal but any language would do.
> [I doubt there are any 386 compilers that do heap allocation of
> individual call frames, since you need a stack anyway to handle
> interrupts. But there are lots of packages that set up blocks of
> space for thread stacks and run with the stack in one of them rather
> than the "system" stack. -John]
SML/NJ. It is described in Andrew Appel's book Compiling with
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:
all "calls" become jumps and all functions take an extra parameter,
namely the continuation (the "rest of the program").
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.
(Of course there is still a stack for the ML run-time and the C
library. Interrupts, though, are handled by the operating system so
they are of no concern.)
Return to the
Search the comp.compilers archives again.