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

[Colm O' Flaherty]

It seems that there is already a PIC port for gcc.. in the form of 
Microchips own MPLAB C30 compiler.. I didn't realise this (and google 
certainly didn't tell me) until I had started on the PIC14 port for gcc, and 
went to the Microchip website for some info, and searched on "C compiler" 
and then "gcc" out of curiosity... lo and behold, the source code for their 
port.. (based on gcc 3.3, it seems).


It supports "Microchip 16-bit devices: PIC24, dsPIC30F and dsPIC33F"

Microchip sells MPLAB C30 as a commercial product.  On the "Buy It now" 
page, they have a link to the source code though, so I grabbed a copy... :)


(Part Number: SW006012 - MPLAB C30 C Compiler for dsPIC30/33, PIC24:   (GBP) 
£ 513 )


Colm

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

[François Poulain]

Yes, I have the source code of this backend. It's based on gcc-3.3.

You can find an URL to download the source code on the GCC mailing, else
I can put it on a FTP server.

PoluX

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

[Aaron W. LaFramboise]

I have also recently become interested in a GCC port for the 18F.

Can someone summarize who--if anyone--is working on this, how much 
progress he has made so far (Is his work based on mainline?), and any 
expected future milestones?


(And who are all of the people in the CC list?  Is there some other list 
discussing this?)


I think that the major work that will need to be done for this port is 
figuring out how to get segmentation to work.  Some other potential 
ports need this too, so if there's any way to do this in a way that all 
ports can benefit, that would be great.  I think this is definitely 
possible, but it seems like it may take some effort--particularly to get 
the changes into a form acceptable for inclusion into FSF GCC.


The way I would do this (and will, perhaps, if noone else intends to 
work on this any time soon) is to consider the access bank (low 128 GPRs 
and some of the high 128 SPRs) as the GCC registers.  (I am not sure if 
~140 registers is too many for GCC to handle effectively; Are there 
ports that use this many?)  This will yield a port that can deal with at 
least 512 bytes of memory, I think.  Implementing segmentation will give 
it access to the rest of the banks.

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

[Colm O' Flaherty]

Aaron,

I'm currently working on this, for one.  I'm in the very early stages of 
development.


I'm currently using the following GCC ports (backends) for references 
purposes: AVR, m68hc11/12.  My code is currently based on GCC 3.3, but I'll 
migrate to mainline as soon as I have any changes outside of the 
config/pic14 folder.


The cc list of the mail is based on a list of people from this list who 
historically displayed interest in a PIC port for GCC.  We should probably 
just mail to the list now though, as some of the emails no longer exist.


To summarise my knowledge of existing work in progress:

- Francois Poulain had done some work on a port.
- I've commenced (I wanted to start from scratch in order to fully 
understand the architecture, and to make sure I was able to use the 
mainline)
- someone else mentioned they had done some work (this should be apparent 
from searching the list)


There's no organised (non-individual) GCC port in progress yet, as far as 
I'm aware.  If I make good progress on my work, I'll happily make it 
available for general participation, but its too early for that.


Have you checked out SDCC?  This may support the specific devices you're 
interested in.  For my part, I'm more interested in a GCC port than SDCC 
though, as I feel there is an awful lot more to be gained from a gcc port in 
the longer term.


I think one of the existing GCC microcontroller back ends already supports 
banking (segmentation).. I just can't remember offhand which one..


Colm

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

