This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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 <fpoulain@enib.fr>
To: Gabriele Caracausi <gabriele@caracausi.it>
CC: 'Colm O' Flaherty' <colm_o_flaherty@hotmail.com>,damien.thebault@laposte.net, gcc@gnu.org, tbird-contact@cox.net,dj@redhat.com, mrs@apple.com, Kevin.Tucker@Microchip.com,Lmjennings@ra.rockwell.com, raimund@vmars.tuwien.ac.at, mjv@x64.com,trebor@trebor.org, vrokas@otenet.gr, alex@monaghan.co.uk,dooms@student.info.ucl.ac.be, denisc@overta.ru, aph@redhat.com,matz@suse.de, dave@cyclicode.net, eric.robert@videotron.ca,Svein.Seldal@solidas.com
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:fpoulain@enib.fr]
> Sent: Monday, March 06, 2006 7:56 PM
> To: Colm O' Flaherty
> Cc: damien.thebault@laposte.net; gcc@gnu.org; tbird-contact@cox.net; gabriele@caracausi.it; dj@redhat.com; mrs@apple.com; Kevin.Tucker@Microchip.com; Lmjennings@ra.rockwell.com; raimund@vmars.tuwien.ac.at; mjv@x64.com; trebor@trebor.org; vrokas@otenet.gr; alex@monaghan.co.uk; dooms@student.info.ucl.ac.be; denisc@overta.ru; aph@redhat.com; matz@suse.de; dave@cyclicode.net; eric.robert@videotron.ca; Svein.Seldal@solidas.com
> 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
>







Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]