There have been a lot of threads dealing with viewing the code from the LX linker (COD file) and comparing it to the compiler output (LST). All of which creates a major dilemma in debugging programs. To me, the compiler output should always be in a final form. It is Ok to change long jumps to short ... it is NOT Ok to rearrange and generate new code. I use the compiler output to validate code generation and to determine the best way to improve a specific function or sequence. When the linker generates new code this process is essentially useless. Following the linker output is like handling spagetti. I just spent two days tracking an LX bug ... it was anything but obvious. I, for one, would like to formally request that Keil put the optimizations in the compiler and to scratch doing it in the linker. We all know that more efficient compilers are a good thing ... we also know that we need to complete our projects. Keil needs to remember that it's products are tools to help us write and debug code. The more straight forward the output, the easier it is to understand. What are your thoughts? P.S. An alternative is to have the linker produce COD files for each module and to scrap the assembly option in LST files. If this alternative is selected, the COD files will need some sort of documentation ("C" source) to permit the user to follow the logic. A single project wide COD file with shuffled functions is not acceptable.
"What are your thoughts?" I disagree totally! Everything in engineering involves tradeoffs; in software, there is very often a tradeoff between having "nice" clean, elegant, easy-to-read, easy-to-debug source code and squeezing out every last drop of performance, or cramming the maximum functionality into the minimum memory footprint. "it is NOT Ok to rearrange and generate new code" If optimisation is your overriding concern, then you will want to take advantage of every possible trick in the book. "I, for one, would like to formally request that Keil put the optimizations in the compiler and to scratch doing it in the linker." All the optimisations are optional - just don't enable them if you don't want them! "Keil needs to remember that it's [sic] products are tools to help us write and debug code." The important word there is us - they're not just there to meet your specific set of goals & criteria; for some users, it is important to get the absolute maximum optimisation, and they are prepared to trade this off against the resulting impacts on debugging etc that you have mentioned. Again; it's all optional - so if you don't need it, don't enable the option! "put the optimizations in the compiler and to scratch doing it in the linker" The thing is, the compiler only ever sees one module in isolation; only the Linker sees the "Big Picture" of the entire application as a whole. Therefore there's a whole set of optimisations which simply cannot be done by the compiler alone. eg the global register optimisation supported by the BL51 linker, which does give a major reduction in code size. "...have the linker produce COD files for each module" Again, this precludes any inter-module and application-wide "global" optimisations
Bob, I also use the LX51 linker and would be very grateful if you could post details of the bug you found along with the LX51 version number. Regarding your comments: From what I recollect from using C51 with BL51 at optimisation level 9 (favour code size) the assembler listing in the .lst file was as difficult to follow (due to code rearrangement) as that in the .cod file but without the advantage of the interleaved C source. I have noticed on occasion that the interleaving isn't quite right but in general I find the .cod an improvement on what we had before. I must point out, though, that I have only used LX51 with single source file projects. This is only speculation, but I wonder whether the jump optimisation is really the final step? Perhaps LX51 does some additional optimisation afterwards, or perhaps the jump optimisation happens in two (or more) stages? This might preclude doing some other optimisations in the compiler. I used to look at the compiler output fairly frequently to see how I could improve the source to 'help' the compiler produce the smallest code, however with the current standard of the compiler/linker optimisations I sometimes find that the smallest change to the source can cause an unexpected increase in code size as my 'improvement' defeats the common block optimisation. By the way, I've found that optimisation level 9 gives the smallest code in all projects I've used LX51 with so far - levels 10 and 11 actually increase it a bit, perhaps by 0.5%.
Wow ... did I open pandoras box. Keep the comments coming. They are great and good for everyone. Thanks
To Keil developers and Andrew ... my apologies for ranting in this forum. I have been a long time supporter of Keil products and will continue to be. Andrew, I frequently am running out of space and always (well nearly always) welcome improvements in code generation. As an old time assembly language programmer I regularly used lots of tricks to generate tighter code. With "C" getting so good ... it is very rare that I resort to assembly any more. It is just too difficult to maintain on projects whose life cycles reach the decade mark and exceed my ability to remember all the nuances that were introduced for the sake of size. I frequently have 20-30 source modules where each relates to a specific portion of the job being done. It helps me keep the interactions between modules to a managable level. While I can't disagree that only the linker has the global "view" of the total program, I do think a better job can be done to find a way of presenting the linker code (and to document it) rather than one cumbersome file.
"my apologies for ranting in this forum" You can't beat a good rant! "With "C" getting so good..." Unfortunately for the debugger, this is frequently at the expense of any straightforward link between source & object! "I do think a better job can be done to find a way of presenting the linker code (and to document it)" I agree - as all these optimisations take the object further & further away from its source, it would be useful if the tools could document what they've done!
Bob, Any chance you could post that LX51 bug? Thanks, Dafydd