This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: GAS: Handling option parsing for ARM co-processor extensions
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Nick Clifton <nickc at cambridge dot redhat dot com>, binutils at sources dot redhat dot com
- Cc: Richard dot Earnshaw at arm dot com
- Date: Tue, 15 Jan 2002 14:16:40 +0000
- Subject: Re: GAS: Handling option parsing for ARM co-processor extensions
- Organization: ARM Ltd.
- Reply-to: Richard dot Earnshaw at arm dot com
> I have been wondering whether it would be better to accept any
> coporcessor instruction by default and disable their assembly only if
> explicitly requested on the command line. Of course this assumes that
> there are no ambiguities between different coprocessor instruction
> sets. But it is in keeping with assembler's current default of
> accepting any normal ARM instruction and only restricting the assembly
> of v4 or v5 instructions if a cpu is specified on the command line and
> it does not support these instructions.
Long term, I think this will be making more problems for us. I foresee
more and more co-processors being added to ARM chips in the future and
there are bound to be incompatibilities before too long. It's one thing
to accept all the basic ARM instructions, since these are always added in
a way that avoids overlap. But co-processors are added by independent
companies who are not working together, so there is no reason to expect
that their extensions will be orthogonal, even in the mnemonic namespace.
My inclination in this area is that -mall should mean "any ARM core" but
not imply any extensions to in the co-processor space. That would, at
least, keep the option vendor neutral.
> Anyway as the the command line options I believe that we should keep
> the current set of options for backwards compatibility.
IMO -marm9e for maverick must go. It's just plain wrong. Since there
hasn't been a release since this was added, I see no reason to keep that.
You will recall that I objected to this at the time the patch to add
maverick support was proposed.
> However your
> proposal for handling different ISAs and extensions seems reasonable
> to me, so I would accept it.
OK, I'll work on a patch.
R.