Mail Archives: djgpp/1998/10/02/14:00:16
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
- Raw text -