From: Vangelis R. <vr...@ot...> - 2003-06-06 21:12:42
|
Hi, I have a question about an apparent bug. I try to compile the following source with SDCC: sdcc -v gives: SDCC : pic14/pic16* 2.3.5 (Jun 5 2003) (UNIX) --- m2.c c source --- 1 2 #include "18f442.h" 3 4 char at 0x300001 config1=0x11; 5 6 static int beta=0xa0, delta=0x0f1b; 7 8 //char *name="This is a string"; 9 10 int main(void) 11 { 12 char alfa, gamma; 13 14 #if 0 15 alfa = PORTB; 16 #else 17 alfa = PORTB + 0xa0; 18 #endif 19 20 if(alfa && 0x80 == 0x80) { 21 beta = ~ delta; 22 } else { 23 beta = delta; 24 } 25 26 gamma = beta+2; 27 PORTC = gamma; 28 PORTD = gamma; 29 return 0; 30 } 31 ----- end of code ---- Obviously the file above does nothing useful, except than not compiling at all! SDCC output is: ----------------------------------------- ../sdcc --verbose --dumpall --no-peep -mpic16 -p18f442 m2.c -o 18 sdcc: Calling preprocessor... sdcc: Generating code... *** Saved 1 registers *** No registers saved on this pass *** Saved 1 registers *** No registers saved on this pass sdcc: Calling assembler... 18.asm:360:Error [116] Value of symbol "_PORTB" differs on second pass pass 1=3969 0xf81, pass 2=261 0x105 --------------------------------------- What happens here is that although symbol _PORTB is defined to be a register at address 0xf81 (output from gpasm is hacked to show the hex value of symbol too), during code generation it seems that it is allocated as being at 0x105. What follows is an extract from the corresponding 18.asm (the SDCC asm file) ---------------------------------------- cblock 0X0100 ; Bank 2 r0x20 _beta _beta_1 _delta _delta_1 _PORTB endc cblock 0X0F82 ; Access Bank _PORTC _PORTD endc ---------------------------------------- as you can see _PORTB is (re)allocated as a general purpose register. The problem seems to be generated by the line 17 in the source, where PORTB is used as an operand to the addition command. If I set the conditional to 1 and compile line 15 instead, no error is generated and the source is compiled correctly. Below is an extract of the output from the .p file (which contains pCode generated data): ----- 18.p ------ 1 pcode dump 2 3 4 New pBlock 5 6 internal pblock, dbName =M 7 ;; Starting pCode block 8 ;;ic g 0x167 9 ;; *** genLabel 3104 10 ;;ic 0x9 11 ;; *** genFunction 2691 curr label offset=0previous max_key=0 12 ;; ----------------------------------------- 13 ;; function main 14 ;; ----------------------------------------- 15 ;_main: 16 _main ;Function start 17 ; 2 exit points 18 ;;ic + 0x2b 19 ;; *** pic16_genPlus 789 20 ;; 752 21 ;; 780 - true symop 22 ;; *** aopForSym 446 23 ;; 534 sym->rname = _PORTB, size = 1 24 ;; 752 25 ;; 752 26 ;; *** 795: symbol name = iTemp0 27 ;; 808 28 ;; 825 size=1 29 ;;Warning -pic port ignoring get(AOP_ACC) 1102 30 ;; line = 799 result AOP_ACC=AOP_accumulator_bug, left AOP_DIR=_PORTB, right AOP_LIT=0xa0, size = 1 31 ;; *** pic16_getDataSize 1786 32 ;; *** pic16_genPlusIncr 168 33 ;; result AOP_ACC, left AOP_DIR, right AOP_LIT 34 ;; pic16_genPlusIncr 180 35 ;; *** pic16_getDataSize 1786 36 ;; adding lit to something. size 1 37 ;; *** genAddLit 462 38 ;; *** pic16_getDataSize 1786 39 ;; left and result aren't same genAddLit 687 40 ;#CSRC m2.c 17 41 ; alfa = PORTB + 0xa0; 42 MOVLW 0xa0 ;key=000 3998 43 ;; 1255 popRegFromString _PORTB 44 ;; 1271 _PORTB offset=0 - had to alloc by reg name 45 ADDWF _PORTB,W ;key=000 3998 46 ;; *** emitMOVWF 445 ignoring mov into W 47 ;;ic S 0x153 48 ;; *** genIfx 9162 49 ;; 752 50 ;; *** 795: symbol name = iTemp0 51 ;; 808 52 ;; 825 size=1 53 ;; *** pic16_toBoolean 1859 54 ;; *** genIfxJump 3579 55 ;#CSRC m2.c 20 56 ; if(alfa && 0x80 == 0x80) { 57 BTFSC _STATUS,2 ;key=000 3998 58 ;; *** pic16_popGetLabel key=2, label offset 4 59 GOTO _00106_DS_ ;key=000 3998 60 ; goto _00106_DS_ 61 ;;ic ~ 0x7e -------------------------- Check lines 29 and 30. There definitely is an accumulator bug, but where it comes from? Do the creators of the pic/pic16 port know anything about it? In addition I would like some of you who have the time, please do acknoledge that the problem is reproducable to your version of SDCC. I have been doing some developing to the sources, and I may have touched something that shouldn't! Regards, Vangelis Rokas |