Re: [ECOS] Q: Libm test vectors.

[Sergei Organov <osv at javad dot ru>]

Well, there is a mode in MPC505 when almost all the exceptional conditions are
handled by FPU. I believe this mode is preferable for PowerPC processors
because it's the fastest mode and doesn't require any software envelope.

In this mode it is guaranteed that FPU itself will *NOT* produce denormalized
numbers, so they can only come from outside.  If denormalized number appears,
then Floating Point Assist exception is invoked, and there is no way
to disable it or a simple way to handle this as far as I know (maybe I'm wrong
though). Anyway, in this mode appearance of denormalized number is true
exceptional condition likely caused by some bug in the program (uninitialized
value, etc.), so I don't think it should be hidden by flushing it to zero.

Sergei.

Jonathan Larmour <jlarmour@redhat.co.uk> writes:
> Sergei Organov wrote:
> > 
> > Hello,
> > 
> > Could somebody please tell me how the test vectors for the libm routines are
> > generated. It seems that they are rather random and even contain denormalized
> > numbers that cause problems on PowerPC when hardware floating point is used.
> 
> Yep, random is exactly what they are. That's never been entirely
> satisfactory I know.
> 
> But denormalized numbers should work. Anyone who does FP arithmetic has to
> deal with denormalized numbers every so often. The only other target we
> have right now that supports a hardware FPU is the VR4300 port, and if you
> look in hal/mips/arch/VERSION/src/mipsfp.c you'll see that we needed to add
> code there to deal (in a fairly simple way) for the lack of hardware
> support for denormalized numbers.
> 
> Does the PPC support a "flush denormal numbers to zero" type of flag?
> 
> Jifl
> -- 
> Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223) 728762
> "Plan to be spontaneous tomorrow."  ||  These opinions are all my own fault