[MLton] Debian: sparc works

[Wesley W. Terpstra]

On Wed, Dec 22, 2004 at 04:04:35PM -0800, Stephen Weeks wrote:
> > Not every system supports all the rounding modes.
> > When FE_DOWNWARD, FE_TONEAREST, FE_TOWARDZERO, or FE_UPWARD is defined that
> > means the platform supports that mode. If it is not defined, then this mode
> > does not exist... Your use of _constant will lead to constants.c failing to
> > compile on less able platforms.
> 
> One solution is to put appropriate #defines in platform/<os>.h to make
> undefined constants, say, -1, and to put a test for them in
> IEEEReal.sml so that setRoundingMode raises an exception on such
> modes.

Actually, here's a simpler solution, in platform.h put:

#define FE_NOSUPPORT 627124 /* magic, we hope is none of the other #s */

#ifndef FE_DOWNWARD
#define FE_DOWNWARD FE_NOSUPPORT
#endif
#ifndef FE_TONEAREST
#define FE_TONEAREST FE_NOSUPPORT
#endif
...

The standard requires that these be defined only if they are supported.
os.h is no good because rounding is more or less CPU dependent, not OS.

> > primitive type in MLton? I don't mean user visible, just in the
> > primitive.sml stuff...
> 
> Why does the compiler need to know about these types, i.e. why should
> they be primitive?  It seems better to keep the compiler simple and to
> put the knowledge elsewhere, e.g. as type synonyms in a prelude :-).

Because time_t might be 40 bit or whatever, and there might not be a
char, short, int, long that corresponds to it. Maybe I'm over paranoid.
For DSPs it's even common to have types that aren't 8*x bits long.
I concede that for most modern platforms this will not be an issue.

Another reason is that if we want to make the C codegen warning free and
also obey the C aliasing rules, we may need to know the C types of things.
Note that pid_t and friends are primitives in gcc (actually __pid_t).

I suppose you could define Pid, Uid, Time, Size, etc to be the smallest 
SML compiler supported type larger than pid_t, uid_t, time_t, size_t, etc.
Alternately, if you can guarantee that the SML compiler types cover all of
the POSIX types' sizes, your prelude idea would work fine.

What primitive types can the compiler support?
Does it know all bit widths from 1-128 of Word and Int?
If yes, then I am all for your prelude idea.

If not, a prelude idea with the 'next largest' might be ok too.
The C runtime code will just have to carefully cast from Pid to pid_t.

(Yes, 128 will be needed b/c a 64*64 product results in a 128bit number, and
even though you haven't implemented the MUL instruction yet, I trust you
will do this at some point. :-)

> > How to pick SML's int and real is something I am less sure about.
> > SML int != C int; linux+C made int=32bit even on 64bit machines because of
> > legacy code. SML doesn't have this problem so we should get it right: 64bit.
> 
> That seems fine.  Also, if we're going to go to the work to make the
> basis library more portable and be able to handle basic types being of
> different sizes, dependent on platform, we might as well go that extra
> bit and add a compiler switch to control what size Int is.  That way,
> if space or legacy code is important, it is easy for a programmer to
> choose Int = Int32 on Alpha.

Oooooo, that would be fancy. :-)

Still, how do we pick the default?
... or even the candidate options? target/constants?

That's one of those damned 'not just CPU dependent' things.
Case and point, amd64: you may have a 32 or 64 bit kernel.

-- 
Wesley W. Terpstra