gnupic: Thread: sdcc bug

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 

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

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

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.

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

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: ####@####.####
>