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.
