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

[cgd at broadcom dot com]

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), 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-)


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



> > 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."  I think
that's a much more useful way to think about things given the plethora
of ISAs.

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



cgd