Re: GAS: Handling option parsing for ARM co-processor extensions

[Richard Earnshaw <rearnsha at arm dot com>]

> On Tue, 2002-01-15 at 12:12, Richard Earnshaw wrote:
> > Well, not really, since AFAICT from the Cirrus web pages, Maverick is just 
> > a co-processor extension on a CPU.  There's nothing much to tie it to a 
> > particular processor, so using -mmaverick to imply a particular CPU looses 
> > flexibility.
> 
> Um, yeah, I didn't make that very clear.  I meant that you would end up
> with "-marmv4 -mmaverick" or something like that, along the lines of the
> "-marmv3 -mfpa10" that we have now.  XScale was a dumb thing to pick as
> an example.

I don't like that, for one because, as I said to Lars, you have to parse 
the entire command line before you can know that you have a valid 
combination of flags.  Plus, how do you turn Maverick off if that is one 
of the default flags set up for a build?  The only reasonable way is to 
start adding -mno-maverick etc, which becomes clumsy.  IMO, selecting the 
instruction set to assemble for should be just one flag that allows you to 
fully describe what you want: -m<base-cpu>+<option> allows for that.

>  
> > Incidentally, I'm a bit concerned about -mxscale as a processor.  From the 
> > documents I've read XScale seems to be more of a specification for an 
> > architecture than a single implementation.
> 
> Yes, I think that's right.  I'm not sure that the distinction is
> particularly important right now, though.

Hm, except that when it does become important there will be a much larger 
user base, so the resistance to change will become greater.  However, I'm 
not sure what I would rename it to...

R.