> 3) Look at possible root causes.
Like? So far, they best I could find is to print out the code and follow it carefully.
> The most common problem with optimized code is assumptions about > variables. Variables may be allocated to registers now rather than the > stack.
Whose assumptions? The compiler's or mine? I personnaly don't care where they're keypt. But can the CW debugger display the contents of variables if they get stored in registers? Would this be the reason of nonsense variables contents in the monitor window?
These are your assumptions -- you may not be making them, but they're in the code. Here's an example:
You've got these variables
char str[20];
int i, myScore;In non-optimized code (what I called debug mode), writing to str[21] would modify the first byte of "i", which could be harmless since you're not in a loop at the time and i will be rewritten. In optimized code, i gets moved to a register, so now you modify myScore, a variable with a longer lifetime.
Try running at opt level 2 -- that's a good halfway point where register allocation happens and you've got some IR-level optimizations occuring, but the really heavyweight opts aren't being done.
The CW debugger can't really show many variables in optimized code. This is because the optimizer adds and removes variables as part of its transformations. For example, if you wrote:
int i = 45;
foo(i);
i = 23;
foo(i);
i = 17 + g;
i = 16;
foo(i);You've got one variable named "i", but the optimizer sees "i" as 4 different variables, since the reassignment of i effectively creates a new variable lifetime. The optimizer would turn this into
int i = 45;
foo(i);
int i1 = 23;
foo(i);
int i2 = 17 + g;
int i3 = 16;
foo(i);It would then remove i2, and its value isn't used, unless g was a volatile variable and the read from it would need to be preserved. Then, during constant value propagation, it would turn this code into
foo(45);
foo(23);
foo(16);and now you don't have any variables left in the code that map to "i".
Of course, this example isn't totally realistic -- most people wouldn't write code that looks like this, but it can easily occur with other compiler transformations or inlined code.
--
Ben Combee <[EMAIL PROTECTED]>
CodeWarrior for Palm OS technical lead
Palm OS programming help @ www.palmoswerks.com
-- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
