gnupic: Thread: SDCC overoptimizing


[<<] [<] Page 1 of 1 [>] [>>]
Subject: SDCC overoptimizing
From: Erik Gustavsson ####@####.####
Date: 28 Mar 2003 22:38:19 -0000
Message-Id: <1680399810.1048890339445.JavaMail.webmail@webmail3>

Hi.

I've used only ASM for my previous PIC projects, but
now I thought I'd give SDCC a try for my latest creation.

I'm having some problems with statements getting optimized
down to nothing. For example:

while(!TMR1IF);

I would expect this to become something like:

label:
BTFSS TMR1IF
GOTO label

But instead it just becomes an endless loop...

Also, I'm trying to write a byte to a HD44780 LCD
using this code snippet:

#define LCD_DPORT PORTA
BIT_AT(PORTB_ADDR,4) LCD_E1;
BIT_AT(PORTB_ADDR,5) LCD_E2;
BIT_AT(PORTB_ADDR,6) LCD_RS;
BIT_AT(PORTB_ADDR,7) LCD_RW;

void lcd_write(char x)
{
   LCD_DPORT=x;
   LCD_E1=1;   
   LCD_E1=0;
}

Here the first E1 assignment (that is "BSF PORTB,4") is
optimized away...


Subject: Re: SDCC overoptimizing
From: Scott Dattalo ####@####.####
Date: 28 Mar 2003 23:09:16 -0000
Message-Id: <Pine.LNX.4.44.0303281453420.31802-100000@ruckus.brouhaha.com>

On Fri, 28 Mar 2003, Erik Gustavsson wrote:

> Hi.
> 
> I've used only ASM for my previous PIC projects, but
> now I thought I'd give SDCC a try for my latest creation.
> 
> I'm having some problems with statements getting optimized
> down to nothing. For example:

That code was clearly unnecessary! :)

The PIC Port of SDCC has become stagnant. The bugs you've reported are 
known, but they're not being addressed. What's worse is that I don't know 
when I'll be returning to SDCC. 

Scott

Subject: Re: SDCC overoptimizing
From: Ralf Forsberg ####@####.####
Date: 29 Mar 2003 00:03:42 -0000
Message-Id: <20030328235034.GA572@home.se>

On Fri, Mar 28, 2003 at 11:25:39PM +0100, Erik Gustavsson wrote:
> 
> #define LCD_DPORT PORTA
> BIT_AT(PORTB_ADDR,4) LCD_E1;
> BIT_AT(PORTB_ADDR,5) LCD_E2;
> BIT_AT(PORTB_ADDR,6) LCD_RS;
> BIT_AT(PORTB_ADDR,7) LCD_RW;
> 
> void lcd_write(char x)
> {
>    LCD_DPORT=x;
>    LCD_E1=1;   
>    LCD_E1=0;
> }
> 
> Here the first E1 assignment (that is "BSF PORTB,4") is
> optimized away...

I belive this specific issue can be worked around by changing the
definition of BIT_AT() to use sbit instead of bit. 

http://sourceforge.net/tracker/index.php?func=detail&aid=688137&group_id=599&atid=100599

 / Ralf

Subject: Re: SDCC overoptimizing
From: Erik Gustavsson ####@####.####
Date: 29 Mar 2003 01:10:42 -0000
Message-Id: <2031238239.1048899481245.JavaMail.webmail@webmail3>

> > 
> > Here the first E1 assignment (that is "BSF PORTB,4") is
> > optimized away...
> 
> I belive this specific issue can be worked around by changing the
> definition of BIT_AT() to use sbit instead of bit. 
> 
> http://sourceforge.net/tracker/index.php?func=detail&aid=688137&group_id=599&atid=100599
> 

Ah, thanks...  That sounds like it would work. Perhaps it would solve both problems actually, I noticed that while

while(!SOMEBIT);

doesn't work, this does:

while(!(SOMEREG&MASK));

/cyr
--------------------------------------------------
cyrano(at)algonet(dot)se | http://area26.no-ip.org
--------------------------------------------------
Subject: Re: SDCC overoptimizing
From: Erik Gustavsson ####@####.####
Date: 29 Mar 2003 02:29:11 -0000
Message-Id: <1948333766.1048904189813.JavaMail.webmail@webmail3>

Den 28 Mar 2003 skrev Scott Dattalo:

> On Fri, 28 Mar 2003, Erik Gustavsson wrote:
> 
> > Hi.
> > 
> > I've used only ASM for my previous PIC projects, but
> > now I thought I'd give SDCC a try for my latest creation.
> > 
> > I'm having some problems with statements getting optimized
> > down to nothing. For example:
> 
> That code was clearly unnecessary! :)
> 
> The PIC Port of SDCC has become stagnant. The bugs you've reported are 
> known, but they're not being addressed. What's worse is that I don't know 
> when I'll be returning to SDCC. 
> 

