we have analysed the described issue and found that it is not a bug. The results of the calculation are correct. Following are the results of the analysis:
(1) var uint8 temp = 0;
(2) temp = (temp - 1)%4;
(3) trace "temp =", temp;
a. The expression in row (2) consists of two parts. First the subtraction temp - 1 is evaluated.
b. The operand temp is 0. The result of the operation is thus -1.
c. Similarly to C, arithmetic expressions are automatically promoted to signed integer. The data type of the expression is consequently int32.
d. Then the modulo operation is calculated with -1 as result of the left operand: -1 % 4. This results in -1. Since the left operand was negative, the result is negative too.
e. Again, the data type of the entire resulting expression is promoted to int32.
f. During the assignment to temp in row (2), the int32 value is implicitly casted to uint8 value. Embedded Wizard reports here a warning:
g. The int32 value -1 is represented internally as 0xFFFFFFFF. The cast to uint8 extracts the lower 8-bit. The resulting value is 0x000000FF.
h. The variable contains the value 255.
We compared the behaviour in a simple C example with following code and results. The C compiler produces the same results as Embedded Wizard:
What can you do?
The result of the left operand in the modulo operation has to be unsigned integer. An additional typecast is needed. It converts the negative -1 value to uint8 value 255. Then the modulo operation produces the expected results:
var uint8 temp = 0;
temp = uint8( temp - 1 ) % 4;
trace "temp =", temp;
I hope it helps you further.