register allocation

[Stephen Weeks]

> One idea we're
> playing with is to have the native code generator conform to
> the same data layout and invariants that the MLton backend
> currently uses,

:-)

> but replacing C code with native code,
> wrapping the native code inside a C procedure.

I'm not sure I understand what it means to wrap native code inside a C 
procedure.

> Calls would be translated as jumps to externally linked symbols and
> would be handled by the C linker.  

I assume you mean calls to C routines (including runtime system calls, 
etc).

> Do you think this (or a
> variant thereof) is a feasible approach to getting native
> code inside MLton without rewriting the runtime?

Yes.  I think the interface to the current GC is pretty thin and
manageable.  And I like this approach as well for making the
performance comparison to the old backend easier.

A couple of things that occur to me offhand:

1. The GC knows nothing about machine registers, so that in order to
call the GC, you would have to do something analogous to what happens
in the C code now -- you would have to copy all pointer valued
registers to an array known to the GC or into stack slots, and then
call the GC, and then copy the pointers back to registers upon
return.  You could of course do this with a procedure of your own that 
takes a register mask and does the right thing.

2. The "return addresses" on stack frames are small integers.  These
addresses are used as indexes into the frameLayouts array in GC_state,
as well as into the nextChunk array used by the running program to
determine what C procedure to trampoline to next.  I think that
keeping return addresses as small integers would have negligible
performance overhead with a native backend, where you build your own
table mapping these small integers to the real return address and a
return has to do an extra table lookup.