binutils patches for Cirrus/arm9e/maverick support
Richard Earnshaw
rearnsha@arm.com
Wed Oct 10 09:50:00 GMT 2001
> 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".
More information about the Binutils
mailing list