Does -march=r5000 imply HAVE_64BIT_GPRS?

[Eric Christopher]

> I'm waiting for his intervention. :-)
> 

Here we go:

> > so one thing that i don't get, from all of these discussions and
> > patches is, why _are_ we still maintaining the notion of 'isa' as
> > separate from 'architecture' in the code?
> 
> Well, it's because of historic reasons I assume. Gas mimics the
> native MIPS (SGI) assembler which uses -mipsN and -{32,n32,64} to
> decide about ABI and cpu type in a rather opaque manner.
> With the myriads of embedded cpu's this wasn't viable any more, so
> -mcpu was invented and lately split up in -march and -mtune.
> Now we sit in the mess and have to support a compiler which has
> only -mcpu=FOO ATM.
> 

Only ATM. The current trunk has it split up into -march and -mtune.
-mcpu and -m<foo> is still valid, but deprecated (and in the case of
-m<foo> worked around via specs files).

> > If the desire with these flags was to move in the direction of the way
> > arch/cpu selection is done for other architectures (in the compiler
> > and assembler), shouldn't -mips1 become a synonym for "-march=mips1"?
> 
> It currently is a synonym for -march=r3000 if invoked correctly.
> Introducing a generic arch for the old ISA's would be cleaner but
> isn't really needed IMHO. My latest patch cares about "incorrect"
> invocation as it might be done by GCC 3.0.
> 

Right...

> > If you're going there, with switches like:
> > 
> > 	-mips1 -march=FOO
> > 
> > -mips1 is irrelevant, completely overridden by -march=FOO.
> 
> That's the way it should be IMHO. When -mcpu gets deprecated, we can
> get there and drop the ISA-dependent handling in gas. We could even
> remove -mipsN as redundant, and hopefully also -{32,64}. My idea of
> these options is:
> 
> 	-arch=FOO	allowed insns, max register widths
> 	-tune=FOO	scheduling
> 	-mabi=BAR	ABI to conform to
> 	-m[fg]p=32	non-ABI-conformant register width reduction
> 
> Is command line compatibility to other assemblers an issue?

Not that I know of - though I'd prefer if Ian were to speak up here and
let me know if it is the case.

Personally I agree with this assessment - though we should keep the
-mipsX options for compatability. They can simply be aliases like I'd
planned all along though. R3000, R4000, R5000, R8000 I believe (he says
without looking...)?

Oh yes, your patch is approved as well.

-eric

-- 
Look out behind you!