gnupic: Thread: SDCC Pic Port

I've gone ahead and bit the bullet. I'm starting to port SDCC, Sandeep Dutta's
Small Device C Compiler, to the PIC. SDCC's home page: 
http://sdcc.sourceforge.net/

Sandeep and his team have done most of the hardwork. SDCC creates an
intermediate file that is processed with the device specific code. Some things
like dead code removal, loop optimization, etc. have already been done. This is
going to be a large effort and I'll say up front: NO promises! I've got a
request to Sandeep to get developer's access to their CVS. I'll keep everyone
here posted on the progress.

As I told Sandeep, the plan is this: 
  phase 1 - Port expression's
  phase 2 - Port Call's/Function entry/exit and psuedo stack/register allocation

The reason for this approach is that I'll hopefully learn the SDCC intracacies
good enough during the expression port that I'll be able to handle the much more
difficult parameter passing and function calls.

I've already got addition and subtraction working. I'm in the process of porting
the boolean operators. If you're interested, here's some real output:


test code :


int aint0 = 0;
char achar0 =0;

int test_plus(void)
{

  achar0++;              /* line 22 of t.c */
  achar0 = achar0 + 1;
  achar0 = achar0 + 2;
  achar0 = achar0 + 3;

  aint0++;
  aint0 = aint0 + 1;
  aint0 = aint0 + 2;
  aint0 = aint0 + 3;

}

Compiled output:

;	t.c 22
	incf	_achar0,f
;	t.c 23
	incf	_achar0,f
;	t.c 24
	incf	_achar0,f
	incf	_achar0,f
;	t.c 25
	movlw	0x3
	addwf	_achar0,f
;	t.c 27
	incf	(_aint0 + 1),f
	incfsz	_aint0,f
	decf	(_aint0 + 1),f
;	t.c 28
	incf	(_aint0 + 1),f
	incfsz	_aint0,f
	decf	(_aint0 + 1),f
;	t.c 29
	movlw	0x2
	addwf	_aint0,f
	rlf	_known_zero,w
	 addwf	(_aint0 + 1),f
;	t.c 30
	movlw	0x3
	addwf	_aint0,f
	rlf	_known_zero,w
	 addwf	(_aint0 + 1),f

In case you're wondering, I have no specific deadline for completing this. In
fact, I'd be surprised if the expression stuff is fully working within 3
months. Of course, if anyone cares to help...

Scott

On Sun, Nov 12, 2000 at 05:21:32PM -0600, Scott Dattalo wrote:
> 
> I've gone ahead and bit the bullet. I'm starting to port SDCC, Sandeep Dutta's
> Small Device C Compiler, to the PIC. SDCC's home page: 
> http://sdcc.sourceforge.net/

It's really great!

> Sandeep and his team have done most of the hardwork. SDCC creates an
> intermediate file that is processed with the device specific code. Some things
> like dead code removal, loop optimization, etc. have already been done. This is
> going to be a large effort and I'll say up front: NO promises! I've got a
> request to Sandeep to get developer's access to their CVS. I'll keep everyone
> here posted on the progress.
> 
> As I told Sandeep, the plan is this: 
>   phase 1 - Port expression's
>   phase 2 - Port Call's/Function entry/exit and psuedo stack/register allocation
>

Just two suggestions. AFAIK SDCC does not analyse the call tree
(has it changed last time?).
I think that for PIC16xxxx it is necessary to base the data overlaying
on the call tree analysis.
Additionally it would be good to sacrifice the recursion, and
keep the return address in the RAM (with 8 stack levels it can be difficult
to utilize the recursion anyway ;-).
-- 
			Regards
			Wojciech Zabolotny
			http://www.ise.pw.edu.pl/~wzab

When buying any hardware, ask the dealer if it is Open Source friendly!!!
http://www.openhardware.org

On Mon, 13 Nov 2000, Wojtek Zabolotny wrote:

> Just two suggestions. AFAIK SDCC does not analyse the call tree
> (has it changed last time?).
> I think that for PIC16xxxx it is necessary to base the data overlaying
> on the call tree analysis.
> Additionally it would be good to sacrifice the recursion, and
> keep the return address in the RAM (with 8 stack levels it can be difficult
> to utilize the recursion anyway ;-).

