Re: mutex in frame code

[Richard Earnshaw <rearnsha at arm dot com>]

> 
> > and that these three options be documented machine independently 
> > (specific values of course will be machine dependent).
> 
> I agree with the idea of working towards having all the ports
> have similar meanings for the -mcpu, -mtune, and -march flags,
> but I disagree with the idea of documenting these flags as if
> they were machine independent.  There may be good reason for
> a particular port to have a different meaning for these options,
> either for the time being, or permanantly.  Documenting these
> options as machine independent either forces port maintainers
> to follow the documented behavior even when it doesnt make sense
> for a paticular port, or it means that the doc isn't correct 
> for all ports.  Leaving the exact meaning of these options
> machine dependent, while encouraging ports to follow the overall
> standard, gives port maintainers the freedom to make the right
> decision for a paticular port.
> 

I can't think of anything worse than -mcpu= meaning one thing when 
compiling on MIPS and a completely different thing when compiling on 
SPARC.  I'm in favour of unifying the definition (and of using the 3 
options proposed).

> If you really want machine independent options for these things,
> and I'm not opposed to such a thing, then you should actually 
> create some machine independent options (say --tune=, --arch=, 
> and --cpu=) in the usual way.
> 

I've no problem with this, but if we go this way, I think we need to 
completely expunge the -m{cpu,tune,arch} options immediately.   Some of 
the ARM ports SPEC flags are complicated enough, without having to support 
two sets of options which mean the same thing.

Richard.