[MLton] power pc "port"

[Matthew Fluet]

> The multiple defintion problems are because Mac OS X's libSystem
> (equivalent of libc) uses the gdtoa library.  However, it doesn't export
> the gdtoa symbol.  So we may just have to live with these warnings (there
> is a switch somewhere to suppress them).

There must be ways that other projects that use gdtoa get around it.

> The IEEEReal_getRoundingMode and IEEEReal_setRoundingMode errors are
> an oversight - I'll have to hack runtime/basis/IEEEReal.c to have a
> PowerPC case.

Yes.

> The spawnve and spawnvp errors are a puzzle to me.  I don't see where in
> the MLton code these functions are defined.  Is there a dependant library
> that I'm not seeing?  (I can easily implement these functions, but I don't
> want to do that if they're already out there somewhere.)

As far as I can tell, we are pulling it from libc.  For most platforms, I
suspect that whatever header file the prototypes are really in has more
stuff than we need, so there is an explicit
   runtime/platform/spawn.h
that is included by linux.h, {free,net,open}bsd.h, and solaris.h,
but cygwin.h and mingw.h get it from <process.h>.

However, that doesn't explain the linker not finding the symbols.  Maybe
they are in a different library under Mac OS X.

> The etext error may turn out to be annoying.  The MLton GC uses the _start
> and etext symbols to figure out where the text segment sits.
> Unfortunately, the Mac OS X linker doesn't offer an etext symbol.  It
> does, however, offer functions that give similar information: get_etext(),
> get_end(), and get_edata().  However, the manual page (see
> http://developer.apple.com/documentation/Darwin/Reference/ManPages/html/end.3.html)
> makes clear that you're not really supposed to rely on those.  Perhaps if
> a MLton GC expert could tell me exactly how etext is used, I can hack the
> GC to be more Mac OS X-friendly.

The _start and etext symbols are used for profiling.  Essentially, the
time profiler works by raising a timer interrupt and incrementing a
counter corresponding to the program counter of the interrupted
instruction. The _start and etext symbols are used to determine which
addresses correspond to instructions from the executable (as opposed to
instructions in a dynamically linked library or in the kernel).

Profiling is probably the last thing you want to tackle, and looking at
the manual pages, I suspect that we're going to have to work hard to get
it working on Mac OS.

For now, I would suggest setting
  #define HAS_TIME_PROFILING FALSE
in platform/ppc.h (or whatever you call it).  That will avoid all the time
profiling stuff in gc.c including the _start and etext symbols.