Subject:
Re: [gnupic] SDCC 2.6.0, finds pic14 header files but not pic16
From:
Dave Tweed ####@####.####
Date:
3 Aug 2006 13:02:07 +0100
Message-Id: <E1G8btr-0004Wx-00@pop-canoe.atl.sa.earthlink.net>
mengjin su ####@####.#### wrote:
> I did a testing using SDCC (v2.5.0?). I feel the code efficiency
> is not satisfying. Here is the test C code I wrote:
>
> void strcpy (char *des, char *src)
> {
> while ( (*des++ = *src++) ) {}
> }
>
> The assembly code SDCC generated is
>
> ; ; Starting pCode block
> S_main__strcpy code
> _strcpy:
> ; .line 11; main.c void strcpy (char *des, char *src)
> MOVFF FSR2L, POSTDEC1 ; update stack frame pointer
> MOVFF FSR1L, FSR2L
> MOVFF r0x00, POSTDEC1 ; save registers we want to use
> MOVFF r0x01, POSTDEC1
> MOVFF r0x02, POSTDEC1
> MOVFF r0x03, POSTDEC1
> MOVFF r0x04, POSTDEC1
> MOVFF r0x05, POSTDEC1
> MOVFF r0x06, POSTDEC1
> MOVLW 0x02 ; copy arguments to registers
> MOVFF PLUSW2, r0x00
> MOVLW 0x03
> MOVFF PLUSW2, r0x01
> MOVLW 0x04
> MOVFF PLUSW2, r0x02
> MOVLW 0x05
> MOVFF PLUSW2, r0x03
> MOVLW 0x06
> MOVFF PLUSW2, r0x04
> MOVLW 0x07
> MOVFF PLUSW2, r0x05
> _00105_DS_:
> ; .line 13; main.c while ( (*des++ = *src++) ) {}
> MOVFF r0x03, FSR0L ; get src pointer
> MOVFF r0x04, PRODL
> MOVF r0x05, W
> CALL __gptrget1 ; get the byte it points to
> MOVWF r0x06
> INCF r0x03, F ; increment src pointer
> BTFSC STATUS, 0
> INCF r0x04, F
> BTFSC STATUS, 0
> INCF r0x05, F
> MOVFF r0x06, POSTDEC1 ; push byte on stack for __gptrput1()
> MOVFF r0x00, FSR0L ; get des pointer
> MOVFF r0x01, PRODL
> MOVF r0x02, W
> CALL __gptrput1 ; store the byte it points to
> INCF r0x00, F ; increment des pointer
> BTFSC STATUS, 0
> INCF r0x01, F
> BTFSC STATUS, 0
> INCF r0x02, F
> MOVF r0x06, W ; test byte for zero
> BTFSS STATUS, 2
> GOTO _00105_DS_
> MOVFF PREINC1, r0x06 ; restore saved regsiters
> MOVFF PREINC1, r0x05
> MOVFF PREINC1, r0x04
> MOVFF PREINC1, r0x03
> MOVFF PREINC1, r0x02
> MOVFF PREINC1, r0x01
> MOVFF PREINC1, r0x00
> MOVFF PREINC1, FSR2L ; restore stack frame pointer
> RETURN
>
> What do you think?
Having looked at lots of compiler-generated code for lots of different
8-bit processors, I think it looks quite reasonable, given that the C
code, as written, is perfectly general. (See the annotations above.)
This means that the compiler must use 3-byte pointers and generic
memory access routines like __gptrget1() and __gptrput1(), because it
doesn't know whether the pointers point to RAM, EERPOM or Flash PROM
(code memory).
On processors with multiple memory spaces, you must be careful to take
advantage of whatever storage class qualifiers the compiler provides on
both variables and the pointers that point to them, in order to give
the compiler the information it needs to produce more highly optimized
code.
I know nothing about the details of SDCC for the PIC, but if there's a
way to tell it that both of the pointers can only point to objects in
on-chip RAM, I'm sure the generated code will look much better to you.
-- Dave Tweed
