This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: EP9312, Maverick Crunch fixes
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Petko Manolov <petkan at nucleusys dot com>
- Cc: Nick Clifton <nickc at redhat dot com>, binutils at sources dot redhat dot com, Richard Earnshaw <rearnsha at arm dot com>
- Date: Wed, 25 Feb 2004 15:28:23 +0000
- Subject: Re: EP9312, Maverick Crunch fixes
- Organization: ARM Ltd.
- Reply-to: Richard Earnshaw <rearnsha at arm dot com>
> Hi Nick,
>
> In binutils-2.14/gas/config/tc-arm.c line 10227 says:
>
> if (cpu_variant & ARM_CEXT_MAVERICK)
>
> At some point this has been (same file, line 11718) changed to:
>
> if (cpu_variant & FPU_ARCH_MAVERICK)
>
> In the first case when you invoke gas with "-mcpu=ep9312" it'll add
> "Maverick float format" flag to the resulting .o file. In the latter it
> won't.
>
> Since ep9312 does have Maverick Crunch coprocessor i would think passing
> "-mcpu=ep9312" should be sufficient to set this flag. The good effect is
> that running gcc with this switch will end up generating an object file
> with "Maverick float format".
>
> I wonder if we should change the code to:
>
> if (cpu_variant & (FPU_ARCH_MAVERICK | ARM_CEXT_MAVERICK))
>
> This way both "-mcpu=ep9312" and "-Wa,-mfpu=maverick" (from gcc
> point of view) will do the same thing. However, i am not sure if this
> will break some gas/gcc convention(s) i don't know about.
I need to think through this case carefully before I reach a final
conclusion, but my initial reaction is no, I don't think so.
The reason for trying to split up the floating point from the cpu option
is that -mcpu must not change the ABI used by the compiler (it can change
the instructions available to use, but not the layout of data).
Regrettably, because the FPA uses a different floating point word order
from the VFP and Maverick the -mfpu option must have some effect on the
ABI, hence the split. Consider the case where Linux (or some other OS is
being used on the ep9312 -- it should still use the same ABI as other ARM
boards so that you can take a generic ARM/<some-os> application and run it
on your machine.
I'll give this some more careful thought.
R.