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