[MLton] summer release?

[Matthew Fluet]

Henry Cejtin wrote:
> This  is truly excellent.  I would be curious to have some description of the
> native code generator.  Things like how you use the 8 extra registers.

The commit log has some notes:
   http://mlton.org/pipermail/mlton-commit/2007-May/001568.html
You (Henry) will especially appreciate the fact that on amd64, we use 
SSE2 instructions and XMM registers, yielding IEEE compliant floating-point.

As for the extra 8 registers, I just give them over to the register 
allocator and we do less spilling.  On the x86, we take %esp as the ML 
frontier register and %ebp as the ML stack pointer register; except on 
MinGW/Cygwin, where signals break when we use %esp, so we take %edi as 
the ML frontier register.  On the amd64, we take %r12 as the ML frontier 
register and %rbp as the ML stack pointer register.  It would be pretty 
easy to reserve %rsp on the amd64, but we don't need to.

> I assume that the amd-64 bit version of MLton uses full 64-bit  pointers  (as
> opposed to some of the other ideas discussed before, like 32-bit offsets from
> a semi-space base).  

That is correct.

 > In connection with that, I would really like to have the
> FFI,  for  implementations  where  it  holds, let me export, for instance, an
> array of strings as a char **.   I.e.,  to  expose  arrays  in  ML  as  being
> pointers to C.

Exported nested indirect types when native pointers are equivalent to 
heap object pointers would be fairly easy.  Indeed, I'm tempted to 
restore that behavior for the time being, since we don't currently have 
implementations where the two kinds of pointers differ.

I think that compressed heap object pointers could be a win for some 
applications.  In addition to the variety of schemes used to compress 
the pointers, there are a number of design decisions that concern how to 
mix compressed and uncompressed heap object pointers.  The most trivial 
design would be to compress at each object allocation and to uncompress 
on each dereference.  However, we'll immediately want to add a 
common-subexpression-elimination pass to share compress and uncompress 
computations.  The tricky part is that such sharing might lead to an 
uncompressed pointer being live across a gc point.  So, either we allow 
stack frames to include both compressed and uncompressed pointers or we 
ensure that no uncompressed pointer is live across a gc point.  If we 
allow stack frames to mix compressed and uncompressed pointers, then we 
might consider allowing normal and array objects to mix pointer 
representations.  One obvious reason for allowing such mixed pointer 
objects would be exactly for FFI: any exported value would force that 
value to contain only uncompressed pointers.  (Note, the value itself 
could be internally represented with a compressed pointer, and we simply 
uncompress when passing through the FFI.)