[MLton] x86_64 port status

[Matthew Fluet]

>> Wouldn't it be better to put it in the appropriate platform specific
>> header file?
>
> I agree.  I would certainly put the definition in solaris.h.
>
> Relevant to that, I noticed that gen-types.c included cenv.h rather
> than platform.h.  I was wondering why.  For Solaris it caused me to
> duplicate a couple of #ifs that were nicely handled by the platform/*
> stuff.  It seems like it would be better to include platform.h if at
> all possible.

The issue, as I see it, is that "platform.h" has been serving too many 
roles.  If you look at the file in HEAD, I see that it:

1) attempts to establish a sane C99 environment:

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
     b) defines a feature set

3) defines a bunch of utility typedef and functions

4) checks that the feature set is defined

5) includes "types.h" and "gc.h", which begins to define many types
    which are only relevant to the MLton runtime and MLton generated
    executables.

6) prototypes utility functions

7) prototypes functions which are _import-ed by the ML side of the Basis
    Library implementation.

We've been including 'platform.h' in any file that requires any subset of 
these roles.  Admittedly, this was the original intention of 'platform.h' 
(from commit 3386):

   Reorganized the runtime to improve portability.  Now, there is a
   single include file, platform.h, which all runtime C files include,
   that is responsible for making the platforms present a consistent
   interface.  Platform-specific code goes in
   runtime/platform/<os>.{c,h}.  There are a few remaining
   platform-specific #if's in gc.c.  Using platform.h greatly simplifies
   porting to a new platform, because we don't have to spray #if's over
   lots of files (as was starting to happen with MinGW) and we don't have
   to duplicate knowledge about what include files are needed.

   Used platform.h to define various properties (HAS_MREMAP, HAS_WEAK,
   ...) that can be tested for (mostly in gc.c) to decide whether and how
   to implement certain things.

   Got rid of the myriad of other include files (libmlton.h,
   basis-constants.h, my-lib.h, posix-constants.h, etc.) used to build
   the runtime.  Instead, all these have been merged into platform.h, and
   any associate code into platform.c.

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.

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.

So, we now have:

<cenv.h>:
1) attempts to establish a sane C99 environment:

<util.h>
3) defines a bunch of utility typedef and functions
6) prototypes utility functions

<basis-ffi.h>
7) prototypes functions which are _import-ed by the ML side of the Basis
    Library implementation.

<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
     b) defines a feature set
3) defines a bunch of utility typedef and functions
5) includes "types.h" and "gc.h", which begins to define many types
    which are only relevant to the MLton runtime and MLton generated
    executables.
5') includes "basis-ffi.h"

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.