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
- From: "Maciej W. Rozycki" <macro at ds2 dot pg dot gda dot pl>
- To: Richard Sandiford <rsandifo at redhat dot com>
- Cc: Thiemo Seufer <ica2_ts at csv dot ica dot uni-stuttgart dot de>, gcc-patches at gcc dot gnu dot org, binutils at sources dot redhat dot com
- Date: Tue, 16 Jul 2002 11:41:10 +0200 (MET DST)
- Subject: Re: RFC & patch: Rework MIPS command-line handling
- Organization: Technical University of Gdansk
- Reply-to: "Maciej W. Rozycki" <macro at ds2 dot pg dot gda dot pl>
On 15 Jul 2002, Richard Sandiford wrote:
> > 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...
There is no need, either, as there are "-march=mips1", etc. equivalents,
and specifying "-march=3000 -march=mips2" is obviously incorrect for
anyone, while "-march=3000 -mips2" isn't that obvious, even though it has
the same meaning.
> > 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, but if it's related to...
Well, the o32 ABI explicitly states only MIPS1 instructions (which MIPS32
is a superset of) are allowed. But for practical reasons it's useful to
assume an ABI only specifies the register allocation, the calling
convention and addressing, leaving the instruction set used to be handled
by the execution environment. The set is more or less reported in the ELF
header anyway.
> > This would mean the User can use
> >
> > gcc -mabi=32
> >
> > and then he gets code which might _not_ run on o32 conformant
> > Systems. This defeats the idea of having an ABI.
>
> It sounds like you're saying that, because the original o32 systems were
> MIPS I only, -mabi=32 should mean "generate MIPS I code" unless the user
> says otherwise. That's the current behaviour, but like I said above,
> it seems strange to pick MIPS I regardless of the default processor.
The confusion is a result of binding two unrelated properties together,
i.e. the instruction set and the code conventions. Maybe the solution is
adding another option to specify the conventions only? But is it really
desireable?
Maciej
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +