Post by thread:PICLIST Digest - 13 Jan 1999 to 14 Jan 1999

Hi, Well, I have been reading the gcc manual (the one that comes with the source) and I have been studying Otto Lind's port of gcc to the 68HC11. As far as I can see there is nothing that would make porting gcc to the PIC 16F84 impossible or unfeasible. Sure the Pic has no builtin stack, so you have to simulate one in RAM. But gcc's optimization seems to be so good that most stack invokations are eliminated anyway. Furthermore the Pic has only one register, so you have to work with virtual registers (as is the case for the 68HC11 port). This has the potential of generating unnecessary store's and load's, but again gcc seems to optimize these away. In fact the optimization power of gcc seems to be truly awesome! The fact that the Pic is 8bit, does not make it impossible to work with 16bit (or higher) variables. Gcc will store these in consecutive (virtual)registers or stack locations. One thing I was worried about was the implementation of the "const" directive (this should be implemented through a lookup table). However gcc will place constant array's in code space (see the 68HC11 port), with the correct directive to make them lookup tables. As far as needing a new linker, I don't see why. The compiler would generate MPASM files, which can be linked with Microchip's MPLINK and MPLIB. I think there is enough code around to make a good standard 16 bit library. To port gcc one would only need to write three files: picxxxx.md : The machine description: describes the types of instructions availabe. This is a kind of rule based expert system. picxxxx.h : Macro definitions describing the stack outline, register usage, memory addressing schemes, function prologue and epilogue, passing of arguments in registers, etc... picxxxx.c : Support for picxxxx.h (some things are a little to complicated to be implemented as macros). Also, when using makefiles, it is better to have a .c file than a .h file. The latter tends to trigger recompilation of everything. If I find the time then I plan to try write some of these. I wouldn't follow the 68HC11 port too closely, since I think Otto Lindt might have missed s ome potential optimizations (like the possibility of eliminating entirely a stack frame for a function, which will happen quite often I think). If other people are interested please email me (people from gnupic?). But please read the manual (Richard Stallmann's "Using and porting gcc") and study the 68HC11 port f irst (a search with altavista for the words 68hc11 and gcc will turn up the latter). Regards, Michel

I think you will end up close to targeting gcc to a 32-bit architecture and interpreting that architecture on the PIC. But of course I am prejudiced because I choose a different route. I'd be interested in your experiences! (I once stared targeting gcc to some weird space-grade processor but I had to give up because there wasn't even a good assembler or CPU decription available.) Keep a few things in mind when you target PICs: - the 8 (or even 2) level stack is a real trouble, so consider to - check the amount of stack needed at compiler time - replace tail calls with jumps - inline at least the single-called routines - provide some alternative (store a return indication and use a goto insetad of a call) - accessing all data via some index register is slow and uses lots of code; a static-stack requires more work from the compiler (and cannot cope with recusion) but is otherwise much better regards, Wouter ---------- {Quote hidden}> From: Michel Van den Bergh <spam_OUTvdberghTakeThisOuTZOLA.LUC.AC.BE> > To: .....PICLISTKILLspam@spam@MITVMA.MIT.EDU > Subject: Re: PICLIST Digest - 13 Jan 1999 to 14 Jan 1999 > Date: Saturday, January 16, 1999 13:05 > > Hi, > > Well, I have been reading the gcc manual (the one that comes with the > source) and I have been studying Otto > Lind's port of gcc to the 68HC11. As far as I can see there is nothing > that would make porting gcc to the PIC 16F84 impossible or unfeasible. > > Sure the Pic has no builtin stack, so you have to simulate one in RAM. But > gcc's optimization seems to be so good that most stack invokations are > eliminated anyway. > > Furthermore the Pic has only one register, so you have to work with > virtual registers (as is the case for the 68HC11 port). This has the > potential of generating unnecessary store's and load's, but again gcc > seems to optimize these away. In fact the optimization power of gcc seems to {Quote hidden}> be truly awesome! > > The fact that the Pic is 8bit, does not make it impossible to work with > 16bit (or higher) variables. Gcc will store these in consecutive > (virtual)registers or stack locations. > > One thing I was worried about was the implementation of the "const" > directive (this should be implemented through a lookup > table). However gcc will place constant array's in > code space (see the 68HC11 port), with the correct directive to make > them lookup tables. > > As far as needing a new linker, I don't see why. The compiler would > generate MPASM files, which can be linked with Microchip's MPLINK and > MPLIB. I think there is enough code around to make a good standard 16 > bit library. > > To port gcc one would only need to write three files: > > > picxxxx.md : The machine description: describes the types of > instructions availabe. This is a kind of rule based expert system. > > picxxxx.h : Macro definitions describing the stack outline, register > usage, memory addressing schemes, function prologue and epilogue, > passing of arguments in registers, etc... > > > picxxxx.c : Support for picxxxx.h (some things are a little to > complicated to be implemented as macros). Also, when using makefiles, > it is better to have a .c file than a .h file. The latter tends to trigger > recompilation of everything. > > If I find the time then I plan to try write some of these. I wouldn't > follow the 68HC11 port too closely, since I think Otto Lindt might have missed some > potential optimizations (like the possibility of eliminating entirely a stack > frame for a function, which will happen quite often I think). > > If other people are interested please email me (people from gnupic?). But please read the > manual (Richard Stallmann's "Using and porting gcc") and study the 68HC11 port first (a > search with altavista for the words 68hc11 and gcc will turn up the latter). > > > Regards, > Michel