Hi all, I am using the microvision 2 and the controller is c8051f12x. I faced a strange problem with keil. Have a look at the following sample code.
void main() { f1(); f2(); f3(); } void f1() { // some code } void f2() { // some code } void f3() { // some code }
What optimisation level are you using? Optimisations such as common-entry merging and common-tail merging could produce the effects that you describe...
Thank you Neil, Optimisation level is 8(Reuse Common Entry Code) and Emphasis is 'Favor Speed'. Anyway, the optimisation never takes the control in a meaningless path. Say, if I am calling a function twice in the main(), it will always stick to anyone of the call. But here, I am facing a meaningless way of flow of control. can you say why it is so? - Neo
"the optimisation never takes the control in a meaningless path." That's true but, at high optimisation levels like this, the actual code execution path can bear very little resemblance to the path in the source code! Are you sure that the code is actually executing incorrectly? It could be just the debugger that's getting confused... The first thing to do is to verify that the actual behaviour is correct in terms of external inputs & outputs, rather than the specific order of execution of source statements. Try running it at minimum optimisation to verify that the logic of your code is correct.
at high optimisation levels like this, the actual code execution path can bear very little resemblance to the path in the source code! I agree with this and I have also seen this. But Keil ensures that the optimisation of code never collapse the flow of control. When I started working with keil, first I was confused with the flow of control when using the high optimisation level. Then I worked with various optimisation level and understood the behaviour of keil. But it does not semms to be a prob with optimisation levels. But anyway thankyou and I'll test it with lower optimisation levels. Are you sure that the code is actually executing incorrectly? It could be just the debugger that's getting confused... yes I am sure. the code is running incorrectly. I verified this problem with debugging using EC2 and putting some test messages and viewing it thro hyper terminal.
"I'll test it with lower optimisation levels." If it works on lower optimisations, you have one of two problems: (1). Your code relies upon something that it shouldn't, but that happens not to matter at low optimisation (ie, your code works by luck); (2). You have found a situation that confuses the optimiser. If you suspect (2), you should start by examining the compiler's generated assembler and the disassembly generated by the Linker in its .COD file.