Re: PPC FPU handling [was: Re: NaN patch]

Re: PPC FPU handling [was: Re: NaN patch]

[Michel Dänzer]

On Tue, 2001-11-20 at 16:44, Keith Whitwell wrote:
> Keith Whitwell wrote:
> >
>
> > >
> > > I'd consider adding NaN-checking code to the indirect rendering path,
> > > since it's slow anyway but am hesitant to add it to client-side (and
> > > hardware) code for performance reasons.
> > >
> >
> > Well rather than doing this, can we isolate where the bug is and wrap that
> > section in START_FAST_MATH/END_FAST_MATH.  I'm pretty sure this sort of
> > explicit NaN checking isn't in the SI, and if you think about what code is in
> > the indirect path but not the direct path, it doesn't add up to much -
> > certainly not worth this heavyhanded approach.  Alternately there might be
> > some code that could be slightly tweaked to avoid the crashes.
> >
>
> OK.  There is no implementation of START_FAST_MATH/END_FAST_MATH for PPC (this
> is a macintosh-specific problem).

No, it's not. :) But it's funny you mention this, the following code in
mmath.h doesn't look right to me:

/* The mac float really is a float, with the same precision as a
 * single precision 387 float.
 */
#if defined(macintosh)
#define HAVE_FAST_MATH
#endif


Shouldn't that rather be #if defined(__powerpc__) ?


>  One is required for this and every
> architecture which runs Mesa, otherwise there is a need for a check on every
> single float that comes into the api, which is in the squillions.  Have a look
> at mmath.h in xc/extras/Mesa/src, and try and do something similar.
>
> The big requirement is to turn off the ieee inf/nan exceptions (on the x86 we
> also stop the fpu keeping excess precision).  Turn the exceptions off in
> START_FAST_MATH (and back to their original state in END_FAST_MATH) and your
> problem should go away.  The documentation of these macros only talks about
> precision in 3.4.2, but is accurate in 4.0.


Also, further down:

#if defined(__i386__) || defined(__sparc__) || defined(__s390x__) || \
    ( defined(__alpha__) && ( defined( __IEEE_FLOAT ) || !defined( VMS )
) )
#define USE_IEEE
#define IEEE_ONE 0x3f7f0000
#endif


Shouldn't these be defined for __powerpc__ too, or isn't the PPC FPU
IEEE conformant (or what do these defines mean anyway)?


Looking forward to any insights...


--
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member   /  CS student, Free Software enthusiast

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/