[MLton] power pc "port"

[Filip Pizlo]

> > The problem here is that Mac OS X doesn't have a 'gmake', although
> > 'make' is the GNU version.  Is there a need to make some of the
> > scripts refer to 'gmake' instead of 'make'?
> 
> I remember running into problems on some platforms (FreeBSD IIRC) that
> have both make and gmake.  We definitely use GNU-style Makefiles and
> so need gmake on those platforms.  It should be easy enough for you to
> add a script in your path called gmake that does the right thing.
> Maybe we should try to put such a script in bin/mlton?

I was thinking about putting a script in bin that first tries to find
gmake, and if it isn't found, it'll call make.

What do you mean by putting such a script in bin/mlton?  I thought
bin/mlton was itself a script?  Or did you just mean bin?

> No.  int isn't as thorough as fixed-integer, and it doesn't test sizes
> other than Int32.
> 
> > Aren't there tests after mllex?  The problem is that this error
> > halts the bin/regression script... so getting around it will let me
> > run the rest of the regressions.
> 
> One thing you can do is take out the set -e at the beginning of the
> script.  We have it there so the script screams loudly if something
> goes wrong.  But it's sometimes useful to take it out to get through
> more tests.

Ah, that's useful to know.

> As to finding the problem in fixed-integer, Matthew's suggestion was
> good.  One other thought -- I'm unsure whether you're using a compiler
> running on MacOS or a compiler running on Linux.  If the former, you
> may be running into problems with bugs introduced in building MLton.
> I'd recommend using a MLton built on Linux and running on Linux, cross
> compiling to MacOS.  That takes out one possible source of errors.

To answer your question, the compiler I'm using had its C code generated
on Linux and was then compiled and linked with my Mac's GCC.  So that's
about as 'pure' as I could get, considering that I don't know how to
cross-compile from Linux to Mac OS X.

I'm slowly making progress in the fixed-integer.  I'm pretty sure that
it's got to do with PowerPC calling conventions.  But before I go into
details, I'd like to know more about the following:

1) Why does int.sml's fmt function first ensure that its input is negative
and then negates the result from rem?  Why not operate on the
positive absolute value instead?

2) Is it really the case that the WordAAA_BBB functions are not declared
in any header file, and that the C compiler must make assumptions about
their signature?

Basically, it turns out that fixed-integer only fails for integers whose
representation is 16 bits or 8 bits.  The thing that is special about 8
bits and 16 bits is that PowerPC has only 32 bit arithmetic (well, that's
the case for my PowerPC - so there may be other problems when doing this
on a 64-bit PowerPC), so 8 bit and 16 bit numbers get passed around in
32-bit registers with the upper bits either zeroed or sign-extended.  
However, bad things can happen if the C compiler doesn't know that the
function it is calling takes an argument that is less than 32 bits
wide.  Although I have not gotten to the root of the problem, it seems to
me that the rem computation in fmt's loop fails and gives a wildly
incorrect number, which then causes StringCvt.digitToChar's sub lookup
fail.  Indeed, it is the sub function that is throwing the Subscript
exception.

I've got some other work to take care of now, but I'll return to this bug
later on today.

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