Quote:
Originally Posted by Thomas Richter
Actually, ISO C requires the rounding mode to be adjustable, right?
|
Correct. There is
fesetround()
since C99, but I'm refering to the default behaviour on startup which is defined in section F.7.3 Execution:
Code:
At program startup the floating point environment is initialized as prescribed by IEC 559:
(...)
- The rounding direction mode is rounding to nearest.
Quote:
|
If the mathieeedoubbas.library is run on the FPU, and is opened correctly - that is, by the same task(!) that runs the calculations, it configures the FPU as of 3.1.4 and below in "round to zero", double precision. This is *not* a particularly good choice, but it is consistent with the choice the library makes if run on the CPU.
|
Ok. Thanks for clarification. That's what I was afraid of. So this is a constant source of problems when using the MathIEEE libraries for a C compiler's mlib. And probably also the reason why SAS/C didn't use them.
EDIT: BTW, does it mean that the rounding mode in FPCR for an FPU could be misconfigured by the MathIEEE library? At which point? When opening the library? As far as I remember FPCR is zero (round to nearest) when a program uses the FPU without MathIEEE libraries.
Quote:
|
Now, on 3.2, things changed (and this was a major task). Now, if the library is run on FPU, it implements "IEEE aware round to nearest", and the same(!) also goes for the CPU implementation.
|
A bit late but... very nice! Thanks for that.
Quote:
|
The mathieeedoubbas was verified with the "Paranoia test".
|
Indeed, the Paranoia test is part of our compiler testsuite and the MathIEEE libraries always behaved surprisingly good. Even better than John R. Hauser's Softfloat Library, IIRC.