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

On Tue, 2001-11-20 at 16:44, Keith Whitwell wrote:

Keith Whitwell wrote:

quoted

quoted

quoted

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/