[MLton] x86_64 port status

[Matthew Fluet]

>> However, I believe that reinstating libmlton.h, in the guise of the
>> auto-generated basis-ffi.h, is better, as it ensures consistency
>> between the C and ML sides of the Basis Library implementation.
>
> That is a huge improvement.  So much so that I suspect users will want
> us to make the tool available for their programs.

Maybe. gen-basis-ffi.sml is little more than a sed or perl script, I just 
find it more convenient to write in SML.  Most importantly, it fixed a lot 
of inconsistencies.

>> Furthermore, I believe that it makes sense to auto-generate the
>> sizes of C primitive types, which needed only a sane C99 environment
>> and the utilities.
>
> True.  Although it doesn't hurt to have more there when defining the C
> primitive types.

Agreed.

>> <cenv.h>:
>> 1) attempts to establish a sane C99 environment:
> ...
>> <platform.h>
>> 2) identifies the target OS and pulls in a target OS specific header,
>>     which (recursively) serves a number of roles:
>>      a) attempts to compenstate for a broken C99 environment
> ...
>> It would be nice to somehow move 2a) into <cenv.h> in some manner.
>> Stephen's suggestion of moving the #ifdef chain at the beginning of
>> 'platform.h' into 'cenv.h' is probably the best solution, though it
>> suffers from folding 2b into <cenv.h> as well.
>
> It would certainly be possible to split out the n-way platform #ifdef
> and the platform/<os>.[ch] files into two pieces, one piece that
> extends the C99 part and the other for everything else.  But it seems
> like a lot of work for no clear benefit to me.

I agree that it makes the most sense to move the n-way platform-os #ifdef 
into cenv.h; I'd say move the n-way platform-arch #ifdef there as well.