[MLton] power pc "port"

[Matthew Fluet]

> Just an update, the regression tests fail on fixed-integer and on real
> (apparently not doing rounding correctly - that would be a bug in my
> code).  Notably, they succeed for the int test.

Wow.  That's pretty impressive for the first round of regressions after
completing a port.

> bin/regression: line 213: gmake: command not found
>
> 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'?  Anyway, for now, I'll make them use 'make'
> just to see what the outcome of the tests is.

It shouldn't really matter.  gmake is only used to try to compile mllex,
mlyacc, and mlprof, and that is only checking the type-checker.  So, you
won't learn anything new there.

> > > Can someone give me an estimate of how long they take on a fairly
> > > average PC?
> >
> > one hour
>
> It took two hours to reach the above gmake failure.

That's probably expected.  On a PC we can use the native codegen and a
compiler built with the native codegen, so there is a decent speedup
there.  Your compiler is built using the C codegen and running on a laptop
(IIRC), so two hours sounds o.k.

> > It's tough to read much into your test, since gcc will likely simplify
> > everything away at compile time.  It would be better to test calls to
> > the library routines in separately compiled C files, as they are in
> > libmlton.  You could have your C code call Word{8,16,32,64}_{quot,rem}
> > and link with libmlton.a.  Running through all pairs of args from -100
> > to 100 should be a pretty good test.
>
> Ah, OK.  However, is it safe to assume that since the int regression test
> succeeded, then quot and rem work?

I would think so, although it may still be worth trying Stephen's
suggestion.

Without much else to go on, here are a few little things that I would try:
- see if fixed-int.sml succeeds with just the Int32 test.
- see if fixed-int.sml succeeds with Int16, Int64, Int8
- then start trying the non-standard sizes.

Unfortunately there aren't any other regressions that look at the
non-standard integer sizes.  On the other hand, all the operations are
just implemented by lifting to the larger standard size, so there isn't
much that can go wrong.