Re: [avr-libc-dev] Bug in math library

[Marek Michalkiewicz]

Hi,

On Sat, Jan 08, 2005 at 03:47:34PM -0400, Colin O'Flynn wrote:

> At any rate the problem lies in the fp_split.S file. The file says this:
> 
> CLR     rBE            ; clear fraction extension
> cp      rBE,rB3        ; set C if nonzero exponent.  -MM 2000-11-25
> brcs    1f
> ldi     rB3,1          ; zero exponent really means 1 with hidden bit = 0
> 
> If the exponent is nonzero, it sets it to 1.

If the exponent is _zero_, it sets it to 1.

Note the order of "cp" operands: if (0 < rB3) then skip the "ldi".

> This breaks the test completely - 
> as far as I can tell this is a pretty big problem. I don't know enough about 
> avr-libc's "special" floating-point format to understand why there is this 
> 'hidden bit' thought, which is why I just didn't make a patch.

This is the standard IEEE float format, "hidden bit" is explained here:

http://en.wikipedia.org/wiki/Floating_point

> At any rate it is my guess that the math library has been broken since 
> 2000-11-15, which is when it looks like that fragment was added. To me this 
> seems fairly large, as it also breaks a number of other routines with "zero 
> tests" in them.

If I remember correctly (it was long time ago...), this was a fix
for some bugs with very small (close to zero) numbers.  But, you may
be right - it looks like one bugfix introduced another bug :(

I suspect these "zero tests" should test the fraction (rA2:rA1:rA0),
not the exponent (rA3).  The "hidden bit" is un-hidden by fp_split
and becomes rA2 bit 7.  For approximate testing (very small "denormal"
numbers considered equal to zero), test only rA2.  For testing if
a number is exactly equal to 0, test all of rA2:rA1:rA0 (not sure
about rAE where it is used - seems to be zero almost all the time).

Disclaimer: please don't trust me too much, and double check to
be sure whatever I said above makes any sense ;)

Hope this helps,
Marek