[Colm O' Flaherty]

See also the recent mails on "Re: GCC port for V8-uRISC (8 bit CPU)", which 
I'm not really familiar with yet, but which could be very relevant.


Colm

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

[Aaron W. LaFramboise]

Colm O' Flaherty wrote:

Have you checked out SDCC?  This may support the specific devices you're 
interested in.  For my part, I'm more interested in a GCC port than SDCC 
though, as I feel there is an awful lot more to be gained from a gcc 
port in the longer term.


As near as I can tell, the support in SDCC for the 18F is pretty weak. 
I haven't actually tried it, but comments from the main person working 
on 18F support in SDCC lead me to beleive it has a way to go yet.


But really, I don't understand why SDCC needs to exist.  GCC provides 
95% of any ordinary C compiler port.  It has better support for the C 
language (and other languages) than something like SDCC will likely ever 
have; it also has a superior optimizer, even if this optimizer is not 
presently tuned for small devices.


In any case, I'm mostly interested in C++.

I will probably start working on a 18F back-end if no definite plans for 
implementing a complete port materialize 'soon.' (that is, if no-one 
else seems likely to produce anything within the next few months)

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

[Colm O' Flaherty]

I will probably start working on a 18F back-end if no definite plans for 
implementing a complete port materialize 'soon.' (that is, if no-one else 
seems likely to produce anything within the next few months)


Well I suppose these things need to start from individuals grouping 
together.. I'm happy to share my work with you for collaborative purposes, 
but at the minute, there isn't much to share..

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

[François Poulain]

Le vendredi 07 avril 2006 à 02:54 -0500, Aaron W. LaFramboise a écrit :
> I have also recently become interested in a GCC port for the 18F.
> 
> Can someone summarize who--if anyone--is working on this, how much 
> progress he has made so far (Is his work based on mainline?), and any 
> expected future milestones?
I am studying the gcc internal guide for the moment. I am very busy for
the moment, and I won't write much code before July.

> 
> (And who are all of the people in the CC list?  Is there some other list 
> discussing this?)

I am on gcc dicussing list.

> 
> I think that the major work that will need to be done for this port is 
> figuring out how to get segmentation to work.  Some other potential 
> ports need this too, so if there's any way to do this in a way that all 
> ports can benefit, that would be great.  I think this is definitely 
> possible, but it seems like it may take some effort--particularly to get 
> the changes into a form acceptable for inclusion into FSF GCC.

I think so. Microchip have done a modified version of GCC-3.3 with
DSPICs support, so we have got a heavy good base to work on the
instruction set, wich is similar for PIC18. DSPIC is a 16 bit CPU, so is
memory isn't segmented.

> 
> The way I would do this (and will, perhaps, if noone else intends to 
> work on this any time soon) is to consider the access bank (low 128 GPRs 
> and some of the high 128 SPRs) as the GCC registers.  (I am not sure if 
> ~140 registers is too many for GCC to handle effectively; Are there 
> ports that use this many?)  This will yield a port that can deal with at 
> least 512 bytes of memory, I think.  Implementing segmentation will give 
> it access to the rest of the banks.
> 

For the instant, I don't know how to implement any kind of way in gcc.

Salutations,

Francois Poulain

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

[Aaron W. LaFramboise]

François Poulain wrote:


I think so. Microchip have done a modified version of GCC-3.3 with
DSPICs support, so we have got a heavy good base to work on the
instruction set, wich is similar for PIC18. DSPIC is a 16 bit CPU, so is
memory isn't segmented.


Just as a reminder, even though the Microchip code is covered by the 
GPL, code based on it won't be acceptable for inclusion into FSF GCC 
unless you can get Microchip to sign a copyright assignment, which seems 
unlikely.  Any code in FSF GCC needs to be written by someone with a 
copyright assignment to FSF, or at least a public domain release.  (I'm 
not sure on the exact rules here.  Someone at the FSF would know exactly.)

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

[François Poulain]

If I'm right, here are copyright assignments to FSF for the Microchip's
contributions for GCC.

Best regards,

Francois Poulain

[EMAIL 
PROTECTED]/David/Install/gcc-3.3_with_PIC30_support/gcc-3.3/gcc/config/pic30 $ 
head pic30.*

==> pic30.c <==
/* Subroutines for insn output for Microchip dsPIC30.
   Copyright (C) 1994, 1995, 1996, 1997, 1998 Free Software Foundation,
Inc.
   Contributed by John Elliott ([EMAIL PROTECTED])

This file is part of GNU CC.

GNU CC is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 1, or (at your option)
any later version.

==> pic30.h <==
#ifndef _PIC30_H_
#define _PIC30_H_

/* Definitions of target machine for GNU compiler.
   Copyright (C) 1994, 95-98, 1999 Free Software Foundation, Inc.
   Contributed by Microchip.

This file is part of GNU CC.

GNU CC is free software; you can redistribute it and/or modify

==> pic30.md <==

;;- Machine description for GNU compiler
;;- Microchip dsPIC30 version.
;; Copyright (C) 1994, 1995, 1996, 1997 Free Software Foundation, Inc.

;; Contributed by John Elliott ([EMAIL PROTECTED])

;; This file is part of GNU CC.

;; GNU CC is free software; you can redistribute it and/or modify


Le dimanche 09 avril 2006 à 05:39 -0500, Aaron W. LaFramboise a écrit :
> François Poulain wrote:
> 
> > I think so. Microchip have done a modified version of GCC-3.3 with
> > DSPICs support, so we have got a heavy good base to work on the
> > instruction set, wich is similar for PIC18. DSPIC is a 16 bit CPU, so is
> > memory isn't segmented.
> 
> Just as a reminder, even though the Microchip code is covered by the 
> GPL, code based on it won't be acceptable for inclusion into FSF GCC 
> unless you can get Microchip to sign a copyright assignment, which seems 
> unlikely.  Any code in FSF GCC needs to be written by someone with a 
> copyright assignment to FSF, or at least a public domain release.  (I'm 
> not sure on the exact rules here.  Someone at the FSF would know exactly.)
> 

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

[Aaron W. LaFramboise]

François Poulain wrote:


If I'm right, here are copyright assignments to FSF for the Microchip's
contributions for GCC.


Unfortunately, this is not good enough.  A copyright assignment is a 
formal contract that must be physically signed and sent to the FSF.  See 
 for details.


Since as far as I can tell John Elliot has not attempted to include his 
changes in the official FSF GCC, it is very that he has a copyright 
assignment.  Any work based on work by him would require an assignment 
from him also--and most likely his employer, Microchip.


There is an official list somewhere of who has copyright assignments on 
file.  Alternately, whatever work he has done were thought to be 
valuable, someone could just email him and ask. :)

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

[Colm O' Flaherty]

Does anyone have any ideas about what gcc support is like for targets with 
no data stack?  The 14 bit cores (16F) mostly have a 2-8 level hardware 
stack, which is not part of the program or data memory, and is not 
addressable.  There is no data stack.


I'm hoping that there is an existing backend architecture where there is no 
stack, so that I can have a peep to see how the code fakes stack support, 
but so far, all the obvious candidates (the microcontrollers) seem to have a 
stack.


Ideas, anyone?

Colm

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

[François Poulain]

Ok I was wrong. Maybe you could contact John Elliott
([EMAIL PROTECTED]), because I 'm not an English native speaker
and I don't understand all the juridic terms. I also think that the
goodness of the question often makes the goodness of the answer.

Best regards,

Francois Poulain

Le dimanche 09 avril 2006 à 21:49 -0500, Aaron W. LaFramboise a écrit :
> François Poulain wrote:
> 
> > If I'm right, here are copyright assignments to FSF for the Microchip's
> > contributions for GCC.
> 
> Unfortunately, this is not good enough.  A copyright assignment is a 
> formal contract that must be physically signed and sent to the FSF.  See 
>  for details.
> 
> Since as far as I can tell John Elliot has not attempted to include his 
> changes in the official FSF GCC, it is very that he has a copyright 
> assignment.  Any work based on work by him would require an assignment 
> from him also--and most likely his employer, Microchip.
> 
> There is an official list somewhere of who has copyright assignments on 
> file.  Alternately, whatever work he has done were thought to be 
> valuable, someone could just email him and ask. :)
> 

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

[Rask Ingemann Lambertsen]

On Mon, Apr 10, 2006 at 07:54:24AM +, Colm O' Flaherty wrote:
> I'm hoping that there is an existing backend architecture where there is no 
> stack, so that I can have a peep to see how the code fakes stack support, 
> but so far, all the obvious candidates (the microcontrollers) seem to have 
> a stack.

The PowerPC (look in config/rs6000) has no stack.

All GCC needs is that you define a register to be the stack pointer
(STACK_POINTER_REGNUM) and this register doesn't have to be a base register
(see "Addressing modes" in the GCC Internals manual). Even a pushm1 pattern
(see "Standard Pattern Names for Generation") is not necessary if you are
happy with the code that GCC itself comes up with.

-- 
Rask Ingemann Lambertsen

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

[Colm O' Flaherty]

Happy days.. That wasn't obvious to me.  I'll check out the details later.

Thanks.

Colm


The PowerPC (look in config/rs6000) has no stack.

All GCC needs is that you define a register to be the stack pointer
(STACK_POINTER_REGNUM) and this register doesn't have to be a base register
(see "Addressing modes" in the GCC Internals manual). Even a pushm1 pattern
(see "Standard Pattern Names for Generation") is not necessary if you are
happy with the code that GCC itself comes up with.

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

[Robert Dewar]

Colm O' Flaherty wrote:

Happy days.. That wasn't obvious to me.  I'll check out the details later.


In fact many RISC chips have no specific hardware support for
a stack (MIPS is another example of such an architecture).

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

[Mike Stump]

On Apr 9, 2006, at 3:39 AM, Aaron W. LaFramboise wrote:
Just as a reminder, even though the Microchip code is covered by  
the GPL, code based on it won't be acceptable for inclusion into  
FSF GCC unless you can get Microchip to sign a copyright  
assignment, which seems unlikely.


Would seem to be easy enough to do, just, one cannot count on it.   
People that want to start from that code should open a dialogue now,  
before they start.

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

[Alan Lehotsky]

Again, the GCC3 distribution has a port of the IP2K microcontroller.

It has a hardware call stack, but the data stack is implemented  
entirely in software.


You will have to dedicate a register to act as the data-stack  
pointer.  I suppose if you limit yourself to
writing functions with NO stack-local data you might be able to keep  
the SP as a virtual register and make sure
that code generation never tries to actually use it.  You will also  
be severely limited in the ability to
pass parameters if you only allow register parameters with no  
parameter saving.


At this point, why bother writing a C compiler


On Apr 10, 2006, at 03:54, Colm O' Flaherty wrote:

Does anyone have any ideas about what gcc support is like for  
targets with no data stack?  The 14 bit cores (16F) mostly have a  
2-8 level hardware stack, which is not part of the program or data  
memory, and is not addressable.  There is no data stack.


I'm hoping that there is an existing backend architecture where  
there is no stack, so that I can have a peep to see how the code  
fakes stack support, but so far, all the obvious candidates (the  
microcontrollers) seem to have a stack.


Ideas, anyone?

Colm

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

[Colm O' Flaherty]

I'm not dependent on it, although at some point, I'm sure i may take a 
closer look at the code to see how they've done certain things.


Just as a reminder, even though the Microchip code is covered by the GPL, 
code based on it >>won't be acceptable for inclusion into FSF GCC unless 
you can get Microchip to sign a copyright >>assignment, which seems 
unlikely.


Would seem to be easy enough to do, just, one cannot count on it. People 
that want to start >from that code should open a dialogue now, before they 
start.

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

[Colm O' Flaherty]

I'm not quite sure I follow you.. if its possible to dedicate a register to 
act as the data-stack pointer, and implement it that way, why would I want 
to "keep the SP as a virtual register"?  I'm not being antagonistic when I 
say that.. I'm just trying to understand what you're trying to tell me..


Will check out the ip2k port again.. the last time I looked, I was blinded 
by the assumption that if the usual stack macros were defined in a 
straightforward fashion, that the target actually supported (or implemented) 
a stack... "It ain't necessarily so".



you might be able to keep the SP as a virtual register and make sure
that code generation never tries to actually use it

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

[Dave Korn]

On 11 April 2006 08:47, Colm O' Flaherty wrote:

> I'm not quite sure I follow you.. if its possible to dedicate a register to
> act as the data-stack pointer, and implement it that way, why would I want
> to "keep the SP as a virtual register"?  

  Because then you would /not/ have to sacrifice one of your precious limited
supply of registers to act as a real hard stack pointer and it would be used
as a general purpose register instead and allow better code generatation and
less spilling when the register pressure gets high.


cheers,
  DaveK
-- 
Can't think of a witty .sigline today

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

[Alan Lehotsky]

On Apr 11, 2006, at 03:46, Colm O' Flaherty wrote:

I'm not quite sure I follow you.. if its possible to dedicate a  
register to act as the data-stack pointer, and implement it that  
way, why would I want to "keep the SP as a virtual register"?  I'm  
not being antagonistic when I say that.. I'm just trying to  
understand what you're trying to tell me..


Sorry, thought you were indicating that you didn't WANT a data  
stack :-)  Now I understand that your chip

just doesn't provide hardware support for stacks.

BTW, another port I did (to a RISCy architecture that was the core  
for a high-speed multiprotocol router
(never submitted to the FSF and the company's now belly-up) provides  
a "lower bound" on how simple an

addressing scheme you can deal with.

This machine had 512 directly addressable memory locations and 4  
registers that could be indirected thru
(kinda like the way the PDP-8 worked).  With 3 registers available  
for reload (1 was reserved for the SP),
you could pretty much compile all the GCC test suite that didn't need  
more than 512 words of memory.

[Oh, BTW,  chars were 32 bits on this machine also]




Will check out the ip2k port again.. the last time I looked, I was  
blinded by the assumption that if the usual stack macros were  
defined in a straightforward fashion, that the target actually  
supported (or implemented) a stack... "It ain't necessarily so".



you might be able to keep the SP as a virtual register and make sure
that code generation never tries to actually use it

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

[Aaron W. LaFramboise]

I send a message to John Elliott's listed address yesterday, and I have 
not yet received an immediate response.  I will post to this list if I 
receive anything from him.


So, I'd caution anyone away from basing any work on the dsPIC port until 
some specific understanding is established with Microchip--if you want 
it to be included in FSF GCC.

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

[François Poulain]

Hello,

Le lundi 06 mars 2006 à 13:39 +, Colm O' Flaherty a écrit :
> Francois,
> 
> I'm really interested in getting a gcc port (gcc backend) for the Microchip 
> PIC16F family (14 bit instruction, 8 bit word) up and running.  I've seen 
> various mails to the gcc list that refer to this, the most recent being from 
> you.
It a good question. I think 18F is clearly C-oriented architecture,
whereas coding C on 16F is not very efficient. In the other hand, 16F is
quite simple,it could be a good example, and I better know 16F assembly
than 18F assembly (I always coded 18F in C).
> 
> Can you summarise the current status of your port, or any other active gcc 
> PIC ports that you are aware of?
For the moment, I am only studying internal gcc documentation. I will be
quite busy until june month, so I don't planned anything for the moment.

About this subject, if a french people know well gcc machine descriptor
language, I am interessed in being mailled by him, to learn more about
that.
> 
> There is an existing open-source C compiler with PIC support (SDCC) that 
> I've used, but my experience with this is that it isn't as scalable as I 
> would like (particularly for device support), whereas gcc is a well known 
> compiler with a solid code base, great platform support, and comes with 
> pretty much every Linux distribution I've ever seen.
I think so.
> 
> Am I mistaken in thinking that if we got a gcc PIC backend up and running, 
> that we would be able to code for PICs in C, C++, Fortran, Ada, and Java 
> (subject to memory limitations, etc)???  Thats a dream...
I think so, and it's also the dream of a friend. Really, gcc seems have
a different behaviour for C-C++ and the others. I can't tell more about
that subject, and as far I am concerned, I don't have the competences
and the will to use Java on Pic.
> 
> Colm O' Flaherty

Francois Poulain

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

[François Poulain]

> 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 +, 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

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

[Gabriele Caracausi]

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 +, 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

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

[Julian Niño]

see:
SDCC compiler for small devices.
http://sdcc.sourceforge.net/
This perhaps is a first point for begin this

Julian Niño

- Original Message -
From: "Gabriele Caracausi" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, March 08, 2006 12:31 PM
Subject: RE: GCC Port (gcc backend) for Microchip PICMicro microcontroller


> 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 +, 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
>
>

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

[François Poulain]

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 +, 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
> 

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

[Mike Stump]

On Mar 13, 2006, at 5:29 AM, Colm O' Flaherty wrote:
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"?


If 100% of the ports produce assemble files, then, you'll want to  
produce assembly files.  100% of the ports produce assembly.


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!


Nope.


The issue here is that that gcc would then become "bound" to gputils,


Not a problem, though, we'd prefer that you did up a binutils port as  
well.  The reason is that those utilities have a certain feature set  
that other tools don't have, and that feature set is used and it  
useful to the compiler and users.


Also, it is possible to do up a port first to gputils and then later  
to enhance it to target binutils, while retaining the ability to  
still target gputils, if people find that interesting.


The real issue here, for me, is the level of duplication / overlap  
with the SDCC project.


Don't worry, they can come join us and stop duplicating our work  
after you get a port going.

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

[Colm O' Flaherty]

Ok, so the mist is clearing.  We produce assembly, including directives, 
etc, and target gputils initially (because it exists, and it works), and 
then later, do a port for binutils.


Is there anyone thats familiar with any of the other microcontroller ports 
like the AVR port, so that we can try learn from mistakes there, and gain 
some experience?



From: Mike Stump <[EMAIL PROTECTED]>
To: "Colm O' Flaherty" <[EMAIL PROTECTED]>
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]

Subject: Re: GCC Port (gcc backend) for Microchip PICMicro microcontroller
Date: Mon, 13 Mar 2006 11:16:38 -0800

On Mar 13, 2006, at 5:29 AM, Colm O' Flaherty wrote:
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"?


If 100% of the ports produce assemble files, then, you'll want to  produce 
assembly files.  100% of the ports produce assembly.


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!


Nope.


The issue here is that that gcc would then become "bound" to gputils,


Not a problem, though, we'd prefer that you did up a binutils port as  
well.  The reason is that those utilities have a certain feature set  that 
other tools don't have, and that feature set is used and it  useful to the 
compiler and users.


Also, it is possible to do up a port first to gputils and then later  to 
enhance it to target binutils, while retaining the ability to  still target 
gputils, if people find that interesting.


The real issue here, for me, is the level of duplication / overlap  with 
the SDCC project.


Don't worry, they can come join us and stop duplicating our work  after you 
get a port going.

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

[Lucas (a.k.a T-Bird or bsdfan3)]

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 +, 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
>

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

[Colm O' Flaherty]

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 +, 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
>

CC Lists [was Re: GCC Port (gcc backend) for Microchip PICMicro microcontroller]

[DJ Delorie]

> (And who are all of the people in the CC list?  Is there some other
> list discussing this?)

We were randomly CC'd in the initial spew of emails, although I
personally am already on the gcc list, so CC'ing me on this only
serves to mess up my procmail filters.  I've asked privately to be
removed from the CC list, but I guess that wasn't enough, so here's a
public request.

So just to be clear - I am not interested, in any way, in any effort
to port GCC to any Microchip product.  Nothing personal, I just have
enough on my plate already with my existing ports.  Thus, I do not
wish to be personally CC'd on any discussion to those ends.  My
procmail filters will notify me of any mention of my other projects.

Thanks
DJ