This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: RFC & patch: Rework MIPS command-line handling
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