| View previous topic :: View next topic |
| Author |
Message |
notbad
Joined: 10 Jan 2013
Posts: 68
|
| ASM codes appear before C statements in .lst file. |
 Posted: Fri Apr 19, 2013 2:22 pm |
 |
|
"Sometimes" ASM codes appear before C statements in the .lst file in (V4.130).
I saw this problem when I compiled my bigger code.
Then I had a hard time trying to Reproduce it on a short code for posting here. Finally I succeeded!
What's wrong? Is it OK?
| Code: | #include <16F873A.h>
#FUSES NOWDT //No Watch Dog Timer
#FUSES HS //High speed Osc (> 4mhz for PCM/PCH) (>10mhz for PCD)
#FUSES NOPUT //No Power Up Timer
#FUSES NOPROTECT //Code not protected from reading
#FUSES NODEBUG //No Debug mode for ICD
#FUSES NOBROWNOUT //No brownout reset
#FUSES NOLVP //No low voltage prgming, B3(PIC16) or B5(PIC18) used for I/O
#FUSES NOCPD //No EE protection
#FUSES NOWRT //Program memory not write protected
#use delay(clock=20000000)
#use rs232(baud=9600, UART1)
#byte CCP1CON =0x17
#byte T2CON =0x12
#byte PR2 =0x92
#byte CCPR1L =0x15
#byte CCP2CON = getenv("SFR:CCP2CON") |
| Code: |
#include "ccp.h"
void main()
{
set_tris_c(0xf0);
printf ("start:\r\n");
if (!input(pin_c7))
{
output_low(pin_b0);
}
output_high(pin_b0);
printf ("\r\n%X%X%X%X\r\n" ,PR2,T2CON,CCP1CON,CCPR1L);
while(true);
}
|
| Code: |
.................... {
008E: MOVLW F0
008F: MOVWF TRISC
0090: BCF STATUS.RP0
0091: MOVWF @TRIS_C
.................... set_tris_c(0xf0);
0092: MOVLW 04
0093: BSF STATUS.RP1
0094: MOVWF EEADR
0095: MOVLW 00
0096: MOVWF EEADRH
0097: BCF STATUS.RP1
0098: GOTO @PSTRINGC7_9600_62_63
.................... printf ("start:\r\n");
0099: BSF @TRIS_C.7
009A: MOVF @TRIS_C,W
009B: BSF STATUS.RP0
009C: MOVWF TRISC
009D: BCF STATUS.RP0
009E: BTFSC PORTC.RC7
009F: GOTO 0A4
.................... if (!input(pin_c7))
.................... {
00A0: BSF STATUS.RP0
00A1: BCF TRISB.TRISB0
00A2: BCF STATUS.RP0
00A3: BCF PORTB.RB0
.................... output_low(pin_b0);
.................... }
00A4: BSF STATUS.RP0
00A5: BCF TRISB.TRISB0
00A6: BCF STATUS.RP0
00A7: BSF PORTB.RB0
.................... output_high(pin_b0); |
|
|
 |
Ttelmah
Joined: 11 Mar 2010
Posts: 19451
|
|
| Posted: Sat Apr 20, 2013 2:26 am |
|
|
The C lines are only put in at all as a 'this is roughly the code for this' aid. In many cases parts of the code will be many lines away. Why the assembler sometimes gets in front, is indeterminate, but it makes no difference to the result.
It depends on compiler version, and optimisation level.
Your example doesn't locate like this on earlier of later versions. However the code generated is the same, so it isn't a problem.
Best Wishes |
|
|
notbad
Joined: 10 Jan 2013
Posts: 68
|
|
| Posted: Sat Apr 20, 2013 10:48 am |
|
|
Thank you
I did a little more tests and as it seems, This happens when the last directive in the .h file ends with a parentheses and there is no "carriage return-line feed" at the end. At least that's so in my case. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19451
|
|
| Posted: Sun Apr 21, 2013 1:47 am |
|
|
I'd guess it counts 'lines', by counting the line feeds, and if you have a line at the end of the include that doesn't have a line feed, it gets one line out on it's 'count' of which line in the source file, corresponds to the code block.
Best Wishes |
|
|
ckielstra
Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands
|
|
| Posted: Sun Apr 21, 2013 4:20 am |
|
|
Now you have found the reason why, it is easy to create a workaround. Either way, it is good practice to terminate the last line in your files with a newline.
Somehow I configured my MPLAB to always ensure that the header file ends with an empty line. If the last line is not terminated with an CR/LF, than this is added by MPLAB on saving.
Note that many other compilers like Visual Studio and GCC generate a warning when the last line of a header file contains code because it is a known issue to generate problems down the line of compiler tools. |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
