This is the mail archive of the
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 <email@example.com> 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
> I do think it's reasonable and probably desirable to support (can you
> hear the maniacal laughing, too?):
> (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-)
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.
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.