[<<] [<] Page 1 of 1 [>] [>>] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
sdcc bug
From: "Ricardo Amezquita Orozco" ####@####.#### Date: 14 Oct 2002 16:59:49 -0000 Message-Id: <ILINENHPILOCIAAA@mailcity.com> Hello I wrote a small program, to test some things in the pic port of the sdcc compiler, and I think I found a bug. The C source is the folowing #include "p16f877.h" #define __16F877 BIT_AT (PORTA_ADDR,0) PA; BIT_AT (PORTB_ADDR,0) PB; int main() { int i; int j; TRISB=255; ADCON1=0x06; TRISA=0x00; while(1) { if(PB==0)PA=1; else PA=0; } } the generated asm is the following ....... ;; Starting pCode block _main ;Function start ; 2 exit points ;#CSRC test.c 11 ; TRISB=255; MOVLW 0xff BSF _STATUS,5 # change to bank 1 MOVWF _TRISB ;#CSRC test.c 12 ; ADCON1=0x06; MOVLW 0x06 MOVWF _ADCON1 ;#CSRC test.c 13 ; TRISA=0x00; CLRF _TRISA _00109_DS_ ;#CSRC test.c 14 ; while(1) BTFSC (_PB >> 3), (_PB & 7) # still in bank 1 but pb is in bank 0 GOTO _00106_DS_ BCF _STATUS,5 ;#CSRC test.c 16 ; if(PB==0)PA=1; BSF (_PA >> 3), (_PA & 7) GOTO _00109_DS_ _00106_DS_ ;#CSRC test.c 17 ; else PA=0; BCF (_PA >> 3), (_PA & 7) GOTO _00109_DS_ RETURN ; exit point of _main end The asm file is triying to check if PB==0 in the wrong bank ____________________________________________________________ Watch a championship game with Elway or McGwire. Enter Now at http://champions.lycos.com | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: sdcc bug
From: Samuel Tardieu ####@####.#### Date: 14 Oct 2002 17:43:16 -0000 Message-Id: <2002-10-14-19-40-03+trackit+sam@inf.enst.fr> On 14/10, ?Ricardo Amezquita Orozco wrote: | BCF (_PA >> 3), (_PA & 7) [...] | The asm file is triying to check if PB==0 in the wrong bank and sets PA to 0 in the wrong bank too. Sam | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: sdcc bug
From: Samuel Tardieu ####@####.#### Date: 14 Oct 2002 20:17:58 -0000 Message-Id: <2002-10-14-22-14-45+trackit+sam@rfc1149.net> Your post reminded me that I wanted to look at SDCC for a long time. While reading the source, I noticed the latest peephole optimization: replace restart { movf %1,w movwf %1 } by { ; peep 11 - Removed redundant move movf %1,w } This optimization looks dangerous to me in at least two situations: - one wants to mirror the perceived state of a port in high-impedance mode (portb = portb) - one wants to act on a timer by having it loose four instruction cycles (tmr0 = tmr0 will do that) What kind of C code could produce such a pattern which needs to be optimized? Sam -- Samuel Tardieu -- ####@####.#### -- http://www.rfc1149.net/sam | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
SDCC bug
From: Craig Franklin ####@####.#### Date: 12 Nov 2003 02:58:26 -0000 Message-Id: <1068604327.2017.11.camel@R2D2> A user has reported an SDCC/gplink bug. https://sourceforge.net/tracker/?func=detail&atid=431665&aid=840370&group_id=41924 The problem appears to be in SDCC. udata sections are the default for SDCC data memory. Some devices (16f873) only have sharebank memory available. The user seemed to think other people were having SDCC target memory allocation problems. If you experience this problem, a work around is to modify the linker script. Change the unprotected SHAREBANK sections to DATABANK. This isn't strictly correct, but it should make gplink happy. The final solution will require a change to SDCC. Either to allow the user to specify the data memory section or to change the default section type depending on the device. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: SDCC bug
From: Scott Dattalo ####@####.#### Date: 12 Nov 2003 14:29:19 -0000 Message-Id: <Pine.LNX.4.44.0311120558440.26936-100000@ruckus.brouhaha.com> On 11 Nov 2003, Craig Franklin wrote: > A user has reported an SDCC/gplink bug. <snip> > The final solution will require a change to SDCC. Either to allow the > user to specify the data memory section or to change the default section > type depending on the device. If the default section were to then what would it change to? Scott | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: SDCC bug
From: Craig Franklin ####@####.#### Date: 13 Nov 2003 01:34:11 -0000 Message-Id: <1068685664.3216.0.camel@R2D2> On Wed, 2003-11-12 at 08:03, Scott Dattalo wrote: > On 11 Nov 2003, Craig Franklin wrote: > > > A user has reported an SDCC/gplink bug. > > <snip> > > > The final solution will require a change to SDCC. Either to allow the > > user to specify the data memory section or to change the default section > > type depending on the device. > > If the default section were to then what would it change to? > For that device, "udata_shr" should be used for the data section directive. > Scott > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: ####@####.#### > For additional commands, e-mail: ####@####.#### > | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
[<<] [<] Page 1 of 1 [>] [>>] |