What! You mean you don't want to write functions that are restricted to:

void foo(void)

? :).

I'm not sure if SDCC analyzes the call tree or not. However, I know that it
doesn't make implicit assumptions about the stack being present. There's the
back end compilation that resolves the device depend details. One stage is
called register allocation. For example:


int aint0 = 0;
int aint1 = 0;


int call3(int t)
{
  aint0 = aint1+t;
  return aint0;
}


...

void main(void)
{
  aint0 = call3(aint1);
}

The code generated (which is a mish-mash of 8051 and PIC) is:

for the call3 function:
;	t.c 96
;	-----------------------------------------
;	 function call3
;	-----------------------------------------
_call3:
;	t.c 99
	mov	_call3_t_1_1,dpl ; 902
	mov	(_call3_t_1_1 + 1),dph ; 902
;	t.c 98
	movf	_call3_t_1_1,w
	addwf	_aint1,w
	movwf	_aint0   ;2674
	movf	(_aint1 + 1),w
	movwf	(_aint0 + 1)
	movf	(_call3_t_1_1 + 1),w
	skpnc
	incfsz	(_call3_t_1_1 + 1),w
	addwf	(_aint0 + 1),f
;	t.c 99
	mov	dpl,_aint0
	mov	dph,(_aint0 + 1)
00101$:
	C$t.c$100$1$1 ==.
	XG$call3$0$0 ==.
	ret
	G$main$0$0 ==.
;	t.c 102



And here's where the call is made:

;	t.c 110
	mov	dpl,_aint1
	mov	dph,(_aint1 + 1)
	lcall	_call3
	mov	_aint0,dpl ; 902
	mov	(_aint0 + 1),dph ; 902

