[MLton] x86_64 port status
Stephen Weeks
MLton@mlton.org
Sun, 7 May 2006 20:54:08 -0700
> The issue, as I see it, is that "platform.h" has been serving too many
> roles.
I agree that platform.h serves all the roles you mention. I'm just
not entirely clear on the benefits of splitting them all up.
> 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.
> 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.
> <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.