This is the mail archive of the
mailing list for the GCC project.
Re: Patches for coldfire v4e
- From: Bernardo Innocenti <bernie at develer dot com>
- To: arcjai at yahoo dot com
- Cc: gcc-patches at gcc dot gnu dot org, gcc at gcc dot gnu dot org, peter at the-baradas dot com, Jaiprakash C <cjaiprakash at noida dot hcltech dot com>
- Date: Wed, 13 Apr 2005 10:10:39 +0200
- Subject: Re: Patches for coldfire v4e
- References: <firstname.lastname@example.org>
>> - You don't seem to consistently patch both
>>MOTOROLA and !MOTOROLA paths.
>> Is this intentional? AFAIK, there are no
>> ColdFire targets using the MIT syntax,
>> but we need to be consistent;
> I think it is only for the new patterns that these
> paths are not followed. Do you want me to change them
> as well?
Since it noticeably increases the complexity of the
m68k backend, I personally believe the MIT syntax
should go away as soon as m68k-openbsd moves on to
a version of GAS released in this decade.
However, letting MOTOROLA and MIT code diverge makes
it hard to understand what the code is supposed to
do, so we should keep them in sync as much as
>>What are the changes you need to apply?
>>Would plain 68020 code run on v4e processor? As far
>>as I can see, m68k-linux isn't a multilib target.
> Problem occurs mainly due to restricted addressing
> modes in v4e. For ex v4e supports only 16-bit
> displacements. So all crt* files needs to be build for
> v4e. Also v4e does not have extended floating point
> instructions (XF mode) so we may have to modify t-*
> for fpgnulib.c.
So it seems adding coldfire-linux is the only way
to address this...
I'm afraid you'll also have to patch binutils, gdb,
newlib and libstdc++ to get "coldfire-" to mean the
same of "m68k-".
Before you go on, you'll need to submit a new target
tuple to the config project:
Once it's done, let me know and I'll import the new
version in GCC.
I'm sorry it can't be made simpler than this.
// Bernardo Innocenti - Develer S.r.l., R&D dept.