register allocation

[Stephen Weeks]

> Note, we don't have to be quite as crude as the current stuff.  There are
> places currently where the natural thing would be to use an array of addresses
> (or of addresses relative to the current top-of-stack, that we can't do in
> C (either because of the offset problem or because gcc panics if you take the
> address of a variable).  With an actual back end, these could all be done.

The array of addresses relative to top of (mlton) stack is basically
what is done with the frameLayouts indexed by "return address".  The
only place where C gets in the way is in the pointer valued C locals,
where we have to the copying.  This is analogous in a native backend
to pointer valued machine registers, where I think the right thing to
do is to have register mask and do the copying outside of the GC
interface so that the interface stays simple.  I mentioned one way in
the previous message.  Another way, which might interact better with
threads, would be to copy all the registers on top of the mlton stack, 
so that the entire context of the thread is on the stack, and to have
a special GC_frameLayout for this special frame full of registers.

> As to the return addresses, it is so ugly.  You will still have to do some
> kind of switch, and if you centralize the switch the branch prediction is
> going to be really bad.

Maybe.  But functions aren't called that much :-).  I wouldn't object
to using real return addresses, but I would like to maintain the
property that there is only one runtime system implementation,
possibly with a switch that controls whether it is interacting with
the C or native backend.

> I E-mailed Suresh that I figured that the only C code you would call would be
> stuff from the runtime system, and that is easy to do (since the calling
> convention on Intel hardware is so simple).

It's a bit trick for many of the primitives, whose type is only
implicitly specified in header files (e.g. mlton-lib.h), but I agree
that this is the way to go.  In any case, you should just send mail to
MLton.  That way it is archived as well.

BTW, before anyone starts mucking with the runtime, they should get
the latest snapshot from me.  I've made some changes since 1999-7-12
and am in the process of making more to support threads.