Re: RFC & patch: Rework MIPS command-line handling

[Thiemo Seufer <ica2_ts at csv dot ica dot uni-stuttgart dot de>]

cgd@broadcom.com wrote:
> At Mon, 15 Jul 2002 10:13:47 +0000 (UTC), "Richard Sandiford" wrote:
> > Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de> writes:
> > > I agree, -mipsN should be an alias for the equivalent -march=FOO.
> > > Please note that the -mipsN options should IMHO be obsoleted:
> > >
> > > 	- They are asymmetric because all of them can be replaced by
> > > 	  -march=FOO, but there are -march=FOO without -mipsN equivalents
> > 
> > I'd guess the ISA levels are more well known than the processors we're
> > associating them with, so there's probably no harm in keeping them as
> > aliases, but...
> 
> I actually think it's important to keep them.  In general, it's
> quite desriable to be able to say, for instance:
> 
> "will run on any MIPS N CPU, but optimized for this particular CPU."
> 
> where, say, N == 1.  historically, the first part of that has been
> caused by -mips1 (for N == 1),

Unfortunately, it has not. For GCC there's not much difference, but
GAS allows the default CPUs specific opcodes, too.

> and people I think have come to expect
> that.
> 
> I do think it's reasonable and probably desirable to support (can you
> hear the maniacal laughing, too?):
> 
> 	-march=mips1
> 
> (in the NWO would that be mipsisa1. 8-)

Seconded. :-)

> > > 	- As CPU aliases they can allow opcodes which aren't available
> > > 	  on other ISA-conforming CPUs.
> > 
> > Not sure what you mean.  Do you have any examples?
> 
> If the CPU aliases for the ISA aren't the minimal set for the ISA,
> that sounds like a very good reason for somebody to go off and do
> something better, i.e., create "actual ISA" definitions.
> 
> I believe that at least mipsisa32 and mipsisa64 -- ISAs which are
> really ISAs in the code, rather than being CPUs -- are correct.  8-)

Are the CP0 and TLB instructions really covered by the ISA there?

> > > Strictly speaking, MIPS 32 code isn't conforming to o32 ABI.
> > > The same should be true for MIPS IV opcodes in n32 code.
> > 
> > Hmm... not sure why,
> 
> Because the o32 ABI specification was defined as MIPS I only.
> I.e., MIPS I instructions only and EF_MIPS_ARCH == 0.
> 
> It's a definitional thing.  8-)
> 
> The notion that a bunch of us like more is something like: "ABI means
> file format, calling conventions, etc.  Orthogonal to that is the ISA
> level, and the ISA level is easy to check via EF_MIPS_ARCH."

It's not truely orthogonal because there's a minimal required ISA
for some ABIs.

> I think
> that's a much more useful way to think about things given the plethora
> of ISAs.

>From a ABI POV there aren't many: MIPS I and MIPS III.

> And, in that view, -mabi=foo probably shouldn't change the ISA (and
> definitely shouldn't downgrade it).

My idea is to get sane defaults from the ABI definition.

	gcc -mabi=FOO

should create ABI conformant code, while

	gcc -mabi=FOO -march=BAR

loosens the ABI restrictions in order to allow BAR opcodes.
AFAICS this fulfils the "least surprise" priciple for hosted
systems, and the embedded world can live with it, too.


Thiemo