[MLton] Patch for x86-darwin

[Matthew Fluet]

>> -Word32 c_stackP;\
>> +/* The first element of this array is the stack pointer to be used by\
>> + * sml (16-byte aligned).  The second is the actual base of the stack,\
>> + * which is used when returning to C.\
>> + */\
>> +Word32 c_stackP[2];\
>> 
>
> You need to align the C stack pointer to a 16-byte boundary.  You don't 
> really know exactly what alignment it might have, so the easiest way is to 
> and it by -16.  However, this cannot be reversed, so you need to store the 
> stack pointer before it was anded (ie the real stack pointer) for when you 
> return to C code.

O.k.  Of course, if we're not assuming that gcc has left the stack pointer 
on a 16-byte boundary, it's not clear to me that we're safe in assuming 
that gcc has left the stack pointer pointing to the stack.  Ideally, we 
should write up the MLton_jumpToSML code in assembly, where we'll know 
exactly what's going on with %esp.

Of course, I don't quite see the point of 16-byte alignment if no function 
can assume that the stack pointer is 16-byte aligned on entry.

> If I follow correctly, you'd have something like this...
>
> ccall_a (...);
> ccall_b (...)
>
> you could get into some funny cases if you're subtracting the size of 
> arguments.  I'll have to think through them.

Yes, but it should be fixed now.  Essentially, if you had:

  ccall_a (char, short);
  ccall_b (int);

the assembly would have:

  movl (c_stackP),%esp
  movzbl %al,%eax
  pushl %eax
  movzwl %bx,%ebx
  pushl %ebx
  call ccall_a
  subl 3, %esp
  pushl %ecx
  call ccall_b
  subl 4, %esp

At this point, %esp is 5 bytes greater than the value stored in c_stackP. 
Turns out this is o.k., since %esp was always well within the stack area, 
and after this code, %esp is dead, so for the next C call, we refetch 
c_stackP.