[MLton] native x86-64 code-gen

[Matthew Fluet]

> Tweak the current native code-gen to use the extra regs and generate a 
> 64-bit program that assumes all pointers are 32-bit in size. This might 
> require some extra masking when dealing with address.
> Modify the runtime to make sure the MLton heap and stack live in the 
> lower 32-bit address space.

This really isn't any less work than really fixing the compiler to know 
about 64-bit systems.  And, in fact, it would just make it harder to go 
back and make the C-codegen work on a 64-bit system.  

> So this almost works except for dealing with the FFI, and a situation 
> where the runtime returns a 64-bit pointer that needs to be stored in an 
> MLton data structure.

Right, and since much of the Basis Library implementation relies crucially 
upon FFI support, it makes a lot more sense to handle the 
internalizing/externalizing of pointers in an IL that is shared by all the 
codegens.

We all know that the "quick'n'dirty" that just barely gets something to
work is rarely the "right thing."  And when we know of at least a "better
thing" at hand, there is no reason to cripple ourselves with the "wrong
thing."

> So the advantage of what I outlined above, as well as being simpler than 
> a full 64-bit port. Is that pointers stay 32-bit, since lots of ML 
> sturcutures are pointer intensive a full 64-bit approach is likely to 
> almost double the size of many small objects, and eat up space in the 
> cache for no good reason.

Absolutely, and this has been thought about:

http://mlton.org/pipermail/mlton/2004-October/026162.html