Q: mathfp goals.

[Sergei Organov]

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.
> >