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

[Adam Goode]

On 10/23/2009 02:35 AM, Wesley W. Terpstra wrote:
> 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.
> 

Well, I would say it could be barely conforming, since the basis appears
to tolerate implementations to throw an exception rather than implement
rounding modes.

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

Unfortunately, VFP is still very much an optional feature. In fact, if
you have an XScale, I don't think it is even available.

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

There is no transparent use yet, but this is possible when glibc is
compiled in multilib mode. There are a few issues to work out, but it
could be done. I looked at it months ago, but nothing recently. This
would solve the problem with rounding modes: if you have hardware,
you'll automatically use it, if not, fesetround will fail and MLton will
throw the exception. Right now if you have hardware, fesetround will
succeed but the rounding mode will be effectively ignored.

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

Yes, that is what fesetround does. Unfortunately, it can't know if
you're actually going to use the VFP from then on! By default, you
don't, so the rounding mode is set in the hardware you're not using.

> 
> Has MLton ever been compiled on ppc64?
> 

I have not compiled it there. I suppose I could try to get an account
somewhere, but haven't gotten around to it.

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

Nice! I should check to see if Fedora offers these things. The emulator
is SLOW.



Adam

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
Url : http://mlton.org/pipermail/mlton/attachments/20091026/734f058c/signature.pgp