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:
> At Mon, 15 Jul 2002 17:54:45 +0000 (UTC), "Thiemo Seufer" wrote:
> > 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.
> 
> I prefer to think of it that there are two competing definitions.  8-)
> 
> All of the binary formats in question have a field, EF_MIPS_ARCH,
> which can easily be used to determine which ISA is used to compile the
> binary.
> 
> According to your strict definition, only one value of that field is
> allowed per ABI.

For strict ABI conformance, it obviously is.

> However, it is much more useful to people creating optimized code to
> be able to generate code for specific ISAs,

For people who create, maintain and use an whole OS this would
be horrible. :-)

> it is almost free from the
> POV of checking whether said code is compatible with the current
> system(*), and it doesn't really diminish the value of the ABI for
> 'binary portability' if the portable binaries are compiled with
> the options that produce the exact ABI.
> 
> If somebody's using, say, mips64-linux, I'd say that they expect
> -mabi=X to get them the either 'portable' ABI 'X', or the "-mips3" ISA
> version, depending on how they look at things.

I this special example,

	gcc -mabi=o32

should produce MIPS II code, while

	gcc -mabi=64

should give MIPS III code, so it runs on any supported hardware.
Note that the MIPS II is a deviation from stock o32 ABI, the
linux-mips kernel emulates the necessary instructions on MIPS I
hardware. This means we have an o32-linux ABI there.

> If they're using a target like, say, mipsisa64-linux, then they almost
> certainly want -mabi=X to get them the ABI 'X' for binary format,
> calling conventions, etc., but with use of MIPS64 instructions.
> 
> If they're using mipsisa64sb1-linux, they probably expect built-in
> support for, say, MIPS-3D, MDMX .ob, and the few SB-1 extensions as
> well, regardless of the ABI they choose on the command line.

If all of the hardware for this target supports these, ok.
But the ISA pre-selection should then be done in the target specific
code and not globally.

> I'm wondering if the right thing to do here is have flags like
> -mstrict-abi=XXX, which also set the ISA type, or -mabi=strict-XXX...

-mabi=isa64sb1-with-many-wonderful-extensions ;-)

> There's use for it: people building e.g. userland binary distributions
> would want it, and would encourage users building e.g. RPMs to use it
> so they didn't have to remember the exact ISA to use to get things
> right.
>
> I think there're a large number of people out there doing embedded
> work with systems that use the standard ABIs (E.g. linux), whose lives
> would be a fair bit harder if -mabi=X always implied ISA.

In this case, people should not even need to care about the ABI.
The ABI should be a sane default, and they have only to specify
where they want to deviate from it. E.g.

	mips-linux-gcc -march=r4600

should cenerate code which uses r4600 specific opcodes but uses
o32 definitions otherwise. The definition of the default ABI
should be done in the target specific code, maybe with "No ABI"
for embedded toolchains.


Thiemo