[MLton] Debian: sparc works

Stephen Weeks MLton@mlton.org
Wed, 22 Dec 2004 18:37:33 -0800

> 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
> #endif
> #ifndef FE_TONEAREST
> #endif
> ...

Done, except I used -1 for FE_NOSUPPORT.

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

As Matthew pointed out, this is a really hard goal, and to me it's not
clear it's worth the effort.  So, I'd like to keep that out of the
current planning.

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

Sounds good to me.

> What primitive types can the compiler support?

Currently, the supported primitive types are 

However, the only sizes supported for FFI are 8, 16, 32, 64.  Adding a
new size is hard, because the native codegen has to be told the
calling convention.

> (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. :-)

I trust you will know enough about the compiler soon enough so you can
do it yourself :-).

> > > How to pick SML's int and real is something I am less sure about.
> 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.

We can either choose the default based on the architecture, and let
the user change with a switch, or we could keep a little more
information in our notion of architecture.  Perhaps we could treat the
different AMD modes as variants of the basic AMD architecture.

  datatype AMD64Mode.t = Legacy32 | Compatibility | Full64

  datatype MLton.Platform.Arch.t = 
    | AMD64 of AMD64Mode.t