[MLton] power pc "port"

[Filip Pizlo]

Good news and bad news: the good news is that fixed-integer is now
passing.  That means that the only regression test not yet passing (other
than the ones after mllex, which I'm just now getting around to running)
is real.sml - and that's because I probably made a silly mistake in
implementing setRoundingMode.  The bad news is that the problem observed
in the _neg function is much more widespread.

In fact, all of the sub-32-bit word functions either do a sign extension
or apply the 0xff mask before returning.  This means that for any sequence
of sub-32-bit word operations that contains a mix of signed and unsigned
arithmetic, things get really messed up really quickly.

I see four solutions:

1) Separate all word functions into signed and unsigned.

2) Rewrite the word functions in assembly so that they do not apply the
mask.

3) Implement sub-32-bit words by embedding them in a 32-bit word at the
SML level.  Will this violate any specifications?

4) Have the functions for which sign matters (like quot and rem) do a sign
extension before proceeding with the operation.

For now, I have implemented (4) by way of a fairly nasty hack.  It turns
out that stuffing a value into an array and then retrieving it forces sign
extension, even with optimization enabled.  I could implement it using
inline assembly, but I wasn't sure if that was a good idea style-wise.

Anyway, I have verified that it fixes the problem.  However, I'm not sure
that it is the right long-term solution, since it is not clear that the
same hack will work on other architectures for which this is an issue.

Option (2) seems like it might be a fine way to go.  In fact, I was
thinking of just writing a Word.S file for PowerPC.

I don't know about option (3) because I'm not sure I fully understand the
motivation for the sub-32-bit integer types.

Option (4) seems like it would be the best long-term solution, since it
would require no assembly, and it would make the PowerPC end work without
disturbing the X86 and SPARC side of things.  It does seem that this
solution would require a fair bit more foot-work, judging by how the C
code is generated.

Thoughs?

--
Filip Pizlo
http://bocks.psych.purdue.edu/
pizlo@purdue.edu


On Sun, 5 Sep 2004, Filip Pizlo wrote:

> > Henry and/or Stephen can probably chime in with more info, but is GCC
> > really right here?  Word8_neg is specifying an 8-bit negation -- a
> > perfectly well defined operation which given 8 bits returns the 8-bit
> > negation.  While it may be the case that the implementation needs to side
> > step through 32-bit operations, why can the end result look any different
> > than what would happen under an 8-bit machine?
> 
> Well, here are more details according to the C standard.  Consider the
> Word8_neg function, which is defined as follows:
> 
> unsigned char Word8_neg(unsigned char w) {
> 	return (- w);
> }
> 
> The steps that happen are:
> 
> 1) w must be promoted for the negation to be performed
> 2) the negation is performed
> 3) the result of the negation must be converted for the return, which
>    requires an unsigned char type.
> 
> In step (1), the unsigned char is promoted to int.  See sections 6.3.1.1
> (defined what promotion means) and 6.5.3.3 (defines what negation means)
> of the C standard.
> 
> In step (2), the negation happens; this is nothing special.  Note that the
> value produced by the negation is still an int.
> 
> In step (3), a conversion from a signed type (specifically, int) to an
> unsigned type (specifically, unsigned char) occurs.  In section 6.3.1.3 of
> the C standard, in paragraph 2, it states:
> 
> "Otherwise, if the new type is unsigned, the value is converted by
> repeatedly adding or subtracting one more than the maximum value that can
> be represented in the new type until the value is in the range of the new
> type."
> 
> Note that this is exactly the same as doing:
> 
> 	return (- w)&0xff;
> 
> Hence, the masking that GCC is doing is quite correct with respect to the
> C standard.
> 
> --
> Filip Pizlo
> http://bocks.psych.purdue.edu/
> pizlo@purdue.edu
> 
> 
> _______________________________________________
> MLton mailing list
> MLton@mlton.org
> http://www.mlton.org/mailman/listinfo/mlton
>