Re: rfc: replacing fp-bit with glibc's soft-fp implementation

[Richard Earnshaw <rearnsha at arm dot com>]

> I've talked with this over with Geoff and Richard on and off over the 
> past few months, and I've finally decided to give it a go.  Before I 
> sink any time into it, I'd like to get people's input, to make sure 
> there are no objections.
> 
> Glibc's soft-fp/ implementation (also used in the Linux kernel) is both 
> faster, and more accurate.  Not to mention, it also provides exceptions 
> and rounding modes.

Can these be disabled if a user wants faster code, or has code that relies 
on behaviour such as flush-to-zero and no-nans?

> If done right in both glibc and gcc, we can even provide a completely 
> soft float implementation that is IEEE/ISO compliant for systems that 
> have no hardware floating point.  We would of course have to define an 
> interface between libgcc and glibc to set rounding modes and exceptions.

I'm in favour of anything that improves the FP emulation performance (who 
wouldn't be?) but there is a potential stumbling block in that the code 
you are replacing is GPL with exception, while presumably the code in 
glibc is LGPL.  Has the suggestion been cleared with RMS?

Finally, this "interface" you mention also needs to work when the C 
library is not glibc, particularly in the embedded space.

R.