Re: binutils patches for Cirrus/arm9e/maverick support

[Richard Earnshaw <rearnsha at arm dot com>]

> Hi Guys,
> 
> > > It can't be just "maverick" because maverick is no one chip.
> > 
> > But then, nor is "arm", nor is "strongarm" and nor, probably, is
> > "xscale",  yet all three are accepted as cpu names.
> 
> Right, so maybe we ought to accept the generic name in binutils and
> the specific cpu variants in gcc.

Indeed.  Generally the assembler is configured to be fairly permissive by 
default (accepting almost all valid opcodes by default); it only becomes 
restrictive if a command-line option to select a processor is given.

This will have to change slightly when I am ready to release the VFP 
support code, since the selection of target FPU can affect the meaning of 
the .double directive.

In terms of what operations should be accepted by default, then I think 
that with the possible exception of standardized floating-point 
instructions, we should generally reject co-processor extension opcodes 
unless explicitly enabled either during configure or on the command line.

> > If you're going to insist on a particular name, then perhaps it
> > should be EP9312, but how many people are going to know what that
> > is...?
> 
> Plus there is also the EP7312, the CL-PS7500FE, the EP7212, the EP7211
> and the EP7209...

Indeed, though as has been pointed out, these don't extend the instruction 
set as far as I am aware (the cl-ps7500fe is, in effect an arm7500fe part, 
so has an FPA macrocell).  Generally, I'd be against making gas aware of 
every chip name that contains an ARM core of some form -- the list would 
extend to hundereds; even the list of ASSPs would probably be too much.

R.

PS, If I've read the information on the Cirrus web-site correctly, it 
would appear that the co-processor extensions are known as 
"MaverickCrunch".