[MLton] x86_64 port status
Matthew Fluet
fluet@cs.cornell.edu
Thu, 22 Dec 2005 13:51:10 -0500 (EST)
> 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.