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