Does P2020 conforms to the IEEE 754?

Showing results for 
Search instead for 
Did you mean: 

Does P2020 conforms to the IEEE 754?

Contributor I

In one of my applications, I verify that the double-precision value is not a NAN value. 

According to the IEEE 754, NAN == NAN is false. But the code that GCC generates for this condition:

             efdcmpeq  cr7,r10,r9

sets cr7 to 4 (cr7 gt) when r10 and r9 are set to NAN. In the end, it produces true as result of the comparison.

So who is wrong: GCC, P2020, or I do something wrong?

Tags (1)
0 Kudos
3 Replies

Contributor I

Maybe i can put in more clearly in a different way. I want to use the double precision support in hardware. I have managed to adapt the build process so that i see that instructions are issued in HW instead of calling soft-float libraries. The software also runs much faster compared to soft-float library. The results i am getting from the HW-Float build is slightly different from the soft-float version. I guess there are some corner-cases which are not handled correctly.

What i have understood by reading § of SPE PEM is that there is a difference in the behavior when the SPE module provides results compared to what i am used to in other processors. When i understood it correctly disabling traps has effects on the results -> meaning when i disable a certain trap i will get a "default" result which can be used for further computation -> What is the behavior in the sticky flags in this case. Are they set until i deliberately reset them by writing a zero to them. Are the other conditions in which they are cleared?

The SW under Test shall run in two modes:

1. Normal operation. In this mode i have to following configuration:

1.1 Rounding to nearest, SPEFSCR[FINVE] = 1, SPEFSCR[FUNFE] = 1, SPEFSCR[FOVFE] = 1, SPEFSCR[FDBZE] = 1, SPEFSCR[FINXE] = 0

1.2 In this mode calculations do not expect problems as the input data used for calculations are within the expected limits. All of the exceptions are enabled except INEXACT. Does disabling INEXACT exceptions generate "defaults" during computations?

2. Potentially illegal operations - We perform e.g. matrix inversions which could be a problem (singular matrix). In other processors we simply disable traps and perform the operations. After the e.g. matrix inversion has been completed we check the sticky bits to see if we have accumulated traps over the last calculations (overflow, underflow, division by zero, invalid operand/operation). If we detect such traps we dump the result of the matrix inversion and notify continue.

2.1 Rounding to nearest, SPEFSCR[FINVE] = 0, SPEFSCR[FUNFE] = 0, SPEFSCR[FOVFE] = 0, SPEFSCR[FDBZE] = 0, SPEFSCR[FINXE] = 0

2.2 From what i have understood this approach may not be working anymore since disabling exceptions has effects on sticky flags resp. intermediate results of larger operations?




0 Kudos

Contributor I

Hi, i looked up all threads and documentation about the IEEE 754 compliance topic. Can you provide additional information how i could get an better overview on this topic?

I still haven´t figured out in which cases special handling would be required. What i have found in other forums was that the rounding modes (infinity+, infinity-) require special handling using SW-Traps to be fully IEEE 754-compliant. I do not plan to use this mode as i want to use "round to nearest" exclusively. Can you confirm that for this rounding mode no additional trap handling is required?

Are there any further limitations i have to deal with? According to the previous post the only instruction worth mentioning is  efdcmpeq? I have not noticed this instruction at all to be relevant for this topic. Maybe i am looking on the wrong things?

What about the note_1 in  Table 3-37 of the PowerPC e500 Core Family Reference Manual:

"Exception detection for these instructions is implementation dependent. On the e500, Infinities, NaNs, and Denorms are
always be treated as Norms. No exceptions are taken if SPEFSCR[FINVE] = 1. "



0 Kudos

NXP TechSupport
NXP TechSupport

Embedded floating-point operations largely comply with the IEEE-754 floating-point standard.

Software exception handling is required to achieve full IEEE 754-compliance because the IEEE floating-point exception model is not fully implemented in hardware.

Please refer to the PowerPC e500 Core Family Reference Manual, efdcmpeq Floating-Point Double-Precision Compare Equal:

"If the contents of rA or rB are Infinity, Denorm, or NaN, SPEFSCR[FINV] is set, and the FGH FXH, FG and FX bits are cleared. If floating-point invalid input exceptions are enabled, an interrupt is taken and the condition register is not updated. Otherwise, the comparison proceeds after treating NaNs, Infinities, and Denorms as normalized numbers, using their values of ‘e’ and ‘f’ directly."

0 Kudos