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.
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!