[MLton-devel] Re: HiPE/x86 Erlang compiler paper

[Mikael Pettersson]

On Wed, 8 May 2002 11:21:50 -0400 (EDT), Matthew Fluet wrote:
[a long time ago, I know]
 > > 	"In MLTon, %esp is the heap pointer and %ebp points to a
 > > 	simulated call stack. It is not clear to us what the advantage
 > > 	of this unusual arrangement is."
 > 
 > As you note, MLton uses a simulated call stack.  All arguments (and
 > returns) for (non-foreign function) function calls are passed via this
 > simulated call stack.  As you mention in your future improvements,
 > changing this calling convention to pass some parameters in memory would
 > benefit tail-call and leaf functions.
 > 
 > There are three distinct reasons for not using %esp to point to this
 > simulated call stack.
 > 
 > 1. the stack grows "backwards" compared to a C stack, so we can't use
 >      push instructions to fill in arguments and auto increment the stack
 >      pointer
 > 2. in computing GC masks, variables live across potential GC points are
 >      allocated stack frame slots; other variables are allocated to a
 >      global pool of slots.  During register allocation, these slots
 >      correspond to the spill location of temporaries.  Due to register
 >      pressure (and the fact that stack slot variables are not passed in
 >      registers across basic blocks [1]), there are many reads and writes 
 >      to stack slots.  For reasons beyond my understanding, x86 addresses
 >      with %esp are one byte longer than addresses with %ebp, so it saves
 >      code space and nets better instruction cache usage.
 > 3. to make a foreign function call, we must use standard C calling
 >      conventions.  In order to accomplish this, we save the original value
 >      of %esp at program start-up and load that before making a foreign
 >      funcion call and use push instructions to fill in the arguments.
 >      Because of the reasons outlined in 2, many of these arguments are
 >      allocated on the simulated stack, so there is extra shuffling of
 >      registers at a C call if we were to %esp for the simulated stack as
 >      well.

To me it seems that item 3 is mostly a consequence of the other two.
I've updated our HiPE/x86 paper's comment about MLTon; it's necessarily
brief but please let me know if it in any way misrepresents MLTon:
================================================================
In MLTon, \texttt{\%esp} is the heap pointer and \texttt{\%ebp}
points to a simulated call stack. Using a different register than
\texttt{\%esp} to point to a simulated stack is motivated
\footnote{Matthew Fluet, email correspondence, May 8, 2002.}
by two main reasons: the MLTon stack grows towards higher addresses,
which prohibits the use of \texttt{push}, \texttt{call}, and \texttt{ret},
and the compiler generates many accesses to variables in stack frame slots,
but the instruction encoding when \texttt{\%esp} is the base pointer is
one byte longer than for other registers, leading to worse code density.
Since \texttt{\%esp} was not used for the stack, it was instead used
as the heap pointer. MLTon uses \texttt{sigaltstack()} to redirect
signal handlers to the alternate signal stack, but on Windows this
does not work, forcing MLTon to use another register as heap pointer
on Windows.
================================================================

Also, could to say how may register you use for parameter passing? I was
never able to quite deduce that while browsing your code.

Any why does your stack grow towards higher addresses? Can't the backend
decide for itself how to implement the stack?

Thanks,

Mikael Pettersson
The High-Performance Erlang Team

_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel