[MLton] power pc "port"

[Filip Pizlo]

> Thanks for the detailed explanation Filip.  Now I understand.  The
> problem was not with Word8_neg, but with WordS8_quot (and others).

Yes - this is actually a better way to look at it.

> My conclusion is that gcc uses different calling conventions for
> signed and unsigned chars on G5, but not on x86 or Sparc.

Right.  On PowerPC, the calling convention calls for either masking or
sign-extending values before a function return, and before passing args to
a function in a function call.  The latter was failing because of
inaccurate type information.

> The only fix that I see is to change MLton's FFI so that it keeps
> track of the difference between signed and unsigned words of various
> sizes so that we generate the appropriate prototypes in the generated
> C code.  This does not require the compiler to distinguish between
> signeds and unsigneds in its ILs, merely to keep enough information so
> that it can follow the conventions used by the outside world (i.e. C)
> when it needs to communicate with it.
> 
> Does this make sense?  Any other ideas?

It does make sense.  The only downside is that in addition to every
arithmetic operation on 8-bit and 16-bit words requiring a function call,
each one of those operations will now require one or more sign extension
and/or masking operations.  Of course, the cost of these operations may 
be minuscule in comparison to the cost of the function calls. :-)

The thing that I worry about is the native codegen for PowerPC.  Will it
have to deal with the same IL as the C codegen?  In that case, having the
IL only know about unsigned words may result in a significant performance
hit, in addition to unnecessary code bloat.

> If we're in agreement on the solution, I'm happy to make the changes
> tomorrow (Monday).  It shouldn't be too bad, modifying
> atoms/c-type.{fun,sig} to add the new types and modifying a little bit
> in elaborate/elaborate-core.fun to make the distinctions.

Good stuff.  I'll finish hacking on IEEEReal.c today, so we should have a
working port real soon.