[MLton] x86_64 port status

[Matthew Fluet]

> I don't quite understand the agnostic C-side library.  I thought that you
> meant that the C source was asnostic, depending on #defines to set the sizes,
> but when you talk about a single libmlton-basis.a, it must mean that the
> actual binary is agnostic as well.  Isn't that very expensive for almost
> no gain?

I want the libmlton-basis.a to be agnostic with respect to the ML heap 
object pointer representation.  All this means is that the compiler proper 
will arrange that FFI of ML array/vector objects will be passed by the 
architecture native pointer representation -- regardless of the ML heap 
object pointer representation (so, yes, there may be a conversion before 
the FFI call, but that is required at some point in time in order to 
actually use the array/vector).

Now, libmlton-basis.a certainly won't be agnostic to the native arch/os 
representation of values.  We're cheating a bit both on the C side and the 
SML side of the Basis Library representation, because we have in 
runtime/types.h:

typedef int32_t Int32;
typedef Int32 Int;
typedef Int Fd;

and in basis-library/misc/primitive.sml

structure Int32 =
    struct
       type t = int32
       type int = t
    end
structure Int = Int32
type int = Int.int
structure FileDesc:>
    sig
       eqtype t

       val fromWord: word -> t
       val fromInt: int -> t
       val toInt: t -> int
       val toWord: t -> word
    end =
    struct
       type t = int

       val fromWord = Word32.toInt
       fun fromInt i = i
       fun toInt i = i
       val toWord = Word32.fromInt
end

So, both sides believe that a file descriptor is necessarily 32-bits.  The 
SML side is a little better, because of the opaque signature match, so we 
don't expect too many surprises when we change the representation there.