We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Inline assembly! asm { ;you assembly code goes here. } My version is so out of date, tho, it may already support it and I don't even know.
The REAL method, not the .SRC workaround, where is it documented?, my manual document the .SRC.
Not sure what you're getting at there, Erik? Keil, in common with some other compiler writers, have chosen to implement inline assembler via .SRC and the Assembler. But isn't it fun, anyway!?
I guess the REAL questions is "How does the Keil C51 compiler generate an OBJ file?". Many C compilers generate assembler output that must then be assembled with an assembler. This is a 2-step process that requires running the C compiler and then the assembler. Many C compilers make this transparent and run the assembler for you (without you knowing it). The KEIL C compiler generates the .OBJ file without calling or running the assembler. Therefore, when you include in-line assembly statements, we chose to simply generate a .SRC file and let you assemble it. The rationale behind that is that if you are generating assembler code from the compiler, you are probably going to want to hand tweak it somewhat. Jon
>The KEIL C compiler generates the .OBJ >file without calling or running the assembler. >Therefore, when you include in-line assembly statements, >we chose to simply generate a .SRC file and let you assemble it. >The rationale behind that is that if you are generating >assembler code from the compiler, you are probably going >to want to hand tweak it somewhat. Can you say that this 2 ways always produce the same .OBJ: 1) .C --> .OBJ 2) .C --> .SRC --> .OBJ in case of no using any #pragma asm/endasm ?
Can you say that this 2 ways always produce the same .OBJ: 1) .C --> .OBJ 2) .C --> .SRC --> .OBJ in case of no using any #pragma asm/endasm ? Method (2) means that you have to call both C51.exe and A51.exe separately, so you'd have to ensure that all your command-line options matched precisely Also, I'm not sure whether C51 disables all optimisation when generating .SRC? (this could make sense, given Jon's earlier comments about "tweakability")
Can you say that this 2 ways always produce the same .OBJ: 1) .C --> .OBJ 2) .C --> .SRC --> .OBJ in case of no using any #pragma asm/endasm ?
Can you say that this 2 ways always produce the same .OBJ: 1) .C --> .OBJ 2) .C --> .SRC --> .OBJ in case of no using any #pragma asm/endasm ? 1 != 2. There are several reasons why. 1. When you compile a C file and generate an OBJ file, the compiler injects debug information into the OBJ file. Things like line number-address offsets are included. When you compile a file with SRC and then assemble the SRC file, the object file has debug information from the assembler, and the line numbers refer to the SRC file (not the C file). 2. When you compile a C file and generate an OBJ file, the C compiler includes references to the standard C library files (C51S, C51C, or C51L). When you create a SRC file, these references are not included. So, if you have a 1-file project that is compiled as a SRC file, you'll have to include the C libraries manually. 3. When you create a SRC file, most optimizations are disabled to about side-effects that interfere with your in-line assembly. Additionally, the compiler attempts to color registers and doesn't "know" about the in-line code that you enter. That text is passed verbatim to the SRC file for assembly by the assembler. Ergo, the compiler can't make rational decisions about the in-line code you have. Jon