That is really a shame. I was really starting to like SDCC,
but I've already been bitten by another bug (I think).

;  PORTB=(PORTB&0xf0)|(0x02);
        MOVLW   0xf0
        ANDWF   _PORTB,W
        MOVLW   0x02
        MOVWF   _PORTB

Seems to me the second MOVLW should have been a IORLW.
I was kind of thinking of having a look at the SDCC 
code myself, but I don't really know where to start...

/cyr
--------------------------------------------------
cyrano(at)algonet(dot)se | http://area26.no-ip.org
--------------------------------------------------
Subject: Re: SDCC overoptimizing
From: Scott Dattalo ####@####.####
Date: 29 Mar 2003 03:24:49 -0000
Message-Id: <Pine.LNX.4.44.0303281902100.23866-100000@ruckus.brouhaha.com>

On Sat, 29 Mar 2003, Erik Gustavsson wrote:

> Den 28 Mar 2003 skrev Scott Dattalo:
> > 
> > The PIC Port of SDCC has become stagnant. The bugs you've reported are 
> > known, but they're not being addressed. What's worse is that I don't know 
> > when I'll be returning to SDCC. 
> > 
> 
> That is really a shame. I was really starting to like SDCC,
> but I've already been bitten by another bug (I think).

Yeah it is ashame. I got stuck in a project that I'm having trouble 
digging myself out of. My participation in SDCC, gpsim, and gpasm have 
suffered.

> 
> ;  PORTB=(PORTB&0xf0)|(0x02);
>         MOVLW   0xf0
>         ANDWF   _PORTB,W
>         MOVLW   0x02
>         MOVWF   _PORTB
> 
> Seems to me the second MOVLW should have been a IORLW.
> I was kind of thinking of having a look at the SDCC 
> code myself, but I don't really know where to start...

Yep, that's a bug.


-------

If you want to look at how to fix these things, then you may want to begin 
by looking at the regression tests in src/regression/*

There you can find numerous files for testing various facets of the PIC 
port. If you run 'make', then a series of scripts will fire off to compile 
the regression code and use gpsim to verify that it compiled properly.

In src/pic/pcode.c are a couple of global variables that affect the way 
SDCC will generate code. In particular, if you set 'debug_verbose' to 
true your .asm generated files will contains tons of debug info (like line 
numbers of SDCC responsible for generating the code). 

That's a start.


Scott

Subject: Re: SDCC overoptimizing
From: Erik Gustavsson ####@####.####
Date: 29 Mar 2003 03:55:20 -0000
Message-Id: <477594197.1048909358119.JavaMail.webmail@webmail3>

> > 
> > ;  PORTB=(PORTB&0xf0)|(0x02);
> >         MOVLW   0xf0
> >         ANDWF   _PORTB,W
> >         MOVLW   0x02
> >         MOVWF   _PORTB
> > 
> > Seems to me the second MOVLW should have been a IORLW.
> > I was kind of thinking of having a look at the SDCC 
> > code myself, but I don't really know where to start...
> 
> Yep, that's a bug.
> 

Here's a patch: 
http://area26.no-ip.org/download/misc/sdcc-orfix.patch

I't seemed like the right thing to do, and works on my
specific code but comes with no warranty beyond that. 

/cyr
--------------------------------------------------
cyrano(at)algonet(dot)se | http://area26.no-ip.org
--------------------------------------------------
Subject: Re: SDCC overoptimizing
From: Scott Dattalo ####@####.####
Date: 31 Mar 2003 00:49:38 -0000
Message-Id: <Pine.LNX.4.44.0303301628090.22669-100000@ruckus.brouhaha.com>

On Sat, 29 Mar 2003, Erik Gustavsson wrote:

> > > 
> > > ;  PORTB=(PORTB&0xf0)|(0x02);
> > >         MOVLW   0xf0
> > >         ANDWF   _PORTB,W
> > >         MOVLW   0x02
> > >         MOVWF   _PORTB
> > > 
> > > Seems to me the second MOVLW should have been a IORLW.
> > > I was kind of thinking of having a look at the SDCC 
> > > code myself, but I don't really know where to start...
> > 
> > Yep, that's a bug.
> > 
> 
> Here's a patch: 
> http://area26.no-ip.org/download/misc/sdcc-orfix.patch

Erik,

I saw your message, but forgot about it when I was fixing the bug... But, 
your patch looks good (although I didn't use it.) In addition to the OR 
and AND bugs, the problem exists with XOR and NEG. I fixed all of these, 
but I wouldn't be surprised to see variations that still caused problems. 
See 

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/sdcc/sdcc/src/regression/and2.c

for the cases that are tested.

Scott


[<<] [<] Page 1 of 1 [>] [>>]


Powered by ezmlm-browse 0.20.