> [ SoftFloat functions in libc ]

There is a reason for it. Imported programs (and even programs in our tree)
expect to link only with libc unless they call transcendental functions or
other things that require -lm linkage.

Just because a program uses a particular C built-in (float, double) doesn't
mean it needs to link with -lm on any other major OS. If we impose that
requirement tons of third-party Makefile's and other build scripts would
break. (Not to mention some of our own.) This means the functions have to
go into libc or libgcc.

NetBSD uses an early version of a high-quality and fairly fast FP package.
As "C" implementations go, it's pretty good.  I'm now upgrading this to a
more recent version.  To go faster, the most obvious approach would be to
optimize the most common ops with some hand written assembly or even just
tweak the library with things like the gcc __inline.

	Ross.Harvey@Computer.Org

> From: Richard Earnshaw <rearnsha@arm.com>
>
> > > kim@pvv.ntnu.no said:
> > You put math functions in libc?
>
> I didn't put them anywhere.
>
> Normally a gcc implementation would put them in libgcc.a, since they are 
> support libraries for a compiler implementation.  The NetBSD implementors 
> chose to place most of the functions from that library in libc.so 
> (presumably to simplify shared library handling for the common case).  I 
> had nothing to do with that decision; I'm not entirely happy with it, but 
> I have to live with it.
>
> > That is the wrong place.
> > Math functions should be in the math libraries.
>
> These functions are low-level compiler-generated routines which happen to 
> be needed to support the base floating point implementation.  The have a 
> parallel to the division and modulo support functions that are required 
> for many RISC processors (including the ARM).  They do not belong in a 
> user-linked library (such as libm), which is only linked in at the option 
> of the user.
>
> > On some platforms there are several math libraries, with different
> > properties. 
>
> Not usually for the low-level functionality we are talking about here.
>
> > 
> > Putting math in libc makes things messy. 
> > Why not put it where it belongs?
>
> See above.  Changing it is, unfortunately, far from trivial.
>
> > Also as mentioned earlier, I worked 3 months of evenings on this project
> > some years ago, and was stopped by uncompilable gcc. I have told you
> > about this project several times before in these years.
> > 
>
> But this is clearly not true.  Numerous people successfully compile the 
> standard gcc and egcs distributions in addition to the in-tree NetBSD 
> copy.  Just saying it is not compilable doesn't help us to help you (we 
> aren't psychic).