Alignment of doubles in ghc

[Simon Marlow]

=20
> I've recently browsed some assembly code generated by GHC=20
> (via gcc). It appeared that most values were accessed via=20
> memory, because the stack is managed by GHC explicity. Even=20
> intermediate results seem accessed via memory, probably due=20
> to shortcomings of aliasing analysis in gcc. (?)
> =20
> This brings on the topic of eval/apply vs push/enter. In the=20
> eval/apply model, the stack management can (possibly) be left to an
> underlying compiler, which would remove most memory accesses,=20
> and leave most of the alignment issue to the back-end.=20
> (http://research.microsoft.com/Users/simonpj/papers/eval-apply/)
> =20
> From that article, I can only assume that GHC will switch to=20
> the eval/apply model. Can we expect that soon? The=20
> "alignment" thing would
> become easier to deal with...

We've already made the switch to eval/apply for the next release of GHC.
However, deferring the entirety of stack management to an underlying
compiler is not that easy: we do accurate garbage collection, so we need
to retain enough information about the compiler's idea of stack layout
in order to be able to find all the pointers during GC.  We therefore
can't compile via C using an ordinary C compiler and leave the stack
management up to the C compiler.  C-- has a solution to this problem,
but there is neither a C-- compiler or a C-- back end for GHC (yet).

Cheers,
	Simon