Re: GCC Port (gcc backend) for Microchip PICMicro microcontroller

Tue, 14 Mar 2006 05:07:06 -0800

Note that there is some interesting documentation regarding adding a new backend (PIC, for example), and general gcc development issues at: http://gcc.gnu.org/readings.html This section answers a couple of the questions I have already asked, or was about to ask! RTFM, I guess.. :)
In the absence of a binutils package for PIC, we could use gputils initially to save time, and then, at a later point in time, add the binutils package. 


Most existing GCC ports for microcontrollers rely on a matching Binutils 
port in order to provide an assembler (GAS) and linker (GNU ld).  GCC 
itself always produces assembler output (which may or may not be saved to a 
file).


Colm O' Flaherty wrote:


All,


I've been thinking a bit more about this (no code yet: I was busy trying 
to find and fix a bug in gpsim), and I'm still not sure what the optimal 
development mode is.. by this, I mean.. "what should the proposed PIC port 
of GCC produce"?


.c -> .asm
.c -> .hex (or .ihx)


There are pros and cons to both approaches. Producing a hex file is (a 
lot?) more work, and would duplicate the work of gputils, but would leave 
gcc as a standalone tool, which I presume is desirable!



Producing .asm files would also be viable.  These files could then be fed 
into gputils (gpasm, gplink), which would produce the hex file.  This is 
how SDCC operates.  The issue here is that that gcc would then become 
"bound" to gputils, or some tool like it.  An added advantage of this 
approach would be that the result could be visually simulated on a PIC in 
gpsim (a terrific advantage, if you ask me), with the knowledge of what 
line of C code is being executed (but running the assembly code).  The 
real issue here, for me, is the level of duplication / overlap with the 
SDCC project.


Any thoughts or preferences?

What view would the gcc purists take of these two approaches?

How does the existing gcc microcontroller ports operate? Do they produce 
hex files, or assembly?


Colm


From: François Poulain <[EMAIL PROTECTED]>
To: Gabriele Caracausi <[EMAIL PROTECTED]>

CC: 'Colm O' Flaherty' 
<[EMAIL PROTECTED]>,[EMAIL PROTECTED], [EMAIL PROTECTED], 
[EMAIL PROTECTED],[EMAIL PROTECTED], [EMAIL PROTECTED], 
[EMAIL PROTECTED],[EMAIL PROTECTED], 
[EMAIL PROTECTED], [EMAIL PROTECTED],[EMAIL PROTECTED], 
[EMAIL PROTECTED], [EMAIL PROTECTED],[EMAIL PROTECTED], 
[EMAIL PROTECTED], [EMAIL PROTECTED],[EMAIL PROTECTED], [EMAIL PROTECTED], 
[EMAIL PROTECTED],[EMAIL PROTECTED]
Subject: RE: GCC Port (gcc backend) for Microchip PICMicro 
microcontroller

Date: Wed, 08 Mar 2006 20:16:39 +0100

I am interested by your work, you can share it. What was your Gcc
development version ?

Le mercredi 08 mars 2006 à 18:56 +0100, Gabriele Caracausi a écrit :
> Hi Francois, Colm,
>
> I've read your emails and I'd like to be involved in this project.
>

> As you can read in my past emails in the GCC ML, I've tried two years 
ago to create a porting of GCC to PIC 18FXXX.

>

> The project was developed when I was student without a truly and 
strong guide in all involved activities.
> My proposal is: I could share the code I've developed but, keep in 
mind, that the code should contain some error.

>

> Starting from it, we could continue / modify / correct / improve the 
porting all together. What do you think about it ?

>
> Ciao!
> Gabriele.
>
>
>
>
>
>
> -----Original Message-----
> From: Franзois Poulain [mailto:[EMAIL PROTECTED]
> Sent: Monday, March 06, 2006 7:56 PM
> To: Colm O' Flaherty

> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; 
[EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; 
[EMAIL PROTECTED]; [EMAIL PROTECTED]; 
[EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; 
[EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; 
[EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; 
[EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: GCC Port (gcc backend) for Microchip PICMicro 
microcontroller

>
> > Like you, I'm still studying the internals of gcc, but I'm close to
> > being confident enough to start making some changes.
>
> Nice !
>
> Le lundi 06 mars 2006 а 17:17 +0000, Colm O' Flaherty a йcrit :
> > Francois,
> >
> > There are only 35 instructions in the 14 bit instruction set, and
> > given that, in gcc, the main initial work seems to be in describing
> > the targets instruction set, it might not take much to find out what

> > implementation issues will occur, by just taking to the time to 
describe the instructions.

> > For me, the things that I suspect to be issues are:
> >
> > -8 bit ALU
> > -small memory space
> > -limited stack space (8 levels on 16F) -the number of PIC devices
> > (configurations) that would need to be supported (with the various
> > number of banks, and memory configs)
> >
> > Like you, I'm still studying the internals of gcc, but I'm close to
> > being confident enough to start making some changes.
> >
> > Colm
>

































					Reply via email to