Subject:
Re: [gnupic] SDCC 2.6.0, finds pic14 header files but not pic16
From:
Dan Andersson ####@####.####
Date:
3 Aug 2006 13:49:49 +0100
Message-Id: <200608031334.11099.dan.andersson@ieee.org>
On Thursday 03 August 2006 13:02, Dave Tweed wrote:
> 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
>
Or, if it's a timecritical application, write inline assembler!
Cheers
Dan
--
Dan Andersson, M0DFI
####@####.#### ####@####.####
