We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
I have a segment of codes as follows. 'app' is a structure variable.
The code can successfully pass the compiling process and run but contains some inexecutable important commands, which can't be recognized by compiler, e.g.app.bT = TRUE. Besides, there are some disordered jump inside the switch, e.g. jumping from case 1 to case 5 without executing "break" in case 1.
app.bT=FALSE;
do {
switch ( ix )
{
case 0: if ( app.f0< app.fB1 ) app.bT = TRUE; break;
case 1: if (( app.fB1 <= app.f0 )&&( app.f0<= app.fB2 ) ) {if ( app.fC1 > ( ( app.fM1 * app.f0 ) +( app.f_Allowed - app.fM1* app.fB2 ) ) ) app.bT= TRUE; } break;
case 2: if ( app.f0>app.f_Allowed) app.bT = TRUE;
break;
case 3: if (( app.f0 <= app.fB4 ) ) { if ( app.fT > ( ( app.fM2 * app.f0 ) +( app.f_Allowed -app.fM2*app.fB3 ) ) ) app.bT = TRUE; } break;
case 4: if ( app.f0> app.fB4 ) app.bT = TRUE; break; default: break;
}
ix++;
while ( ix < 5 && app.bT == FALSE );
I think it's the internal error of C51 since there are few other explanation for this strange problem but I still don't want to believe that's true. Would you please give me an answer? Thank you for your help.
Can you demostrate an actual error in the generated code? That is, post the source, and the generated assembler code, and point out where the result of executing the code is incorrect?
Source level debuggers are often confused by highly optimizing compilers and may show you what appears to be strange execution as they hop from statement to statement. That does not mean the code is not producing the correct result.
For example (and a completely invented one), the posted code has the statement "app.bT = TRUE" in many cases; the compiler might well choose to promote that statement into a more general block where it is always executed before entering some of the cases. So, if you put a breakpoint inside the case, you might not never see app.bT being set, as that happens before the breakpoint.
If you can produce an example of the optimizer breaking things, then I'm sure Keil would appreciate it if you would email the example to support.
"For example (and a completely invented one), the posted code has the statement "app.bT = TRUE" in many cases; the compiler might well choose to promote that statement into a more general block where it is always executed before entering some of the cases."
To make that concrete, say the original code looked something like this:
switch( fred ) { case 1: joe = TRUE; break; case 2: joe = TRUE; break; case 3: joe = FALSE; break; case 4: joe = TRUE; break; case 5: joe = TRUE; break; default: joe = TRUE; break; }
That could clearly be optimised to, in effect:
joe = TRUE; switch( fred ) { case 3: joe = FALSE; break; }
Where cases 1, 2, 4, and 5 are, apparently, never executed!
Yes, you are right. I am sorry about that because I am a fresh Keiler at this point. And I just told every one what I saw.
Now with your advice I can understand that if you want to trace the execution step by step and in a normal order, you will have to reduce the code optimization level. But the results would be the same no matter which level you choose. Compiler just reorder the execution to get optimized.
"I am a fresh Keiler"
Do understand that this is nothing specifically to do with Keil - all modern compilers perform such optimisations.
The difficulty of debugging such highly-optimised code is the price you pay - as ever, it is a tradeoff, and only you can judge whether it's worth it in your particular case
The specific optimisations performed by the Keil C51 compilers are outlined here: http://www.keil.com/support/man/docs/c51/c51_optimize.htm