Date: Wed, 11 Jul 2001 08:28:13 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Patrick Mitran <pmitran AT tsp DOT ece DOT mcgill DOT ca>
cc: djgpp AT delorie DOT com
Subject: Re: libm question
In-Reply-To: <m6K27.21468$Sh2.1265904@carnaval.risq.qc.ca>
Message-ID: <Pine.SUN.3.91.1010711082443.1314I-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


On Tue, 10 Jul 2001, Patrick Mitran wrote:

> The program I'm writting should eventually run on unix/Linux boxes (for
> my personal use only) so using the erfc() is not going to make my code
> portatble.

??? AFAIK, erfc is available on most modern systems, including Unix and 
GNU/Linux systems.  You need to link with -lm, but that's all.

So why did you think erfc makes your code non-portable?

> 2. erfc calls ___ieee574_exp() which as far as I can tell is an
>     exponential function also implemented as a polynomial curve fit.
> 
> The last point raised an eyebrow. Why a curve fit when intel FPUs can
> do exponentiation?

libm which we use was written to be portable to many platforms, so it 
doesn't use Intel-specific instructions at all.  That's why we have an 
alternative implementation for the more popular math functions inside 
libc.a, which does use x87 instructions.  However, erfc is not one of 
those alternative functions.

> Also, I tried compiling a trivial file that just computed sin(2.0) with no
> #include "math" or -lm and it worked! Not only that, but when I
> disassembled it with gdb, the _sin function wasn't the one in libm, it
> actually used the fsin instruction! I'm pretty sure that on a Sun
> machine with gcc this would not have compiled.
> 
> What's going on here?

sin _is_ in libc.a and in libm.a.