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

[Aldy Hernandez <aldyh at redhat dot com>]

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

By user, do you mean at runtime, or at library build time?  At build 
time, it's pretty easy:

	#define FP_SET_EXCEPTION /*NOTHING*/
	#define FP_UNSET_EXCEPTION /*NOTHING*/
	#define FP_CLEAR_EXCEPTIONS /*NOTHING*/
	#define FP_DECL_EX /*NOTHING*/
	#define FP_HANDLE_EXCEPTIONS /*NOTHING*/
	#define FP_ROUNDMODE FP_RND_ZERO
	etc

If you mean at runtime ala "gcc -msoft-float -mfast-soft-float", then 
that functionality would have to be added.  Perhaps we could provide 
fast soft float libraries and slower-but-accurate soft float libraries. 
 Or set accuracy off by default, and provide hooks in both newlib and 
glibc to enable exceptions, nans, and rounding.

...but I don't like either of these [runtime] approaches.  Although we 
need to actually benchmark the current fp-bit implementation and 
glibc's soft-fp implementation, I'm willing to bet that glibc's is 
faster, even while handling exceptions and nans.

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

Ah.  Very good point.  No, I haven't brought it up with RMS, but I can 
do that in a follow up email.

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

Yup.

Aldy