Backend Programming

Backend Programming

[Eric Robert]

Hi,

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.

In fact, it's probably very near some already existing backend so,
hopefully, I won't have to start from scratch. I don't have any
experience in GCC but I have a strong background in C/C++. So, just to
summarize:

1. How much time anyone thinks it takes?
2. Any pointers to what I have to do?

Note: I don't need any part of the standard libraries.

Eric Robert
Software Engineer

Re: Backend Programming

[Dave Hudson]

Hi Eric,

Eric Robert wrote:

RE: Backend Programming

[Eric Robert]

Ok,
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"?

Eric Robert
Software Engineer

-----Original Message-----
From: gcc-owner@gcc.gnu.org [ mailto:gcc-owner@gcc.gnu.org ] On Behalf Of
Dave Hudson
Sent: August 19, 2002 12:54 PM
To: Eric Robert
Cc: gcc@gcc.gnu.org
Subject: Re: Backend Programming

Hi Eric,

Eric Robert wrote:
> Hi,
> 
> 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
handling.

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).


Regards,
Dave
--
PE: dave@cyclicode.net
WE: dave.hudson@ubicom.com