[MLton] Debian: sparc works

Wesley W. Terpstra terpstra@gkec.tu-darmstadt.de
Thu, 23 Dec 2004 00:36:56 +0100

On Wed, Dec 22, 2004 at 02:21:49PM -0800, Stephen Weeks wrote:
> I've eliminated all but the C99 implementation, as well as cleaned it
> up to remove the conversion between C99 names for classes and MLton
> names for classes.

Yeah, I read this...
What you did is fine for fpclassify since FP_NAN, ZERO, etc are all defined.
However, you killed all my #ifdefs around fegetround and fesetround...

Not every system supports all the rounding modes.
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.

> We actually have a lot of work to do here, since there are a number of
> hardwired type definitions in the basis library sources (in particular in
> misc/primitive.sml and posix/primitive.sml).

Yes, that's why I haven't done it yet...
gc.c also terrifies me. ;)

> The one idea I've had along these lines is to automatically generate
> for each target an SML prelude for the basis library implementation
> that defines all the types.

How nasty would it be to make every C type needed by the runtime a primitive
type in MLton? I don't mean user visible, just in the primitive.sml stuff...

If C's pid_t, uid_t, int, long, short, char, etc were all available to the
basis library, that would be ideal. As long as the C FFI supported it, we
could copy the C prototype straight into SML. The type conversions would be
much safer to do outside of C where casts are forbidden. ;) The SML types
int, real, char would be decoupled completely from C types of similar name.

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.

Another problem with my suggestion is conversions. It is conceivable that
some types may be larger than whatever we pick for SML's int. Hopefully we
never need to do a conversion, but you never know with C APIs. =)

Wesley W. Terpstra