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

["Mark D. Baushke" <mdb at gnu dot org>]

"Maciej W. Rozycki" <macro@ds2.pg.gda.pl> writes:
> On 15 Jul 2002, Richard Sandiford wrote:
> 
> > It might also be nice to have a --with-abi configure option,
> > although that's something we could add later...
> 
>  I'm not sure that is desireable -- I think the default ABI would best be
> selectable with the target triple.  Like with "mips64abin32-*-*" or so.

Having an unambiguous default ABI is desirable. If the name of the
compiler is mips64-elf-gcc or mipsisa32-elf-gcc, then there should only
be one ABI that defaults for each of those and it should not depend on
how the toolchain was configured and built. Otherwise, users might need
to always specify the ABI they want to use for every compile and that
would be tedious and prone to errors.

> > The main difficulty with dropping the ABI selection entirely
> > is: how do you select between the 32-bit and 64-bit versions
> > of the EABIs?  mipstx39-elf-gcc generates 32-bit EABI code
> > by default.  What happens if you select a 64-bit processor?
> > Options I can see:
> > 
> > 1. Stick with the idea in the patch I sent.  Selecting a 64-bit
> >    processor would usually select the 64-bit EABI, but adding
> >    -mgp32 forces the 32-bit version.
> > 
> > 2. Reverse of (1).  You get the 32-bit version of the EABI
> >    unless you use -mgp64.
> > 
> > 3. Add eabi32, eabi64, meabi32 and meabi64 to -mabi.  You get
> >    the 32-bit version unless you use -mabi=eabi64.
> 
>  The last option seems the cleanest to me.  With your changes, it would
> permit selecting a default ABI when configuring for certain embedded
> targets as well (though I'm not sure how useful it would be in practice at
> the moment, since I am not an embedded user).

Speaking as an embedded user, any of the three options work. The first
one has the advantage of working even if you happen to have an old
version of the toolchain around by accident.

For the above choices, my order of preference would be: (3), (2), (1).
However, I think there needs to be at least one release that serves as
a transitional introduction if (3) is chosen.

Richard Sandiford <rsandifo@redhat.com> writes:
> 
> Eric Christopher <echristo@redhat.com> writes:
> > > > I took my cue from R3000 and R4000, which were the standard before.
> > > 
> > > So, historically, those defines _seem_ to be used less as 'processor'
> > > defines and more as 'GPR size' defines, at least looking at the way
> > > GCC defined them in say 3.0.x.
> > 
> > It was annoying too. There _were_ preprocessor directives for mips and
> > mips64.. anyhow
> 
> Ugh.  Ok, I'll keep _R3000 & _R4000 as they are now, and add the
> _MIPS_ARCH and _MIPS_TUNE that Chris suggested.

That is good news.

> Question: if gcc treats two processors as the same for scheduling,
> should they have the same _MIPS_ARCH and _MIPS_TUNE value?  Like,
> should -march=r2000 and -march=r3000 set _MIPS_ARCH to the same
> value (_MIPS_R3000?) to reflect what GCC's doing, or should there
> be separate _MIPS_R2000 and _MIPS_R3000 defines?  How about
> -mtune= and _MIPS_TUNE?

A ask a hard question...

I would have no significant problems with _MIPS_R2000 and _MIPS_R3000
using the same value rather than being independent if that were necessary.

However, I think that if both symbols need to exist, it might be useful
to have distinct values for them if possible.

With regard to strictness of the ABI, be advised that kernel code may
sometimes need to pragmatically run using o32 mode but still have access
to cache and other non-conformant ISA instructions... For example, for
space reasons in the embedded world, it is often the case that the
kernel will want to be run in -mips2 mode adding what cpu cache
instructions are required, but otherwise able to use exactly the same
library code as is being used by non-privileged user code.

	-- Mark