[MLton] Debian: sparc works
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
> #define FE_DOWNWARD FE_NOSUPPORT
> #ifndef FE_TONEAREST
> #define FE_TONEAREST FE_NOSUPPORT
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
> 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
> (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