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.
Level 10: Rearrange Code; Level 11: Reuse of Common Exit Code. Does anyone have any experience of these higher optimisation levels, relying on the LX51 Linker? This thread reported some bugs, and expressed some misgivings about the advantages: http://www.keil.com/forum/docs/thread2094.asp That was v7.02; now we're at v7.07a: Can anyone confirm that the bugs are really fixed now? Does it do any better now? Any other plaudits, Gotchas! or concerns?
I also use optimize-for-size level 11. My results are similar to Mr. Grun's, about a 10% savings on ~60k of code. I have not found any bugs attributable to the optimization. The only down side I've experienced is that this level of optimization wreaks havoc on the ability of a source-level debugger to match any given instruction with a line of source code. Any common code the compiler and linker can seek out is ruthlessly replaced with subroutines, so any given line of C is likely to actually call instructions that come from other lines of C. My source-level debugger will jump all over the place when single-stepping instructions. And all the calls to subroutines without meaningful names makes it a bit harder to debug.
"The only down side I've experienced is that this level of optimization wreaks havoc on the ability of a source-level debugger" 'twas ever thus! :-( It's the old optimisation-vs-debuggability problem again: http://www.keil.com/forum/docs/thread1673.asp Another case of, "you can't have your cake and eat it" :-( Out of interest, which debugger do you use?
We have a pretty big project that must fit into 60K.When we encounter some error in the linking process (before packing), it reports over 80KB of code, and after packing we are under 60KB limit.Otherwise,there are no side-effects (versions 7.03 and above).It does a great job actually saved a project!!! regards Dejan
Yes, i have the same problem, debuggging a packed program make some problem to follow the right progression in the source code... But, to debug on the target the better thing is to disable packing (optimize 9), and after the debug session then just re-enable it, and check that all is good with it ( i never had a surprise... ) Christophe. (For me the debugger is keil debbugger with Triscend TE5UV2.DLL).
Out of interest, which debugger do you use? Seehau (the one that comes with the Nohau ICE). I also got some mileage out of uVision for some of the modules that aren't hardware-specific. Oh, and printf(), of course ;) Unfortunately, I can't turn off optimization for debugging, because the project would cease to fit! It's actually interesting at times single-stepping through the code and seeing what the optimizer chose to do. I learned a few 8051 coding tricks that way.