This is the mail archive of the
mailing list for the GCC project.
RE: Backend Programming
- From: "Eric Robert" <synapzzz at hotmail dot com>
- To: "'Dave Hudson'" <dave at cyclicode dot net>
- Cc: <gcc at gcc dot gnu dot org>
- Date: Mon, 19 Aug 2002 13:35:12 -0400
- Subject: RE: Backend Programming
Thanks. I suspected that it would be at lot of work. I guess that the
newer PIC family isn't much better for GCC integration.
So, all I have to do is to read the GCC manual.
Any "How To"?
From: email@example.com [mailto:firstname.lastname@example.org] On Behalf Of
Sent: August 19, 2002 12:54 PM
To: Eric Robert
Subject: Re: Backend Programming
Eric Robert wrote:
> I would like to use GCC to program some types of microcontrollers -
> Microchip's PIC if it's of any interest - and I would like to know the
> amount of work involved in writing a backend for this very small chip?
> It has very few instructions and very few registers.
The "very few instructions" and "very few registers" will actually be
the major problem here. I've spent a great deal of time working on the
backend of the IP2022 in the last 18 months and this has some PIC-like
characteristics (e.g. one accumulator register and only 3 pointer
registers) and the lack of pointers creates major headaches.
With the IP2022 the only way to have a chance to get things to work
correctly was to essentially hide the W register (accumulator)
throughout almost all of the code generation (exposing it only right at
the end in the machine-dependent reorg in order to get better code
generation - much of this has not yet been merged into the FSF sources).
Similarly the reload pass causes major problems w.r.t. pointer
Some of the bigger PICs may now make things a little easier (I'm not
sure) but I suspect that getting good code generation will take quite a
significant amount of work.
> 2. Any pointers to what I have to do?
I'd suggest deciding which processor you wish to support first and then
look to see what similarities it has with the 3 contributed 8-bit ports
(AVR, 68HC11 and IP2022) and then look to see what has been required for
each. The AVR is probably the easiest fit for gcc because it's a very
conventional RISC processor, just 8 bits wide. The IP2022 is by far the
most difficult fit although in fact we have now started to get very good
code generation (gcc is the sole production compiler for the processor).