[MLton] Patch for x86-darwin

[Eric McCorkle]

On Sep 27, 2006, at 12:33 PM, Matthew Fluet wrote:

>
> -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.

>
> Otherwise, it looks pretty good.  I think there is a (latent) bug  
> in the
>   val (pushArgs, size_args) = ...
> code, since the size_args is computed as the size of the unpromoted  
> values.  That is, when calling a C function with the prototype:
>   int f (char c, short s);
> it yields 3 (bytes) for size_args, although 8 bytes of stack are  
> consumed for the arguments.  The size_args is only used for  
> computing the suffix for the stdcall calling convention (but that  
> isn't used by much, and the suffix would be correct for any  
> function with all wordsize arguments) and for adjusting the stack  
> after a cdecl call.  Again, this wouldn't hurt us in the long run  
> because we usually fetch the C stack pointer from a global before  
> each C function call; we only adjust %esp to avoid consuming stack  
> space when there are multiple C calls in a row.
>

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.

-- 
Eric McCorkle,
Brown University
CS Graduate Student