topic Re: nonIEEEconform floats in CodeWarrior for MCU

nonIEEEconform floats

fak — Mon, 16 Nov 2009 16:27:02 GMT

working with CW 6.1 and a MC13213 i ran into problems with the floatingLib.

I constructed a snippet that brings up the kind of problem. (even in the true-time-simulation)

I calculate x3 = (2.5e-11) - (1.7e-20)*(1.7e-20).

and would expect one of the following:

2.5e-11 (plus minus some rounding error), or NaN, or +Inf , or -Inf.

But I get: x3==-3.34...e+37

And this is not conform to IEEE 754 as far as i can see.

I already tried using a Service Request, but it got closed.

And i have no solution to the problem yet.

Q1: are you able to reproduce the behavior?

Q2: can you understand, why i expect a different result?

Q3: is this conform to IEEE in your opinion?

Q4: do you know a solution?

Aswers to any of these Questions is welcome.

many thanks

Fabian

int main(){
     volatile float x1;
     volatile float x2a;
     volatile float x2;
     volatile float x3;
     x1=2.5e-11; /** this is within normalized range **/
     x2a=1.7e-20; /** this is within normalized range **/
     x2 = x2a*x2a; /** this is within denormalized IEEE754
range **/
     x3=x1-x2;     /** this goes wrong i think **/

SOPT_COPE=0;
while( x3<0 ); /** this halts, but should not **/

for(;; /** this should halt but is never reached **/

}

Re: nonIEEEconform floats

kef — Mon, 16 Nov 2009 18:05:15 GMT

I calculate x3 = (2.5e-11) - (1.7e-20)*(1.7e-20).
and would expect one of the following:
2.5e-11 (plus minus some rounding error), or NaN, or +Inf , or -Inf.

2.5e-11 is the right answer. NaN and Inf would be wrong.

But I get: x3==-3.34...e+37

With CW6.3 I got -2.889996e-040 (- (1.7e-20) ^2 ) , which is also wrong.

And this is not conform to IEEE 754 as far as i can see.

Of course.

I already tried using a Service Request, but it got closed.

not good

And i have no solution to the problem yet.

Q1: are you able to reproduce the behavior?

Yes. Different answer but also wrong.

Q2: can you understand, why i expect a different result?

Of course yes.

Q3: is this conform to IEEE in your opinion?

Q4: do you know a solution?
Aswers to any of these Questions is welcome.

It can be solved this way 1) testing existing FP routines implementation for IEEE conformance. Everything can be found here: http://www.math.utah.edu/~beebe/software/ieee/

2a) Using slow but already tested SoftFloat http://www.jhauser.us/arithmetic/SoftFloat.html

2b) rolling your own FP emulation routines and testing them at least with W.M.Kahan's Paranoia.c

Re: nonIEEEconform floats

CompilerGuru — Thu, 29 Oct 2020 08:58:44 GMT

Why did support close the service request?

Getting completely off results seems just wrong to me .

Can you try to reopen it? With such a simple snippet to reproduce it, it should not be hard to fix.

When stepping through the code the BCS in _FADD_K_is_K_plus_L seems wrong to me.

It does a unsigned 16 bit comparison of the exponents, but the exponents are negative for denormalized numbers, therefore the comparison should be signed.

See below for a quick (and just with a few samples tested...) fix for the issue.

Daniel

BTW: Same issue for double (64 bit).

ADDKL_Normal:                        ; // L and K are not special (means not 0,NAN,inf)
              LDA     Kexp:1
              SUB     Lexp:1
              TAX
              LDA     Kexp:0
              SBC     Lexp:0

// Use a signed comparison, Kexp and Lexp are both signed, < 0 for denormalized numbers
              BLT     ADDKL_0   ; // K:exp < L:exp
//            BCS     ADDKL_0   ; // K:exp < L:exp
              TXA
              BEQ     ADDKL_1   ; // K:exp >= L:exp
              TST     Kexp:0    ; // R2780 negative Kexp not handled!
              BLT     ADDKL_0   ; // K:exp < L:exp
    ADDKL_3:  ;

Re: nonIEEEconform floats

CompilerGuru — Tue, 17 Nov 2009 03:16:58 GMT

I've added the issue as MTWX38839 in the internal bug database.

Daniel

Re: nonIEEEconform floats

CompilerGuru — Tue, 17 Nov 2009 03:34:29 GMT

As note, to use the fixed code snippet, copy {}/lib/hc08c/src/rtshc08.c to your project,

add it to your project and then move it in the link order above the ANSI library.

Then in the local rtshc08.c search and replace the pattern as shown in the previous posting.

It occurs twice, once for 32 bit floats and once for 64 bit doubles. Then compile and link.

Make sure in the map file that the modified rtshc08.c is taken, and not the one out of the ANSI library

(fix the link order if the one from the ANSI library is still used).

Daniel