This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC 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: [PATCH] Introduce abi_word_mode


Richard Sandiford <richard@codesourcery.com> wrote on 10/10/2006 09:02:58 AM:

> The point I was trying to make in the quote above was that, AIUI, the
> set of instructions that a binary can ask the system to execute _is_
> part of the ABI.  E.g., to quote from the i386 psABI:
> 
>     Some processors might support the Intel386 architecture as a subset,
>     providing additional instructions or capabilities. Programs that use
>     those capabilities explicitly do not conform to the Intel386
>     ABI. Executing those programs on machines without the additional
>     capabilities gives undefined behavior.
> 
> So bunging a Pentium instruction into a binary that conforms to the
> i386 ABI would make it longer do so.

Well, OK, that's certainly one characteristic you can mean by the 
term ABI -- if you want to make sure your binary runs on every 
machine that supports the "i386 ABI" in that sense, you cannot 
use anything but i386 instructions.

But there is another characteristic that's also very important in
practice, and that's link compatibility.  You can build some objects
of a program with -march=i686, and others with -march=i386, and link
them all together.  Sure, you need a i686 processor to execute the
combined binary, but at least it will work there.

Saying that, well, -march=i686 doesn't conform to the ABI as cited
above anyway, and therefore we might as well use a different calling
convention, isn't really practical.  There is a lot of value to users
to still keep the "ABI" -in the sense of link compatibility- invariant,
while allowing to exploit different instruction set variants.

And this is exactly what we want to achieve -- provide a configuration
of GCC for s390 that exploits the capabilities of 64-bit machines,
while keeping link compatibility with the 31-bit ABI.

> And the broader point in the rest of my message was that mode(word)
> might be useful to people in exactly this kind of case.  Generalising
> beyond s390, if you have an architecture family that includes 32-bit
> and 64-bit systems, and you're creating a binary that cannot run on
> the 32-bit system, that binary is following a different ABI to those
> that _can_ run on the 32-bit system.

But, you typically want a binary that is link-compatible with your
existing 32-bit system libraries at the very least, right?   If you
don't care about that, why don't you just build a 64-bit binary
according to whatever 64-bit ABI conventions you have?

> And in that situation, you might
> as well take as much advantage of the 64-bitness as possible within
> a function.  E.g. you might as well use 64-bit local variables if
> doing so would be faster.
> 
> So I think that (a) the current mode(word) really is an ABI property
> and (b) the current mode(word) could be useful in exactly the kind of
> situation just described.  (As Ian said, the <stdint.h> fast types
> might be better, but I suspect they haven't been around as long as
> mode(word).)

Well, the <stdint.h> types also affect link compatibility, so they
certainly shouldn't change either in the mode I'm interested in.

If there were a clear understanding that attribute ((mode (word)))
may change between configurations even if they otherwise support
the same ABI (in the sense of link compatibility), then I guess
attribute ((mode (word)) would be a suitable type for strictly
local use as you describe above.  But the current user of
((mode (word))), at least in the GCC code base, are not of
that type.

> I just think it's making a big assumption to say that users of
> word(moode) want a different definition to the one we've been providing.

Well, I guess I don't really know what users of mode (word) in
general want; but those users of mode (word) I have seen (and those
are all in GCC code itself) certainly would benefit a lot more from
guaranteed link compatibility than from guaranteed "real register
size".

Also, I still claim that I don't want to provide a "different"
definition that the one we've been providing. I just want to clarify
how the -currently vague- definition applies in an area where we
hadn't needed to apply it before.  (In the past, attribute
((mode (word)) *has* also always been link compatible since we
really never had supported link compatible configuration with
different word_mode before).  

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  Linux on zSeries Development
  Ulrich.Weigand@de.ibm.com


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