Date:	Mon, 10 Jun 2002 08:55:15 +0300 (WET)
From:	Andris Pavenis <pavenis AT lanet DOT lv>
X-Sender:	pavenis AT ieva06
To:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
Cc:	sandmann AT clio DOT rice DOT edu, djgpp-workers AT delorie DOT com, Kbwms AT aol DOT com
Subject:	Re: ISO C99 double math functions
In-Reply-To:	<2950-Sun09Jun2002194245+0300-eliz@is.elta.co.il>
Message-ID:	<Pine.A41.4.05.10206100849160.32640-100000@ieva06>
MIME-Version:	1.0
Reply-To:	djgpp-workers AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Sun, 9 Jun 2002, Eli Zaretskii wrote:

> > From: sandmann AT clio DOT rice DOT edu
> > Date: Sun, 9 Jun 2002 11:06:01 -0500 (CDT)
> > 
> > Unless there are legal reasons to do so
> 
> I don't think there are legal reasons, but DJ should give the
> definitive say-so.
> 
> > Maybe we should move all of libm into libc, make libm an empty shell, 
> > and replace the old libc functions with the libm ones.
> 
> The ``old'' libc functions are actually newer than libm: they were
> rewritten in preparation for v2.03 to be fast but ANSI-compliant, and
> to utilize the x87 coprocessor to the greatest possible degree.
> 
> > If we removed all of our definitions which are redundant with fdlibm,
> > and just build fdlibm modules as part of the libc, what are the drawbacks?
> 
> The main drawback is that we lose the fast libc routines added for
> v2.03.  I don't want to lose them.
> 

I think we should even add additional math functions to libc.a to put
faster (using coprocessor) functions there as functions from libm are 
slower. Perhaps we should have all functions used in libstdcxx.a in
libc.a 

Or other way: it could be possible to have 2 versions of libm -
	- one fast one using coprocessor
	- slower one based on fdlibm

Andris

- Raw text -