GAS: Handling option parsing for ARM co-processor extensions

[Richard Earnshaw]

> 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.