We are evaluation Keil uVision V4.10 and ARMCC V4.1.0.481.
Our first test run didn't go so well.
With no optimisation, everything worked OK. Using optimisation 1 or above, the test failed.
For various reasons, I can not disclose the test source code. However, I will attempt to create a small self-contained example later on. The part of the test code that caused the problem is setting up an multi dimensional array, setting each element to '1' (ie. Array[x][y] = 1 with a for loop for both x and y).
In the meantime, I wonder if anyone has had a similar problem?
Using optimisation -O3, the assembler code in the debugger looks like this:
48: for ( y= 0 ; y < 8 ; y++ ) 0x80000AAC E5C02000 STRB R2,[R0] 0x80000AB0 E2822001 ADD R2,R2,#0x00000001 0x80000AB4 E3A0C001 MOV R12,#0x00000001 0x80000AB8 E20220FF AND R2,R2,#0x000000FF 0x80000ABC E7C3C001 STRB R12,[R3,R1] 0x80000AC0 E5C02001 STRB R2,[R0,#0x0001] 0x80000AC4 EAFFFFFC B 0x80000ABC -- Isn't this an infinite loop???
I explained what the assembler was supposed to be above. It's basically this:
for (x = 0; x < 100; x ++) for (y = 0; y < 8; y ++) array[x][y] = 1;
At optimisation level 0, the output code is correct and works correctly, giving the correct array output. At optimisation level 1, the output code is incorrect. 'x' never increases past the value of '1'. At optimisation level 3, the output code is incorrect. 'y' never increases past the value of '1'.
We have discussed this in a meeting this afternoon and have decided that we simply can not depend on a compiler which can make the kind of mistake as explained in the assembler code in the first message - the compiler seems to have optimised away the increment of the variable 'y' and 'x'.
We had no problem with the exact same code with a compiler from a different vendor under the same optimisation levels.
Therefore, we have decided to purchase the compiler from the different vendor and end the evaluation of Keil.
Shame really, as the debugger is much better in the Keil product. The other compiler support zero peripheral emulation. (The ideal would be to use the other compiler and use Keil as the debugger, but we don't have the budget to do that).
The assembler looks like it enters an infinite loop, but without seeing some surrounding code I think it is difficult to establish what is really happening.
If you are doing an evaluation of the compiler, I would suggest that you do so with the very latest (ARMCC V4.1.0.567).
For various reasons, I can not disclose the test source code. However, I will attempt to create a small self-contained example later on.
Nothing to discuss so far, then.
Isn't this an infinite loop???
It looks like it. Is this supposed to be a problem? Since there is no complete code posted, there is nothing to discuss here either.
View all questions in Keil forum