Does -march=r5000 imply HAVE_64BIT_GPRS?

[Thiemo Seufer]

cgd@broadcom.com wrote:
> It would probably be good if Eric spoke up about his intentions
> here...  8-)

I'm waiting for his intervention. :-)

> 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.

> 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.

> 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?


Thiemo