I am having problems with the Keil LPP Utility (which should interleave the Assembler & 'C' Source in the c51 listing file - see http://www.keil.com/support/docs/975.htm). Sometimes, it just doesn't do the interleaving at all: it leaves the listing file exactly as it started, with the 'C' source listed at the top, and then the Assembler at the end. Has anyone else had similar problems? Better, has anyone solved them!? I thought it might have been to do with the upgrade to C51 v6.14, but it works for the HELLO example project, so it ain't that; I've tried enabling/disabling #include file expansion, but it makes no difference; I've tried changing all the C++ style "//" comments to C style "/* ... */," but that makes no difference.
First, manually remove the assembly comments like this:
;---- Variable 'GrpId' assigned to Register 'R7' ----
By the way, I would like to indent the assembly code, not the C code.
As interleaved assembler must be a very common requirement, I don't see why we should have to manually download and run this dodgy utility. Surely this should be an integrated function within uVision (or C51) - just check the box?! "True Integration!?" - I think not :-(
For true interleaved C/assembly, use the SRC directive. This does a nice job of mixing the C and assembly. The LPP utility program was written by one of our support personnel several years ago for the version 5 compiler and does not appear to always work with the version 6 tools. As for the question, "Why don't we output the .LST file in that way already?", the answer is not simple. First of all, the tools were designed using the Intel A51 and PL/M-51 tools as a starting point. If you want to know why a lot of things on the 8051 are done the way they are, you should take a look at these products. Second, there are a lot of existing programs that DEPEND on the way the tools worked 10 years ago!!! Third, there are existing tools (like emulators) that rely on the format of the listing files and object modules to remain constant. If we were to change the way the tools worked with the random abondon many of our customer suggest, upgrading from V6.12 to V6.14 would require hours of new debugging for EVERYONE and would cause more problems than we could solve in a timely fashion. Providing a quality compiler is not so much a job of what new features you can add and how much you can innovate as much as it is a job of making sure you don't break anything that worked in all the previous releases. Jon
Fair enough, but it shouldn't be hard to add this as a uVision option; then them as wants it can just enable it? Or why not make the disassemby window printable in uVision? From this point of view, I think it'd be better if LPP had separate input & output files - then you could retain the original C51 listing in its established format, and just refer to the "processed" file for interleaved assembler. The trouble with using SRC is that you don't get an object file! Ho-hum, perhaps I'll just have to back to my own dodgy old Word macro!
Maybe you should add some info like this into the Release Notes which "ship" with LPP?
Makes no difference :-(
Can you post a listing that fails?
I can give the LPP source to anyone who wants to make it work. Only one condition...I want the corrected source so I can post a new working version for everyone. :-) Jon
Unfortunately not - Client confidentiality precludes it.
OK. Standard rates apply!
I have found the answer: Use the 'NOCOND' option; ie, don't show code "disabled" by #ifs in the listing! (my "problem" files had lots of conditional-compilation)
Even with NOCOND, it only half-works on my files -- seems to stop merging after the first 2 or 3 functions. (V7.00 C51 compiler) How about adding a SRC-like option that ALSO produces object code? The LPP read-me and knowledgebase article should be updated to say that it may not work! (And mention the SRC option.)