Subject: Re: shocking speed performance!
To: None <richard.earnshaw@arm.com>
From: None <kim@pvv.ntnu.no>
List: port-arm32
Date: 05/21/1999 16:10:41
> > > 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.

What a mess. 

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

Division and modulo are integer operations, and therefore belongs in
those libraries that are always linked.

-lm should link in math functions. When I worked with 68000, I had
several math libraries to work with, some for speed, some for accuracy,
and some for IEEE compliance, and some for FPU. 

In my experience, it has always been the users responsibility to specify
-lm
when compiling code with math.

> > On some platforms there are several math libraries, with different
> > properties. 
> 
> Not usually for the low-level functionality we are talking about here.

How come I have seen it so often if it is not usual?
In my experience, it is usual, and the common way of doing it.
Besides, it is more logical to put math in the math library.

> > Putting math in libc makes things messy. 
> > Why not put it where it belongs?
> 
> See above.  Changing it is, unfortunately, far from trivial.

Does this mean that no NetBSD versions are capable of handling
processors with different and variable floating point systems?
It seems that is the case based on your word.

This is sad.

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

Please read me more carefully. I wrote "some years ago", which is clearly
NOT today. I am getting tired of repeating myself.

Kim0