The point I want to make, is that the 8051's stack is not even used. Instead,
the compiler places parameters into special compiler-generated variables. These
variables go into an `overlay' area. 

For example, if I create a nearly identical function:

int call3iii(int t)
{
  aint1 = aint2+t;
  return aint1;
}

The compiler creates this overlay area:

;--------------------------------------------------------
; overlayable items in internal ram 
;--------------------------------------------------------
	.area _DUMMY
	.area	OSEG    (OVR,DATA)
	.area _DUMMY
	.area	OSEG    (OVR,DATA)
_call3_t_1_1:
	.ds	0x0002
	.area _DUMMY
	.area	OSEG    (OVR,DATA)
_call3iii_t_1_1:
	.ds	0x0002


It's obviously doing a little analysis to be able to determine that these two
functions can share storage for their temporary variables.


Now for recursion... I'm willing to sacrifice that C-luxury for the PIC
port. SDCC does check for recursion and there are things you can do (at the
command line ) to control it. But for a PIC, 8-hardware levels is all you're
going to get. A software stack is too cumbersome. But I'll cross that bridge
when I get to it.

 Scott

On Tue, Nov 14, 2000 at 07:42:13AM -0600, Scott Dattalo wrote:
> 
> It's obviously doing a little analysis to be able to determine that these two
> functions can share storage for their temporary variables.
> 

In the last version I've used, that rule was very simple: the local
variables in functions which don't call other functions are overlayed.
The consequences were serious - every function using the float or even
int(*/) arithmetic could not use the data overlaying.

Below is the corresponding quotation from SDCCUdoc.txt

# For non-reentrant functions SDCC will try to reduce internal ram space
# usage by overlaying parameters and local variables of a function (if
# possible). Parameters and local variables of a function will be allocated
# to an overlayable segment if the function has no other function calls
# and the function is non-reentrant and the memory model is small. If
# an explicit storage class is specified for a local variable , it will
# NOT be overlayed. 
# [...]
# Parameters and Local variables of functions that contain 16 or 32 bit
# multiplication or division will NOT be overlayed since these are implemented
# using external functions.  

I've heard, that this is associated with the linker's limitations (?).
-- 
			HTH & Regards
			Wojciech Zabolotny
			http://www.ise.pw.edu.pl/~wzab

http://www.debian.org  Use Linux - save your data and time

New stuff in CVS:

  o Fixed a few bugs with addition and subtraction.
  o Structure support introduced.
  o split gen.c into two smaller files.
  o split pcode.c into two smaller files.

Scott

It's been a while since I've said anything about SDCC. A lot has changed. 
I'm not even sure where to begin.

-- Better memory allocation... Device specific memory maps are now 
   supported.


-- Register banking is better supported. You can do stuff like this:

data at 0xa2 unsigned int  ui_bank1_temp=0;

and you can do it with bits too:

#define BIT_AT(base,bitno) bit at ((base<<3)+bitno)
#define TRISB_ADR  0x86

BIT_AT(TRISB_ADR,0) TRISB0;


-- Multiplication is partially supported. 

-- Config word is supported

#define _WDT_OFF         0x3FFB
#define _PWRTE_ON        0x3FF7

typedef unsigned int word;

word at 0x2007  CONFIG = _WDT_OFF & _PWRTE_ON;

-- pCode Peephole optimizer has been enhanced.

I've added commands to categorize instruction types. Before, the following 
rule would have required 4 separate rules, but more importantly the old 
way it was implemented there were certain instances when the 4 rules 
failed.

replace restart {
        _NOTBITSKIP_	%1
	_BITSKIP_	%2
        goto	%3
%4:	%5
%3:	%6
} by {
	;peep 1b - test/jump to test/skip
        %1
	_INVERTBITSKIP_	%2
%4:	%5
%3:	%6
} 


-- structures are more robust.

-- bugs, bugs, and more bugs were fixed. A special thanks goes to Linas 
Vepstas for numerous bug reports.

-----

I'm not sure when the next SDCC release will be. I do know that the PIC 
port is rapidly maturing.

Scott

On Thu, May 16, 2002 at 10:15:49PM -0700, Scott Dattalo was heard to remark:
> 
> It's been a while since I've said anything about SDCC. A lot has changed. 
> I'm not even sure where to begin.
> 
> data at 0xa2 unsigned int  ui_bank1_temp=0;
> 
> and you can do it with bits too:
> 
> #define BIT_AT(base,bitno) bit at ((base<<3)+bitno)
> #define TRISB_ADR  0x86
> 
> BIT_AT(TRISB_ADR,0) TRISB0;
> 
> -- Config word is supported
> 
> #define _WDT_OFF         0x3FFB
> #define _PWRTE_ON        0x3FF7
> 
> typedef unsigned int word;
> 
> word at 0x2007  CONFIG = _WDT_OFF & _PWRTE_ON;

It sure would be nice if someone put together an SDCC-PIC howto 
that included the above information.  Its all too easy to loose a few
afternoons figuring out the stuff above on one's own; never mind one has
to be clever to figure it out ....

But if one does figure it out, one is rewarded... I was able to write a
fairly long program (some 6 or 8 subroutines, maybe approaching a KLOC
of C code) that, with a few bug work-arounds, works fine (it does a/d
conversions on the 16f873, and spits stuff out on the serial port).

So I think SDCC is quite usable by the more adventurous ...

> -- bugs, bugs, and more bugs were fixed. A special thanks goes to Linas 
> Vepstas for numerous bug reports.

Don't know how many of these bugs got fixed.  The howto might want to
discuss bug-work-arounds.  For example, I tripped on the following
'feature':

const char *mystr = "Hello, World!\n";

works find in SDCC, but 

char *mystr = "Hello, World!\n";

does not (the former goes into program memory, since its const; the
latter goes into data registers, since its not const, and might be
altered by the program.  PICs have a whole lot more program memory than
data memory ...).

--linas

-- 
pub  1024D/01045933 2001-02-01 Linas Vepstas (Labas!) ####@####.####
PGP Key fingerprint = 8305 2521 6000 0B5E 8984  3F54 64A9 9A82 0104 5933

On Sun, 19 May 2002, Linas Vepstas wrote:

> 
> On Thu, May 16, 2002 at 10:15:49PM -0700, Scott Dattalo was heard to remark:
> > 
> > It's been a while since I've said anything about SDCC. A lot has changed. 
> > I'm not even sure where to begin.
> > 
> > data at 0xa2 unsigned int  ui_bank1_temp=0;
> > 
> > and you can do it with bits too:
> > 
> > #define BIT_AT(base,bitno) bit at ((base<<3)+bitno)
> > #define TRISB_ADR  0x86
> > 
> > BIT_AT(TRISB_ADR,0) TRISB0;
> > 
> > -- Config word is supported
> > 
> > #define _WDT_OFF         0x3FFB
> > #define _PWRTE_ON        0x3FF7
> > 
> > typedef unsigned int word;
> > 
> > word at 0x2007  CONFIG = _WDT_OFF & _PWRTE_ON;
> 
> It sure would be nice if someone put together an SDCC-PIC howto 
> that included the above information.  Its all too easy to loose a few
> afternoons figuring out the stuff above on one's own; never mind one has
> to be clever to figure it out ....

This would be nice. This info should propogate into the documentation too. 

> 
> But if one does figure it out, one is rewarded... I was able to write a
> fairly long program (some 6 or 8 subroutines, maybe approaching a KLOC
> of C code) that, with a few bug work-arounds, works fine (it does a/d
> conversions on the 16f873, and spits stuff out on the serial port).

This is quite surprising! It sounds like SDCC is more usable than I had 
thought.

> 
> So I think SDCC is quite usable by the more adventurous ...
> 
> > -- bugs, bugs, and more bugs were fixed. A special thanks goes to Linas 
> > Vepstas for numerous bug reports.
> 
> Don't know how many of these bugs got fixed.  

You reported about a dozen and I fixed all but two. I also fixed several 
more bugs related to these (the whole right shift thing is broken for 
longs).

>                                              The howto might want to
> discuss bug-work-arounds.  For example, I tripped on the following
> 'feature':
> 
> const char *mystr = "Hello, World!\n";
> 
> works find in SDCC, but 
> 
> char *mystr = "Hello, World!\n";
> 
> does not (the former goes into program memory, since its const; the
> latter goes into data registers, since its not const, and might be
> altered by the program.  PICs have a whole lot more program memory than
> data memory ...).

This is one of the bugs I did not "fix". I looked at it and decided to 
hold off for now. All that needs to be done is to allocate space in RAM 
and copy the string there. 

The only other outstanding bug you reported is the pointer passing 
smashing one. You have a simple work-around (patch), so for now I'm 
letting slip. I have too many other ones to tackle first!

Scott

There have been two major enhancements introduced to PIC Port.

First, Kevin Pauba has submitted a Perl script that will translate a 
Microchip .inc file into a C .h file! 

As Kevin describes:

-----------------------------------------------------

I'm please to announce the availability of the INC2H utility to convert
MPASM include files to header files suitable for use with the SDCC
compiler.

This script identifies special function registers and register bits
automatically.  The special function registers are converted to 'sfr'
declarations and the register bits are converted to 'bit' declarations.

Volatile registers can be specified in a table at the end of the script
and will automatically declared as 'volatile char' types.
 
Here's a sample command-line invocation:

$ perl inc2h.pl /usr/share/gpasm/header/p16f877.inc >p16f877.h

I've tested this script on all MPASM header files for the processors
that are currently supported by SDCC (p16f627, p16f628, p16f84, and 
p16f877).

With this announcement I must also ask for your help.

While I've written a few perl scripts in my time, I'm a beginner PIC guy.  
I have no knowledge which registers should be considered as 'volatile' --
those registers that may change without direct manipulation.  I've
initially declared the INDF and PCL registers as being volatile but would
appreciate your help in determining others.  Please post your findings to
the gnupic mailing list ####@####.#### and I'll update the INC2H
utility.


-----------------------------------------------------

I (Scott) can also add that Kevin script automatically declares bit 
variables for all of the SFRs too. The script can be found in the SDCC CVS 
repository here:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/sdcc/sdcc/support/scripts/

and it's called inc2h.pl. (Probably should've called it pic-inc2h.pl in 
retrospect...)

The other big enhancement is that register optimization has been improved.  
I added some new algorithms to track register usage. For now, all
registers that are used only once will most likely be optimized away. This
has significantly reduced the size of the .hex files in the regression
test. Over the next few days, I'll collapse registers that do not overlap. 
This should free up registers.

---
These changes are in CVS. Please see http://sdcc.sourceforge.net/ for 
instructions on getting SDCC from CVS.

Scott