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

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

Richard Sandiford wrote:
[snip]
> > I don't see a good reason to mix ISA and ABI selection. AFAICS it's
> > enough to
> > 
> > 	- choose the lowest ISA required for a selected ABI
> > 
> > 	- use the 'highest' ABI for any selected ISA
> 
> I'm not sure what you mean by "mix" here.  Anyway, I don't think
> it's a good idea to select the lowest ISA for an ABI.  If you have
> a configuration that uses a particular CPU by default (let's say a
> MIPS II one), specifying an ABI shouldn't "downgrade" to MIPS I.

If you are caring about particular processor features you aren't
using an ABI.

> If someone's using a MIPS II or higher toolchain to generate code
> that must run on a MIPS I machine, it doesn't seem unreasonable
> to ask them to say so explicitly.

There seems to be some misconception about the term 'ABI', maybe
because the current -mabi=FOO option basically means "select calling
conventions and register sizes". But an ABI is a much more powerful
concept than pushing a few compiler options. It defines a platform
over a variety of hardware which allows to run the same binary code.

In fact, all other compiler options we discussed here are already
defined by the ABI if there is one in use. So guessing an ABI from
other compiler options just means doing things backwards. From an
ABI POV, these compiler options will either have no effect or they
will break ABI conformance.

> > GCC and GAS have different requirements: For GCC it's sensible to guess
> > ISA from ABI and vice versa because it usually handles ABI-conforming
> > code. For GAS, the ABI selection is not that useful because assembly
> > normally isn't ABI-conformant (which would be limited to opcodes covered
> > in the respective ISA).
> 
> I agree that might be true for embedded configs.  But like Maciej
> said, it could be useful to have a default ABI for hosted toolchains
> like mips64-linux-gnu.  It seems reasonable that anyone using such
> an assembler would be at least try to write ABI-conformant code.

I don't know about embedded configs. Just have a look at the linux
kernel. I claim it has nearly no assembly code which could be written
in an ABI-conformant way, with few performance improvements in assembly
as an exception.

Having a default ABI is IMHO a good thing in any case: For userland
code the ABI conformance is essential, and for kernels/embedded configs
the ABI can provide the default settings which may get overridden then.

> So the way the GAS config stuff is structured, it will assume NO_ABI
> by default, since that seems sensible for most embedded configs,
> and won't lead to spurious "incompatible ABI" link failures.

Spurious? With some likeliness these are real incompatibilities.

> Not setting EF_MIPS_ABI is also the historical behaviour.
> There's then the option of overriding the NO_ABI default for
> particular configurations.
> 
> > >     For example, if "mips64-elf-gcc -mips1" chooses o32 code
> > >     (as it does now) then "mips64-elf-gcc -march=r3000" should do the same.
> > 
> > This may break the 'No ABI' case which means default ABI plus e.g.
> > -mlong64 as it is used in the embedded world. OTOH, basing this usage
> > on o32/o64 in future is probably a good idea.
> 
> I'm not sure how it could break things like that.  -mlong64 only
> controls type sizes.

I heard

	mips64-elf-gcc -march=FOO -mlong64

is used in the embedded world to get 64 bit code and allow FOO's
opcodes in it. Selecting an ABI definition automatically for e.g.
FOO == r4000 while keeping "No ABI" for FOO == r5000 would be
at least surprising.

> > >     (a) It seems counter-intuitive for -mabi to override the default
> > >         architecture even when that default was compatible.  For
> > >         example, "mipsisa32-elf-gcc -mabi=o32" would generate
> > > 	MIPS I code rather than MIPS 32 code.
> > 
> > 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...

The ABI defines the platform to run code on. So it specifies
the set of opcodes which are legal with this ABI. E.g., MIPS 32
specific opcodes are outside the o32 definition. It they weren't,
every o32 conformant platform would need to emulate them.

> > 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.

Slightly different:
If -mabi=32 really means "Create o32 ABI conformant code", the MIPS I
opcodes are the only ones which can be allowed.

> That's the current behaviour, but like I said above,
> it seems strange to pick MIPS I regardless of the default processor.

An ABI defines _minimal_ requirements for the processor. It also
gives a _maximum_ what is guaranteed to the userland. The strangeness
you see is simply the fact that there are/should be better ABIs than
o32 for current processors.

> > > 	(OPTION_FP64): New.
> > > 	(md_longopts): Add -mfp64, remove -mcpu.
> > 
> > There's little reason to have -m[gf]p64, see
> > http://sources.redhat.com/ml/binutils/2001-07/msg00417.html
> 
> One of the changes was that the default float register size would
> be worked out from -mgp32, -mgp64, -msingle-float, etc.  That was
> mostly for multilib convenience.

For embedded use, I assume. For hosted systems this should be done
by the ABI.

> GAS can generate -mgp32 -mfp64
> "no ABI" code, so we'd need the -mfp64 option then.  Why anyone
> would use it, well, who knows?

I don't see even an half-sane use for it, and it's IMHO a bad idea
to try to support everything without need.

> But someone once went to a lot of
> effort to make it work in GCC too (although it doesn't any more).

Are you actually talking about the combination -mgp32 -mfp64?


Thiemo