This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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


+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+        e-mail:, PGP key available        +

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]