Comparison in CLA

Joost de Bruin

Part Number: TMS320F28069F
Other Parts Discussed in Thread: TEST2

Tool/software: Code Composer Studio

I found something really weird with comparisons in the CLA co-processor (I am aware of compiler bug when the difference of the operands would overflow, which I believe is not the case here). I have done some tests, outcomes are in the comment (CurrentLimit = -1, DACOffset[1][Phase] = 501):

        int16 test1 = 1>-501?1:-501;                                                                // 1
        int16 test2 = -1>-501?-1:-501;                                                              // -1
        int16 test3 = -CurrentLimit>-DACOffset[1][Phase]?-CurrentLimit:-DACOffset[1][Phase];        // -501
        int16 test4 = -CurrentLimit>-DACOffset[1][Phase];                                           // 0
        int16 test5 = (-CurrentLimit)>(-DACOffset[1][Phase])?-CurrentLimit:-DACOffset[1][Phase];    // -501
        int16 test6 = (-CurrentLimit>-DACOffset[1][Phase])?-CurrentLimit:-DACOffset[1][Phase];      // -501
        int16 test7 = -1;
        int16 test8 = 501;
        int16 test9 = (-test7)>-test8?(-test7):-test8;                                                  // -501
        int16 test10 = -test7;                                                                      // 1
        int16 test11 = test10>-test8?test10:-test8;                                                 // 1

The main CPU, and the 'Expressions' window, do arrive at the correct value, it goes wrong in the CLA. Any ideas?

over 5 years ago

0 Santosh Jha over 5 years ago

TI__Guru 50611 points

Joost,

Thank for reaching us. The subject matter experts are out of office due to US holidays and time-bank. Please expect response by Jan 5th or 6th. Sincere apology for delay in response.

0 Lori Heustess over 4 years ago in reply to Santosh Jha

TI__Guru* 92790 points

Joost,

Happy New Year. Thank you for your patience over the holidays. I wanted to see if you are still encountering this issue? If yes, please let me know how the variables are defined (CurrentLimit and DACOffset) and which version of the compiler you are using.

Best Regards

Lori

0 Joost de Bruin over 4 years ago in reply to Lori Heustess

Prodigy 200 points

Hello Lori,

You too have a good year. I worked around it, and that actually resulted in more efficient code. But to avoid this bug in the future, and curiosity, I would like to see it resolved. It actually also happens for locally defined variables:

int16 test7 = -1;
int16 test8 = 501;
int16 test9 = (-test7)>-test8?(-test7):-test8;                                                  // -501

Maybe my brain is short-circuiting, but in my belief -(-1) = 1 > -(501) = -501, so it should evaluate to 1 instead of -501

The variables are defined as follows:

#pragma DATA_SECTION(DACOffset, "CpuToCla1MsgRAM");
int16 DACOffset[2][3] = {{0, 0, 0}, {0, 0, 0}};

#pragma DATA_SECTION(CurrentLimit, "CpuToCla1MsgRAM");
volatile long CurrentLimit = 0;

The version of the compiler is: TI v20.2.0.LTS

0 Lori Heustess over 4 years ago in reply to Joost de Bruin

TI__Guru* 92790 points

Joost,

Thank you for the additional information. In this case the inputs of the comparison will fit into a "short". If you tell the compiler this, then the warning will go away and the compiler will use slightly different instructions to determine the result. (refer to: http://software-dl.ti.com/ccs/esd/documents/cgt-cl2000-v18.12.x_cla-signed-integer-comparison-workaround.html )

I tried this with your code:

int16_t CLAtest10 = (short)(-CLAtest7) > (short)(-CLAtest8) ? (-CLAtest7) : (-CLAtest8);

-Lori

0 Joost de Bruin over 4 years ago in reply to Lori Heustess

Prodigy 200 points

Thank you. This indeed arrives at the correct result. I found the link you mentioned, but I was not aware that results are also affected if the operands are not in the problematic range (i.e. the difference does not overflow). As an extra check I also used the 'safe' comparison operator, this also gave an incorrect result. Code:

    int16_t CLAtest7 = -1;
    int16_t CLAtest8 = 501;
    int16_t CLAtest10 = (short)(-CLAtest7) > (short)(-CLAtest8) ? (-CLAtest7) : (-CLAtest8);    // 1, correct
    int16_t CLAtest11 = (-CLAtest7) > (-CLAtest8) ? (-CLAtest7) : (-CLAtest8);                  // -501, incorrect
    int16_t CLAtest12 = __mgt((-CLAtest7), (-CLAtest8)) ? (-CLAtest7) : (-CLAtest8);            // -501, incorrect

Alas, I still do not know the exact why and when it happens, but I will just take extra care I guess

0 Lori Heustess over 4 years ago in reply to Joost de Bruin

TI__Guru* 92790 points

Joost,

I've been discussing this with the compiler experts and it looks like the __mgt( ) not working may be a bug. It is being tracked by ticket CODEGEN-8490 if you want/need to reference it in a future post.

I asked about the original values fitting into a short, and being defined as int16_t, yet causing this issue. It is because a -short is an int in C. The compiler is doing the right thing by providing the warning, thankfully.

Best Regards

Lori

0 Joost de Bruin over 4 years ago in reply to Lori Heustess

Prodigy 200 points

Hello Lori,

Thanks again. I will be double checking when this warning pops up.

Kind regards,

Joost

C2000™︎ microcontrollers

C2000 microcontrollers forum

Comparison in CLA