??? 06/04/07 14:51 Read: times |
#140243 - it would require some modifications elsewhere Responding to: ???'s previous message |
Erik Malund said:
My point is that it is impossible to set a breakpoint in any code the optimizer has 'shared' between multiple functions, simply because it will break when either of the functions sharing the code execute it. There is nothing like impossible in engineering - although sometimes we might encounter something impractical or prohibitively expensive. It is relatively easy to decide at the breakpoint, to which branch it belongs, from the history (execution trace - a last-branch register is enough). Of course, if this is an afterthought with an already firmly given fixed hardware (as is the "onchip" debug case), this cannot be accomplished easily - the most likely penalty is a short delay upon each pass through the breakpoint which does not evaluate as the "true break" (provided there is some sort of trace anyway - I don't know the situation with the SiLabs, the Ramtron/exGoal Versa does have a "jump log" set of registers). So, my and Andy's point is, that while the compiler/optimizer is relatively complex and advanced, the debugging itslef is often very rudimentary and does not keep up with the possibilities provided by the compiler. You then choose the compromise in design (avoid using the advanced optimisation options) based on this fact. Again, I know, you speak of experience with available systems... JW |