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

[Adam Goode]

On 10/27/2009 03:02 AM, Wesley W. Terpstra wrote:
> On Tue, Oct 27, 2009 at 4:02 AM, Adam Goode <adam at spicenitz.org> wrote:
>>> 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.
> 
> I'm still puzzled as to why the software floating point doesn't
> support fesetround. The software emulation could test its own 'control
> word' (aka global variable) as easily as (easier than?) hardware.

The software floating point only supports default rounding, since that
is all that is required for ARM EABI compliance. For gcc, it
is the implementation here, once described to me as "magic":

http://gcc.gnu.org/viewcvs/trunk/gcc/config/arm/ieee754-sf.S?revision=148210&view=markup
http://gcc.gnu.org/viewcvs/trunk/gcc/config/arm/ieee754-df.S?revision=148210&view=markup


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/20091027/0f31f522/signature.pgp