x86 backend

[Stephen Weeks]

> IntInf_???, Real_??? are not implemented yet; I don't think that the
> IntInf stuff will be too difficult, I just haven't dived in there yet. The
> Real stuff will be more difficult.  It would be nice to get it working
> through FFI calls, but returning floats and moving floats from one
> location to another use entirely different instructions, so I'm going to
> hold off on them for a little while.

Sounds fine.  When you get to reals, I'd vote for going straight to
primitives and not even bother with FFI, since you'll have already
tested the FFI and the backend in other ways, and you have to get to
primitives eventually.  But definitely hold off on real and intinf
until fib, tak, and something involving GC works (at least).

> FFI, MLton_halt, MLton_size, String_equal are implemented as FFI calls.
> Conceivably, MLton_halt could be written as assembly, but seeing as it is
> only ever called once, I don't think we'd see any speed improvement.

Agreed.

> GC_collect, Thread_copy, Thread_copyShring, Thread_finishHandler,
> Thread_switchTo, World_save are also implemented as FFI calls, but with
> the extra code to handle the possibility of a thread switch on return.

Fine for now, but Thread_switchTo will have to be a primitive for
efficiency reasons.  I just put some stuff in machine.h to make
Thread_switchTo 5X faster.

> 2. A very basic linear-scan, greedy(?) register allocator.  
> ...

Looks good.

> unless
> there are any real objections to this setup, I'm going to start working on
> the "glue" between the existing runtime system and the x86 assembly above.

No objections here.  I'd like to see you push through having to deal
with all the other stuff (runtime, assembler, linker) as soon as
possible.

Hopefully there will be a new version of MLton released tomorrow, and
you can start making changes on that one, so we will be as in sync as
possible.