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

[Thiemo Seufer <ica2_ts at csv dot ica dot uni-stuttgart dot de>]

cgd@broadcom.com wrote:
[snip]
> > > 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?
> 
> I have never actually seen a complete and canonical MIPS ISA
> definition pre-dating MIPS32/MIPS64.

I have
"MIPS IV Instruction Set, Revision 3.2, By Charles Price, September 1995"
which fits well together with
"MIPS R10000 Microprocessor User's Manual"

The CP0, TLB, CACHE and ERET instructions are covered in the latter
as being CPU specific.

> > > 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.
> > 
> > 	gcc -mabi=FOO
> > 
> > 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.
> 
> Since I'm a bit behind on this discussion, I'll just have to risk
> reiterating points already made in response to your msg by others:
> 
> That may be appropriate for "mips-linux" tools.

That's what I'm actually caring about. :-)

> It's probably not appropriate for "mipsisa32-linux" tools, since
> somebody configured the tools naming a specific architecture that they
> wanted to build for by default.

AFAICS this toolchain will have EABI(32) and MIPS32 as defaults.
This won't interfere with what I wrote.


Thiemo