Re: MLton broken FFI on AMD64???

On Sun, Feb 6, 2011 at 8:38 PM, Matthew Fluet <[email protected]> wrote:
> On Fri, Feb 4, 2011 at 10:01 AM, Matthew Fluet <[email protected]> wrote:
>> Interestingly, it seems that MacOSX also demands that rax be set to
>> the the number of floating point parameters.
>>
>> It seems that setting rax for every FFI call on AMD64 would be the
>> simplest solution.
>
> I committed a patch that always sets %rax to the number of XMMS
> registers passed for non-win64 AMD64 platforms; since %rax is caller
> save, this doesn't really affect register allocation and just incurs
> an immediate->register move instruction.  That solved the issue on
> Linux and MacOSX (and presumably on other Unices).

BTW, it occurs to me that there isn't a good solution to this problem
with the C codegen.  With the C codegen, MLton emits prototypes for
_import-ed functions that are derived from the type of the imported
function.  The prototype assumes that the function is a non-varargs.
[There is a second issue with Henry's particular example, where the
MLton emitted prototype for printf disagrees with the prototype
exported by stdio.h, so one actually gets a compile error there.]  I
suppose we could also be conservative here and always emit a varargs
prototype.

The other alternative is to simply not support _import-ing of varargs functions.