CW10.6.4 DSC compiler issue with saturation?

[guenter_loettrich]

Hello,

customer reported a potential issue with the DSC compiler in CW10.6.4:

The problem is that the bit complement of 0x80000000 results in 0x7FFFFFFE on 56F84xxx processors, when saturation is active.

All other values are calculated correctly. For 8 bit and 16 bit values, the processor has dedicated instructions to do respective bit complements, all work OK with active saturation.

For 32 bit values, there isn’t such an instruction, the compiler generates the code according to the formula below:

                                                -x = ~x + 1 => ~x = -x -1

The notation is as follows:

-x denotes the two’s complement of value x

~x denotes the bit complement of value x.

Now, the two’s complement of 0x80000000 is actually on 33 bits representable, like 0x080000000; the ALU sees the overflow and saturates at 0x7FFFFFFF.

If we extract 1 in second step, we get the result 0x7FFFFFFE.

This was surprising and not expected, even if the saturation was active.

More information about the compiler version and a test routine:

typedef long frac32_t;

frac32_t x_invert(frac32_t in)

{

   return(~in);

}

volatile frac32_t xx_inv;

void APP_Task10ms(void)

{

   xx_inv=x_invert(0x80000000);

}

Result:

Could you please investigate on that?

thanks in advance

br

Guenter

[guenter_loettrich]

Hi Jennie,

any progress with that topic? Customer is asking if we are able to reproduce the behavior.

br

Guenter

[ZhangJennie]

Hi Guenter,

I reproduced the issue from my side. I wonder this is a toolchain problem, I need check it with development team.

This issue is logged as CWM-225. I will let you know as soon as I get any update there.

Thanks.

Best Regards,

Jennie Zhang

[ZhangJennie]

Hi Guenter

Can you please create a demo project ( made under CW IDE ) to show the problem?

please also mention:

- what result do you expect?

- what's the actual result?

Have a great day,
Jennie Zhang

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[guenter_loettrich]

Hi Jennie,

please find attached a simple project for CW10.7 using MC56F8257 target to verify the behavior.

You can run it either on hardware or in the simulator (like done here).

Please set a breakpoint at return(0); at the end of main and run trough the code until the bkpt is hit.

There is an output array with 12 entries. The first 6 are calculated in non-saturated mode the other 6 with identical input data are calculated with saturation mode enabled.

Of interest are the output values for input "0x80000000”

1. for saturation mode disabled

xx_output[5] contains the correct bitwise complement of 0x80000000 which results in 0x7fffffff

2. whereas for saturation mode enabled

xx_output[11] contains the wrong bitwise complement of 0x80000000 which results in 0x7ffffffe

The question is: Is that an expected behavior ?

br

Guenter