[MLton] Re: In hope of a release ...

[Wesley W. Terpstra]

On Fri, Oct 23, 2009 at 4:44 AM, Adam Goode <adam at spicenitz.org> wrote:
> Well, there are 2 things. First, in software floating point (the
> default), rounding mode is optional. Only round to zero is required.
> With hardware VFP, there is a control word. But as an optimization, you
> get 2 sets of instructions: ones that honor the control word, and ones
> that always to round to zero. The round to zero instructions are only
> used in the cases where C requires it (for casting), so that you don't
> need to save/restore the rounding mode for casting. Otherwise, the
> rounding mode should be as in IEEE.

This sounds much bettter than I'd thought. The software version sounds
like it would be non-conforming re: the basis. The hardware version
can support a full MLton port.

> We use fesetround from C99, but there is a bug in how glibc handles this
> on ARM, depending on how things were compiled and what the hardware is:
>
>  Behavior of fesetround with non-default rounding:
>
>   Compiled for softfloat, no VFP hardware: returns failure (good!)
>   Compiled for VFP, no VFP hardware: fails to run (good!)
>   Compiled for VFP, VFP hardware present: sets rounding mode (good!)
>   Compiled for softfloat, VFP hardware present: silent failure (bad!)

So if a program is compiled to use hardware floating point there is no
problem aside from excluding the weaker machines? Is the presence of
VFP correlated with the presence of >=256MB of RAM? If yes, then could
we just assume any machine using MLton has VFP hardware?

> glibc will always set the VFP if it is present, even if floating point
> is software. This can be fixed with making libgcc dynamically linked,
> and picking the correct floating point library at runtime instead of
> compile time, but this is not done yet.

So if you specified software float and there is hardware available,
programs transparently start using hardware? The fesetround then fails
b/c it doesn't set the hardware control word only the flag the
software floating point sees..?

Another solution might be to check for VFP hardware in fesetround and
if present set the control word. fesetround() always needs inline
assembler anyway.

> http://sourceware.org/ml/libc-ports/2009-04/msg00020.html

> They're in there: r7081, r7082.
Of course they are. -.-

> Primary Architectures
>  ppc64 (64-bit)

Has MLton ever been compiled on ppc64?

> As a related note, your work will be great for the secondary arches in
> Fedora, especially S390 which I started to look at but I didn't have
> access to hardware. I would love to have a new release!

Debian has s390 porter boxes. You can probably request access from the
relevant admin if you wanted it. Incidentally, s390 is *fast*. It
compiles MLton faster than kfreebsd-i386 despite lacking a native
codegen.