This is the mail archive of the
newlib@sourceware.cygnus.com
mailing list for the newlib project.
Re: Q: mathfp goals.
Hi,
If the goal is speed, then in some places 'mathfp' seems strange. Consider,
for example, code for 'fabs'
=== mathfp ===
double
_DEFUN (fabs, (double),
double x)
{
switch (numtest (x))
{
case NAN:
errno = EDOM;
return (x);
case INF:
errno = ERANGE;
return (x);
case 0:
return (0.0);
default:
return (x < 0.0 ? -x : x);
}
}
=== math ===
double fabs(double x)
{
__uint32_t high;
GET_HIGH_WORD(high,x);
SET_HIGH_WORD(x,high&0x7fffffff);
return x;
}
I believe that on many processors the 'math' version is (much) faster due to
abscence of branches.
Did somebody *actually* compare speeds of both math versions? Are the results
available?
Am I missing something?
BR,
Sergei.
Ranjith Kumaran <ranjith@cygnus.com> writes:
> Hi,
>
> The main reason for mathfp is to have a libm that uses floating point
> routines where available instead of (slower) floating point emulation.
>
> Ranjith
>
>
> On 14 Mar 2000, Sergei Organov wrote:
>
> > Hello,
> >
> > What are goals of development of 'mathfp'? Is it speed/code size or
> > independence of availability of IEEE floating point or what? In other words
> > what are the main differences between 'math' and 'mathfp'?
> >
> > Thanks in advance.
> >
> > Sergei Organov.
> >