This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Inexecutable statements inside switch case

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.

Parents
  • "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!

Reply
  • "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!

Children
  • 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