[MLton] power pc "port"

[Matthew Fluet]

> I've overcome all of the linker problems, so that I can build static
> libraries for gdtoa and mlton and the linker doesn't complain.  (The fixes
> necessary to make this happen are described below.)  However, when I run
> the resulting binary, I get:
>
> unhandled exception: Fail: usage: exportMLton worldFile

Actually, that's good.  What you are running into is the fact that you
side-stepped much of the Makefile, so we need to either bring you back in
line with that or go through some steps by hand.  The former is probably
easier.

Here's what's going on.  The  /usr/bin/mlton  (or whatever) that you
normally call is just a script file (see bin/mlton in CVS).  This script
passes a few parameters to  /usr/lib/mlton/mlton-compile  which is the
real binary.  So, the executable you built from mlton.cm should be renamed
to mlton-compile (but we'll get to that shortly).  There is a second
complication -- the mlton-compile binary uses the MLton.World.{load,save}
features to initialize some things at build time.  The mlton script tells
the mlton-compile to start up by loading the previously saved world.
Bottom line: you've got the right binary, and it's telling you that it
wants to save the world.

Here's what I suggest doing.  I'll assume that mlton.cvs.HEAD is where
you have the CVS sources.

1) copy the binary to
     mlton.cvs.HEAD/mlton/mlton-compile
   I'd keep a copy of the binary around somewhere else in case I get
   something wrong here and make ends up deleting the binary.
2) fool the Makefile with
     touch mlton.cvs.HEAD/mlton/mlton-compile
3) from mlton.cvs.HEAD run
     make dirs runtime compiler
   Assuming that you already have the runtime built, this should be fairly
   quick -- it'll just copy a few things into mlton.cvs.HEAD/build/lib.
4) If that succeeds, we should be in good shape.  Try
     make world-no-check
   This will build the saved world described above.
5) Next there are a few auxilary things we need:
     make script mlbpathmap
   These shouldn't fail in any way.  The script will install
   build/bin/mlton, the script that calls build/lib/mlton-compile.
6) Next we need to take care of some machine specific things (mostly
   header file constants used by the basis library), so there's a chance
   things will break here.  But you want to do:
     make targetmap constants
7) Finally, try type-checking the basis library:
     make world

If you get to here, then it looks like you've got a working compiler.
Running mlton.cvs.HEAD/build/bin should print something like:
  MLton MLTONVERSION (built Thu Sep 02 19:21:08 2004 on tiger.cs.cornell.edu)

Next you can try out the regressions:

A) From mlton.cvs.HEAD, run
     ./bin/regression

Probably no chance that these all work, and we can investigate them when
you get here.

> 1) I had to insert -D hacks to rename gdtoa's strof and strod, since
> libSystem also has these.  This got rid of the linker warnings.

Hopefully there is a better way of dealing with this.

> 2) I added a PPC implementation of IEEEReal_set/getRoundingMode.  It was
> not as easy as the SPARC implementation, because I could not find a
> library rutine for doing it - so I had to use the assembly shortcuts in
> <ppc_intrinsics.h>.  The code is iffy enough that it would be great to
> know which regression tests cover the setRoundingMode function.

The real.sml test in regression uses the rounding mode.