Message-ID: <3615143B.C9E4E93F@cyberoptics.com> From: Eric Rudd Reply-To: rudd AT cyberoptics DOT com Organization: CyberOptics X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 Newsgroups: comp.os.msdos.djgpp Subject: Re: question about libm References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 46 Date: Fri, 02 Oct 1998 12:58:19 -0500 NNTP-Posting-Host: 206.144.150.73 X-Trace: news2.randori.com 907351016 206.144.150.73 (Fri, 02 Oct 1998 10:56:56 PDT) NNTP-Posting-Date: Fri, 02 Oct 1998 10:56:56 PDT To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Andris Pavenis wrote: > > > > When I use the libm.a that is included with djgcc, is this a software > > > > implementation of the the transcendental functions or is there any inlining > > > > to take advantage of a math coprocessor? > > > > No; libm is probably slower with respect to math functions; it doesn't > > > use the coprocessor as much as it might. It is, however, more compliant > > > to ANSI in such areas as setting `errno' on errors. But there are some > > > functions that only libm provides, like gamma. > > > My application is an extremely heavy user of pow() and log(). What > > I'm interested is will the libm use a math coprocessor for these > > functions or will it run them in s/w.. Reading between the lines, I think the original question was about the *level* of coprocessor support in the functions. At one extreme, one could implement the functions with no coprocessor support (emulation, in other words), and at the other, one could use the transcendental instructions in the coprocessor. The libm.a functions take a middle course: the coprocessor is used, but only for floating-point arithmetic. The transcendentals are done by series expansions. This has the advantage of portability, but is somewhat slower than using the coprocessor transcendentals. There is no x87 coprocessor instruction for pow(), so this has to be done in software using simpler functions such as exp() and log(). > I think the best would be to have 2 versions of libm.a to choose. > Poeple that wants more ANSI compliant version will then be able > to use version that now is in alpha versions of DJDEV202 and poeple > who want faster library will be able to use it. The current libc functions make full use of the coprocessor transcendental instructions, but some functions, notably asin() and most of the hyperbolics, have serious accuracy problems. They will also bomb with a traceback for exceptional arguments, which ANSI does not allow. I am currently working on replacements for the libc math functions, with the aim of upgrading them in accuracy without incurring much of a speed penalty. They will also be ANSI compliant. The aim is to make them good enough that one can use libc.a by default, and libm only for the higher mathematical functions (gamma, Bessel, etc.). -Eric Rudd rudd AT cyberoptics DOT com