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?
Actually i use it. It work fine since several revision... It reduce my code from 66Ko to 60ko on a project, and 55Ko to 45ko for another. The only problem that i have is that i need to locate some specific portion of code at specific address ( to make my E5 write in his Flash... ), so i have to put an option to this specific file to not optimize it ( level 7), and it work fine. Before Keil C51 V7.07a, the code packing process was VERY long, but it's faster for me in this last release. I use RTX51Full and Banking on it and no problem.
I haven't upgraded since v7.01 as all my existing projects are stable with this version using level 9, favour size. I haven't revisited levels 10 or 11.. Stefan
"It reduce my code from 66Ko to 60ko on a project, and 55Ko to 45ko for another." Thanks for that good news! What was the reference point for these reductions? ie what optimisation gave the 66K and 55K sizes? Were the 60K and 45K at level 10 or 11? Thanks again, A.
The reference point are between : - Level 9 under BL51 ( No packing ). AND - Level 11 under LX51. Christophe.
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.
Has anyone tried comparing level 9 and level 11 both using LX51 with code packing and favour size? Every project I've tried it on has got bigger rather than smaller. Stefan
I've just bee trying it:
9,SIZE 10,SIZE 11,SIZE 65094 57930 57930 10,SPEED 11,SPEED 61242 61242
For me:
11,SIZE 11,SPEED 62619 66332 10,SIZE 10,SPEED 62619 66332 9,SIZE PACKING ON 9,SPEED PACKING ON 62772 66518 9,SIZE PACKING OFF 9,SPEED PACKING OFF 65391 67780
It's beginning to look as though level 11 hasn't actually been implemented and level 10 is being used instead. It would be interesting to compare the final binaries. Andy, you seem to have a big drop in code size from 9 to 10, whereas Christophe does not. Did you definitely have code packing on for both tests? Stefan
"Did you definitely have code packing on for both tests?" No, I didn't! I hadn't thought of just turning the Packing ON without also increasing the Optimisation level. So here's the full results:
Packing OFF Linker Code Packing ON ------- --------------------------- 9,SIZE 9,SIZE 10,SIZE 11,SIZE 65094 58074 57930 57930 10,SPEED 11,SPEED 61242 61242
"a small gain in increasing the Optimisation level from 9 to 10" About 0.25%, in fact. Hardly worth it really. Stefan