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


"Ulrich Weigand" <uweigand@de.ibm.com> writes:
>> (Even if you're using a 32-bit compatibilty calling convention,
>> the 64-bitness of the code that the system has to run is still
>> technically part of the ABI.  I think from that point of view
>> that the current definition of mode(word) is still an ABI property.)
>
> Not really -- maybe I need to bring in some s390 details here.  The
> machine does not have a "64-bit mode" as such.  Rather, it has two
> orthogonal modes: the architecture mode and the addressing mode.
> [...]
> Note that in this mode, we *always* have the full 64-bit registers
> available -- it is just the existing code does not use them.  In
> the way we propose to add that feature, it would *not* change the
> ABI at all -- it would be rather comparable to using a Pentium
> instruction in an IA-32 binary: you do need the envrionment that
> provides the capability to execute those instructions, but you
> do not change the function call / ABI boundaries at all.

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.

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

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.

Richard


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