[MLton] power pc "port"

[Stephen Weeks]

I read through this thread and it looks like y'all are making good
progress.  Here's a few comments.

As to gdtoa, I'd like to see the problem with strtod and strtof fixed,
which I think means that the functions should be renamed to avoid
clashes with standard system libraries.  The clashes make building
MLton statically impossible on some platforms (I've encountered the
problem recently on FreeBSD).  While we do distribute a pristine
tarball for gdtoa, we do have some infrastructure in runtime/Makefile
to create and apply patches to it.  See the gdtoa-patch target.  This
stuff hasn't been used much, so it may need a little work.  But a
couple of name changes in gdtoa and in the runtime files that call
strto{d,f} (basis/Real/strto.c) should be fine.

Yes, it is essential from a usability perspective to get rid of all
linker warnings for a normal run of MLton.

As to making libmlton.a and libgdtoa.a static rather than dynamic,
Henry's point that static improves the ease of use of MLton-generated
executables outweighs any arguments I have heard for making them
dynamic.

I've incorporated Matthew's suggestion for adding to the runtime a
HAS_SPAWN preprocessor symbol, defined to TRUE on Cygwin and MinGW.

As to initializers for the globals in CommandLine.c and environ.c, I
certainly don't mind having them.  It is weird needing them though.

As to the different behavior of cp on MacOS for trailing slashes on
directory names, I've patched the Makefile for now.  I wonder if there
is another switch that could be passed to cp to solve the problem,
though, so that $(CP) in the Makefile behaves the same on all our
platforms.

As to the bug with Int2, I agree with Matthew's assessment that the
first place to look is Int8.{quot,rem}.  The chances for problems in
the case of Int.fmt are increased because it uses quot and rem on
negative arguments.

Other places to look are in the different endianness or word size of
the platform.

Finally, here's a few other debugging tricks that haven't yet been
mentioned.

1. Generate C with -codegen c and debug the C code.
  a. compile with -cc-opt -DDEBUG_CCODEGEN, which will cause lots of
     debugging messages to be printed.  You can also add more to 
     c-chunk.h.
  b. add print statements to the C code to see what's going on.
  c. single step through the C code with gdb.

2. Add print statements and/or turn on debugging in the runtime
   library.  For example, one could add some print statements to
   runtime/basis/Int/Word.c to see what's going on with quot and rem.

3. To understand what's going on at the SML level, you can compile
   with -profile count and link against a runtime compiled with
   DEBUG_ENTER_LEAVE = TRUE.  This will show each SML function as it
   is entered and left.  Someday we will clean this up and make it
   easier to use as a primitive debugger.