[MLton] power pc "port"

[Filip Pizlo]

> > 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.

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.  Or are there no others?

> 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.

Good to know.

> 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.

Will do both of those things.

> 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.

Right.  I have a question, which is probably very naive: why can't I use
print from within basis-library/integer/int.sml?  Is there some other
tracing facility (other than hacking the generated C code) that I can
invoke from within the basis?

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