Is there anyone but me that would benifit from a utility to combine C and assembly? I have found that LPP almost never works. According to this tread there are others that have also encountered problems http://www.keil.com/forum/docs/thread729.asp I know it can be done because we use another compiler for the HC16 and it works flawlessly. Here is an example. Note that absolute addresses have even been inserted. My guess is that they are using their equivalent to an OMF file to generate this.
19330 _TPA_allowed: 19331 19333 47692 T 340C pshm y,x 19334 47694 T 274F tsx 19335 47696 T .set OFST=2 19336 19338 ; 2131 BOOLEAN allowed = FALSE; 19339 47696 T 0501 clr OFST-1,x 19340 47698 T ; 2132 19341 ; 2133 if ( TPA_faults == TPA_NO_FAULTS ) 19342 19344 47698 T F50C ldk #.__data__ 19345 4769A T 27FA tbek 19346 4769C T 17F536B2 ldab L34_TPA_faults 19347 476A0 T B600 bne L17101 19348 476A2 T ; 2134 { allowed = TRUE; 19349 19351 476A2 T F501 ldab #1 19352 476A4 T CA01 stab OFST-1,x 19353 476A6 T L17101: ; line 2136, offset 19 19354 ; 2135 } 19355 ; 2136 return(allowed); 19356 19358 476A6 T C501 ldab OFST-1,x 19359 476A8 T 3705 clra 19360 476AA T 19362 476AA T 3518 pulm y,x 19363 476AC T 27F7 rts 19364 476AE T ; 2137 }
Refer to the following knowledgebase article: http://www.keil.com/support/docs/148.htm Jon
As the originator of the thread you cited, I would certainly find a proper Source+Assembler listing useful. The debugger does give a source+assembler listing, but the trouble is that it can't be printed, and you can't go to a specific line and say, "show me the source+assembler" Using the SRC directive has been suggested, but I have heard it said that this disables (most) optimisations - so it wouldn't necessarily be representative. Apparently, the LX51 Linker (for the 8051 tools) can produce a disassembly listing of the absolute object - I haven't tried this yet, so I don't know if it's any good! "Maybe if we cry hard enough Keil will make this a priority" I think we'd have to cry very hard indeed :-( However, I do think that uVision still has a number of deficiencies which still warrant a higher priority than this. I've got a little list...
Using the SRC directive has been suggested, but I have heard it said that this disables (most) optimisations - so it wouldn't necessarily be representative. This was true a long time ago, but using the SRC option generates the same assembly output that the compiler would. All optimizations are used. Jon
... but using the SRC option generates the same assembly output that the compiler would. All optimizations are used. Is this the case for a module that has some "inline" assembly as well? That is, does the compiler now track which registers have been modified in any "inline" segments? And is this performance the case now for C51 as well? Thanks, --Dan Henry
Is this the case for a module that has some "inline" assembly as well? Yep. Jon
This [SRC disables optimisation] was true a long time ago, but using the SRC option generates the same assembly output that the compiler would. All optimizations are used. "A long time ago" in this context seems to be just over 1 year: http://www.keil.com/forum/docs/thread976.asp From what versions of which Compilers (C51, C16x, etc) was this restriction removed?
I use the C166 toolset. Is that feature available with it (or will it be)? Also, I tried using the SRC directive a while ago and did not like it for some reason. I beleive because when I build the target the files that use the SRC directive would be re-built every time regardless of whether the source code was modified or not. -Walt
"files that use the SRC directive would be re-built every time regardless" Yes, they are. You also lose any source-level debug capability with the original 'C' file, identifiers, etc. Another reason to keep your 'C' in .c files for the compiler, and your assembler in .asm files for the assembler!
You also lose any source-level debug capability with the original 'C' file Really! That's worse than rebuilding everytime. I sounds like the .COD file that Jon mentioned provides what I'm asking for but it does not look like it is available for the C166, at least not yet. -Walt
Oops. Somewhere around C51 V3/V4, the SRC directive generated code without some optimizations (level 4 and up, I think). This limitation was removed somewhere around V5. Jon
it'd be useful if this were clearly documented in The Manual
Jon: Any information on whether this will be available for C166 and when? -Walt
It's pretty easy to test the optimization vs SRC directive issue. 1. Open the MEASURE example. 2. Compile and record the total code size. 3. Add #pargma asm \n nop \n #pragma endasm to a function in measure.c. 4. Modify the project so that measure.c is compiled with SRC and the SRC file is assembled and included in the project. The total code size should only change (go up) by 1 byte. This worked for me. Jon
"It's pretty easy to test the optimization vs SRC directive issue." It's one thing to demonstrate one (or even many) particular case (or even many) in which SRC makes no difference; it's quite another to have that behaviour properly defined and documented by the the supplier!
It's one thing to demonstrate one (or even many) particular case (or even many) in which SRC makes no difference; it's quite another to have that behaviour properly defined and documented by the the supplier! Yep. I agree. I was just pointing out that a user can easily test his/her own code to be satisfied that SRC doesn't unoptimize anything. Jon