• State Not Answered
  • Locked Locked
  • Replies 4 replies
  • Subscribers 22 subscribers
  • Views 898 views
  • Users 0 members are here
Options
Related
How was your experience today?
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

if (0) condition, but entered.

Leong Teck Tey

Hi,

I am using GNU compiler in uVision 3.51. A portion of code is simliar to below:

X = 100; Y = 100; If(x!=y){ Xxxx; }else{ Yyyy; }

By using break point, i found that both Xxxx and Yyyy are entered. It happened in both subroutine, and main. Both X and Y are declared as unsigned integer as global variables. The entire code is less than 16K (about 70% of 16K). Do you have any idea on this? The IC used is LPC2129. Thanks for your advice.

Regards,

  • 0

    X = 100; Y = 100; If(x!=y){ Xxxx; }else{ Yyyy; }

    I assume you wanted to type

    x = 100;
y = 100;
if(x!=y)
   { Xxxx; }
else
   { Yyyy; }

    The best practice to post code is to cut and paste it. Re-typing it always carries the danger of introducing typos, thereby obscuring the actual problem and leading the readers on a wild goose chase.

    But now, back to the original question.

    What optimization level are you using ? Higher optimization levels are usually not very conducive for debugging. Set the optimization level to the lowest possible and try again.

  • 0

    Most likely what happens is this: in the ARM instruction set, almost all instructions can be conditional, i.e. when they are executed their effect depends on the condition code flags in the current program status register. The compiler takes advantage of this when generating code for simple if statements: both branches are executed by the CPU, but only one of them has effect.
    As Christoph mentioned, you should not see this at lower optimization levels.

    Regards,
    - mike

  • 0 in reply to Mik Kleshov

    Hi,

    Yes, the problem was solved by choosing "No Optimization" in Compiler option.

    As mentioned by Mike, when some optimization level was chosen, both branches are entered by "break point", but only the one fulfilling the true condition is excuted. I've verified that too. So it looked like the debugger is causing such trouble.

    Thanks for Christoph and Mike.

    Regards,
    Tey

  • 0 in reply to Leong Teck Tey

    "both branches are entered by 'break point', but only the one fulfilling the true condition is excuted"

    In other words, the code is actually operating correctly?

    "So it looked like the debugger is causing such trouble."

    No: it sounds like it's your interpretation of what the debugger is doing (especially with conditional instructions) that's faulty, not the actual debugger?