[PATCH] Introduce abi_word_mode

[Ulrich Weigand]

(I apologize for duplicate messages, I used a broken mailer ...)
Richard Sandiford <richard@codesourcery.com> wrote on 10/09/2006 09:33:02 PM:

> ...IMO, this point argues against the change you're trying to make.
> You're effectively trying to _redefine_ what the attribute means,
> and one of the drawbacks of that is precisely that it may hurt people
> who are already using it.  gcc is doing what the documentation says
> (mainly thanks to woolly documentation) and the people that make
> use of it may expect it to do what it does now: provide the size
> of a general purpose register.  It's really a case of which target
> audience you choose to side with.

Yes, in a way we want to redefine what the attribute means, but not
to make it mean something different -- rather the definition should
clarify what was actually meant, and the current users expect.

What do you think of the definition I proposed in my reply to Ian,
"the mode of a general purpose register as defined by the ABI",
e.g. as provided by the size of stack save slots for GPRs.

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

The architecture mode depends on whether we are running a 64-bit
or 32-bit kernel.  On the 64-bit kernel (in z/Architecture mode),
we always have 64-bit wide general purpose registers, and a set
of instructions to operate on them (these are all new instructions,
available *in addition* to the old 32-bit wide operations, which
continue to operate on the low 32-bit half of the registers).
On a 32-bit kernel (in ESA/390 mode), we only have 32-bit registers.

The *addressing mode* defines how the hardware performs effective
address generation -- in 31-bit (don't ask) addressing mode, only
the low 31 bits of the index and base registers are used to compute
addresses, in 64-bit addressing mode all 64 bits are used.  The
addressing mode also modifies the behaviour of a number of existing
instructions, like LOAD ADDRESS.  (There is also a 24-bit addressing
mode, but we don't use it in Linux.)

Now, on the software side we tie the ABI to the *addressing mode* --
the Linux on S/390 (32-bit) ABI requires the 31-bit addressing mode,
and the Linux on zSeries (64-bit) ABI requires the 64-bit addressing
mode.  Note that the ABI does *not* actually require any particular
*architecture mode*.

Now, you cannot have 64-bit addressing mode in ESA/390 architecture
mode.  However, you can very well use 31-bit addressing mode in
z/Architecture mode -- and that is in fact in only way to run a
32-bit binary (complying with the Linux on S/390 ABI) under a
64-bit Linux kernel.

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 status quo has the advantage of being what previous compilers do,
> and of being easier to understand.  The EH symbols aren't mangled,
> so if they are a concern, it seems better to just change the types
> (unless it's OK to continue compiling them in 32-bit mode).

I don't quite understand what you propose here -- how can we change
the types of the EH interfaces without breaking the ABI?

Bye,
Ulrich

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