This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
RE: Porting gcc
- From: "Dave Korn" <dk at artimi dot com>
- To: <gcc at gcc dot gnu dot org>
- Date: Fri, 21 May 2004 14:43:13 +0100
- Subject: RE: Porting gcc
> -----Original Message-----
> From: gcc-owner On Behalf Of Mile Davidovic
> Sent: 21 May 2004 14:02
> I have questions regarding support new MIPS based processor,
> MDE950xx. In the
> basic it is same as R3000 but except one thing, this
> processor does not support
> lwl and lwr instructions, what is best way to support this "feature"?
The MIPS port already supports multiple cpu types; you'd just need to
extend what's already there. Look at gcc/config/mips/mips.h; you'd need to
add a new element to the enum processor_type (taking care to keep it
matching up with the definition of the cpu attribute in mips.md); you'd also
define corresponding TARGET_MIPSxxx and TUNE_MIPSxxx definitions.
Further down mips.h you'll see loads of feature-test macros called
ISA_HAS_xxxxx, which are used to test which instructions do or don't exist
on various mips versions; you could define one called ISA_HAS_LWLR for
instance. Then you could use that macro as a feature test in the insn
patterns in mips.md that use those instructions.
Not being familiar with the mips port myself, that's the most advice I can
give you. You'll have to familiarise yourself well enough with the mips
backend to be sure whether or not there were any other things you had to
keep consistent or extend to know about the new cpu type. Maybe some of the
specs, for instance. And mips.c has a structure called mips_cpu_info_table
which you'd need to add an entry to. Finding the remaining stuff you'd need
to implement is up to you.
> We want to use latest gcc version, 3.4. What is necessary
> steps for porting gcc?
Like I say, you don't need to port it; just modify the existing port.
> If we have success to support what is best way to add patches to gcc?
Check out a copy of gcc from the gnu CVS server; you would want to use the
3.4 branch rather than work against the head. Develop your modifications,
test them, ensure the compiler passes the testsuite with no regressions, use
"cvs diff" to generate a patch and send it to the gcc-patches list. Pretty
much exactly what it says at http://gcc.gnu.org/contribute.html really!
cheers,
DaveK
--
Can't think of a witty .sigline today....