Re: Heap Allocated Stack Frame x86 Compiler?

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


Yes.


> 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
Continuations.


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:


f()
{
  g(7);
  h(8);
  ...
}


would become:


f()
{
    g(7, k);
}


k()
{
    h(8, k');
}


k'()
{
  ...
}


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.)


-Peter

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