[MLton] power pc "port"
Filip Pizlo
pizlo@purdue.edu
Mon, 6 Sep 2004 08:12:20 -0500 (EST)
> 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.