[MLton] Patch for x86-darwin

[Eric McCorkle]

On Sep 29, 2006, at 10:49 AM, Matthew Fluet wrote:

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

GCC will always generate stack frames such that they are 16-byte  
alignment preserving.  This is usually sufficient, as most people  
don't write assembly code, so every function will be alignment- 
preserving.  If you disassemble some code, you can actually see that  
it wastes a little space here and there.

This works as long as every function in the program obeys the rule.   
The only way you can run into trouble is if hand-coded assembly  
doesn't follow that rule.  Then you wind up entering functions at  
nonaligned stack addresses.

MLton_jumpToSML is part C, part asm.  It's given that you'll enter at  
a 16-byte aligned address, but exactly what GCC will do before it  
hits the asm code is not.  The only real way to be sure is to do a  
bitwise and to clear out the bits.  Problem is, this isn't  
invertible, so when you return into C, you'll have the wrong stack  
address.  The solution (which I must admit I don't exactly like  
myself) is to save the stack pointer SML will use (%esp & -16) at  
C_stackP[0], and the stack pointer to restore upon return to C at  
C_stackP[1].  The "right" way would be to write a function entirely  
in assembly that does the jump, and call it from C, and have it  
preserve the 16-byte alignment.

-- 
Eric McCorkle,
Brown University
CS Graduate Student