
Notes on the status of the x86_64 port of MLton.
=======================================================================

Summary:

The runtime system (i.e., garbage collector and related services) has
been rewritten to be configurable along two independent axes: the
native pointer size and the ML heap object pointer size.  There are no
known functionality or performance regressions with respect to the
rewritten runtime and the mainline runtime.

The next step will be modify the Basis Library implementation (on both
the SML and C sides) to be agnostic to the native representation of
primitive C-types (e.g., int, long); this is important for getting the
right representation for file descriptors, etc.  This step ensures
that the Basis Library implementation may be shared between 32-bit and
64-bit systems.

Following that, it should be possible to push changes through the
compiler proper to support a C-codegen in which all pointers are
64-bit.  After shaking out bugs there, we should be able to consider
supporting smaller ML-pointer representations and a simple native
codegen.

Timetable:

It is expected that the Basis Library changes and the C-codegen will
be completed by March 1.


Technical Question:

One of the native representations that changes from a 32-bit system to
a 64-bit system is the GNU MP representation of arbitrary precision
integers.  Hence, the MLton.IntInf representation datatype

        datatype rep =
           Big of Word.word Vector.vector
         | Small of Int.int

may not suffice (in the situations where Int.int and/or Word.word are
32-bit but the host system is 64-bit).  We are considering the best
way to accomodate IntInf in the 64-bit setting, but we recall that
Polyspace has used MLton.IntInf.rep in the past, and wanted to ask if
there were any particular requirements on maintaining or changing the
interface.
