[MLton] Progress on AMD64/FreeBSD

[Matthew Fluet]

Jesper Louis Andersen wrote:
> The runtime only required a single change to be ported.

Great!

> But how do I coerce my 32bit machine to build a codegen
> that can bootstrap on the amd64?

There are a variety of ways!

1) Install the mlton-20051202 binary package for x86/FreeBSD onto your
    amd64/FreeBSD system; you can do it either globally (e.g., into /) or
    locally (e.g., into /home/fluet/devel/mlton-20051202).
    mlton-20051202 "knew" about amd64, in the sense that it "knew" to
    use the x86 native codegen and "knew" to pass -m32 to gcc.  And
    mlton-20051202 only "thinks" it is on x86 because
    $$/usr/lib/mlton/target-map tells it that 'self' is 'x86-freebsd'.
    So, just modify target-map to tell mlton that 'self' is
    'amd64-freebsd'.  This will ensure that mlton uses the
    -target-{as,cc,link}-opt amd  flags (in particular, -m32).
    (And, if you installed locally, also edit
    $$/usr/bin/mlton to set the 'lib' variable appropriately and makes
    sure that $$/usr/bin/mlton is on your PATH.)

    Now you should be able to build a source checkout on the
    amd64/FreeBSD machine.  This will build a 64-bit runtime.  Then,
    using mlton-20051202, it will build a 32-bit executable that knows
    how to build 64-bit executables.  Finally, it will bootstrap again
    and build a 64-bit executable.

    This is how I have things on my amd64/Linux machine, so I know it
    works well enough.

2) You can play similar trickery with your recent build of mlton
    from your x86/FreeBSD machine.
    Copy your ~/hacking/mlton/build from your x86/FreeBSD machine to your
    amd64/FreeBSD machine, say to ~/hacking/mlton.32bit/build.
    We'll assume you have a clean source checkout in
    ~/hacking/mlton.64bit

    Now, you have a number of choices.  The copied mlton "thinks" it is
    on x86 because mlton.32bit/build/lib/target-map tells it so.  We
    can't change the architecture here, because this mlton "knows" that
    on amd64 it should use -m64 for gcc, but it would try linking with
    its 32-bit runtime library.

    a) But, we don't need the mlton runtime library to build the mlton
       runtime library, so we can conjure up a 64-bit runtime library.

       In fact, we can be sneakier, and just pretend that the
       ~/hacking/mlton.32bit/build/lib/mlton-compile executable is the
       first executable we would have gotten had we followed 1) above.

       So, we do the following:

       cd ~/hacking/mlton.64bit
       make dirs runtime
       cp ~/hacking/mlton.32bit/build/lib/mlton-compile build/lib
       make world-no-check script mlbpathmap target map constants 
libraries tools
       make compiler world

       This works because all of the information about the target
       platform is read in when the compiler is invoked.

    b) Alternatively, we could tell mlton.32bit that it needs to pass
       -m32 to gcc in order to link with its runtime.

       To do this, simply edit ~/hacking/mlton.32bit/build/bin/mlton
       and add

       -target-as-opt x86 '-m32' \
       -target-cc-opt x86 '-m32' \
       -target-link-opt x86 '-m32' \

       into the script.  Make sure that ~/hacking/mlton.32bit/build/bin
       is on your PATH and execute 'make' in ~/hacking/mlton.64bit.

       In fact, we could have simply added these lines in 1) above in
       order to teach mlton-20051205 how to behave.


Both 1) and 2) require that your target 64-bit platform have sufficient 
32-bit compatibility libraries.  Both will require a 32-bit version of 
the GNU MP shared library on the 64-bit platform.  With 2a), we could 
have statically linked when we build on the x86/FreeBSD machine, but we 
would probably still need some rudimentary 32-bit compatibility support 
on the amd64/FreeBSD system.

If you're trying to be completely 32-bit clean on the 64-bit system, 
then it is effectively like porting to a completely new platform.  See
   http://mlton.org/PortingMLton
and
   http://mlton.org/CrossCompiling
Obviously, in this case, all of the code has been changed and we can 
skip right to the Bootstrap section.  (But remember to run 
'bin/add-cross', which is described in the "Running the regressions ..." 
section.)


So, take your pick!  I think 2a) is the quickest route.  Let me know if 
there are any snags, as we'll want to make sure to pass that information 
along to other porters.


> Apart from that this seems like an easy port.

It should be.  One really hopes that the system interface of an OS is 
mostly architecture independent.