This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMS320F28377D-EP: Is comparing 32-bit Floating-Point Compare for Equal safe?

Part Number: TMS320F28377D-EP

Hello,

I have been experimenting comparing two float numbers for equality.

I have been taught for years that this is not a safe operation to perform because of the float accuracy.

But it seems that the compiler has no issue doing it (not even a warning) and when I check the assembly code I see this kind of instructions:

Is there any issue doing this? Could we be expecting any wrong behavior in some cases? Should it be avoided?

What best practice should you recommend?

Thank you

Best regards,

Laurent.

  • Hello Laurent,

    Is there any issue doing this? Could we be expecting any wrong behavior in some cases? Should it be avoided?

    What best practice should you recommend?

     I believe what you understand about float accuracy is true, from my understanding this sort of instruction is best used for less than or greater than comparisons (there might be a rare use case for equal to comparisons).

    The better approach might be to subtract two floating point numbers, take the absolute value of the result, and use this instruction to compare it to some known offset.

  • That's right, and this why we explicitly put a rule in our coding standard to avoid this practice.

    I am asking, because, while coding for the CLA, I am getting the following warning:

    #30013-D Comparison operation uses integer comparison instruction, which does not operate properly for values that would overflow subtraction. Use --cla_signed_compare_workaround=on to have the compiler work around this issue.

    I have been reading the workaround and I see that a float equality is performed which won't work for us:

    Therefore, we need to avoid turning on this compiler option and instead use another proposed workaround like using a signed integers (short16): 

    But so far, I keep getting the same error with this simple piece of code with all variables declared as short.

    What am I doing wrong? Is there something I don't understand?

    Laurent

  • Hi Laurent,

    Can you send me a snippet of code that I can use to reproduce the warning on my side? It might be quicker than doing too much back-and-forth.

  • Is it what you need (picture attached)?

    I noticed that this does not happen when Optimization level is turn off.

  • Hi Laurent,

    Is it what you need (picture attached)?

    I meant code which I could copy and paste into an example project, although this looks to be CLA-related. Have you verified this warning occurs on the C28 core (in your main.c file)?

    I noticed that this does not happen when Optimization level is turn off.

    When you run the debug session, do you see any differences in the assembly while looking at the Disassembly window?