Re: GCC Port (gcc backend) for Microchip PICMicro microcontroller
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
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 >
Re: GCC Port (gcc backend) for Microchip PICMicro microcontroller
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
Microchip GNU-CC PIC port - script licencing question..
Theres an interesting discussion going on as to whether Microchip Inc is allowed by the GPL to licence linker scripts and some other scripts (their code, not based on a GPL'ed code) when these scripts are all distributed as part of the MPLAB C30, which is a C compiler, based on the GNU CC (gcc) 3.3, which obviously *is* covered by the GPL. Can someone knowledgeable cut to the chase and put us right on what the situation is in this case? How about Richard Stallman? Is he available? (Just kidding, but it would be nice to hear from the man himself). http://www.linuxhacker.org/cgi-bin/ezmlm-cgi/1 Thanks, Colm
Re: GCC Port (gcc backend) for Microchip PICMicro microcontroller
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
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
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
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
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
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
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: Summer of Code 2006
How about a pull-together of all the existing docs on how to create a new front-end / back-end.. stuff like whats in the gcc internals doc, and Stallman's "Using and porting gcc".. maybe update it all in a single place for ver 4.x, and update for the undocumented / obsolete macros? It's not strictly coding, I know, but in many ways, it might actually be a more important (and higher level) project than one strictly involving coding, as it would clear up loose ends, and facilitate the expansion of gcc into other languages / targets. The students that took the project on would gain a detailed knowledge of the structure of gcc itself, and would gain kudos for their efforts. It would be a serious help to people trying to develop new front ends or back ends for gcc (like me!).
PIC14 port: GO_IF_LEGITIMATE_ADDRESS
Can anyone point me at a good existing implementation of GO_IF_LEGITIMATE_ADDRESS, suitable for a microcontroller with banked (segmented) 8 bit registers?
