[<<] [<] Page 1 of 1 [>] [>>] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
SDCC Pic Port
From: Scott Dattalo ####@####.#### Date: 12 Nov 2000 23:14:15 -0000 Message-Id: <Pine.LNX.4.21.0011121700470.27546-100000@tempest2.blackhat.net> 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: SDCC Pic Port
From: Wojtek Zabolotny ####@####.#### Date: 13 Nov 2000 22:44:49 -0000 Message-Id: <20001113234103.A3716@wzab.nasz.dom> 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: SDCC Pic Port
From: Scott Dattalo ####@####.#### Date: 14 Nov 2000 13:34:59 -0000 Message-Id: <Pine.LNX.4.21.0011140652320.3546-100000@tempest2.blackhat.net> 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: SDCC Pic Port
From: Wojtek Zabolotny ####@####.#### Date: 14 Nov 2000 22:01:07 -0000 Message-Id: <20001114230256.A2044@wzab.nasz.dom> 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
SDCC PIC Port
From: Scott Dattalo ####@####.#### Date: 1 Apr 2001 15:26:07 -0000 Message-Id: <Pine.LNX.4.21.0104011031520.12510-100000@tempest2.blackhat.net> 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
SDCC PIC Port
From: Scott Dattalo ####@####.#### Date: 17 May 2002 05:25:16 -0000 Message-Id: <Pine.LNX.4.44.0205162200030.1514-100000@ruckus.brouhaha.com> 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: SDCC PIC Port
From: ####@####.#### (Linas Vepstas) Date: 19 May 2002 13:53:41 -0000 Message-Id: <20020519134404.GA7692@backlot.linas.org> 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: SDCC PIC Port
From: Scott Dattalo ####@####.#### Date: 19 May 2002 14:11:43 -0000 Message-Id: <Pine.LNX.4.44.0205190653270.4765-100000@ruckus.brouhaha.com> 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
SDCC PIC Port
From: Scott Dattalo ####@####.#### Date: 23 Jun 2002 04:17:29 -0000 Message-Id: <Pine.LNX.4.44.0206222051290.26465-100000@ruckus.brouhaha.com> 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
[<<] [<] Page 1 of 1 [>] [>>] |