public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Ulrich Weigand" <Ulrich.Weigand@de.ibm.com>
To: "Paul Edwards" <mutazilah@gmail.com>
Cc: gcc@gcc.gnu.org, "Ulrich Weigand" <uweigand@de.ibm.com>
Subject: Re: s390 port
Date: Fri, 3 Sep 2021 13:18:51 +0200	[thread overview]
Message-ID: <OF84EAA015.F8030BB9-ONC1258745.003C61D5-C1258745.003E26D4@ibm.com> (raw)
In-Reply-To: <2D0FCE9CBE22470A9361F94E221775BA@DESKTOP0OKG1VA>



"Paul Edwards" <mutazilah@gmail.com> wrote on 02.09.2021 22:05:39:
> > Is this about supporting a 4GB address space instead
> > of a 2GB space?
>
> Yes, correct.

OK, that makes things clearer.  This implies in particular:

- 4GB address space means you need to run in AMODE64

- AMODE64 means the native address size is 64 bits.  This
  implies that Pmode has to be DImode, since Pmode tells
  the compiler what the native address size is.

  Specifically, if you try to run AMODE64 with Pmode equals
  SImode, the compiler will not be aware that the hardware
  uses the high 32 bits of base and index registers, and
  will not necessarily keep them zero.  Also, the compiler
  will assume the base + index (+ displacement) arithmetic
  will operate in 32 bits -- I'm pretty sure this is
  actually the root cause of your "negative index" problem.

> > Is it about supporting a 32-bit pointer type in an
> > otherwise AM64 environment?  (This is already used
> > by the TPF target, but the 32-bit pointer will still
> > refer to a 2GB address space.)
> Yes, all pointers will be 32-bit – a normal 32-bit system.

Note that even if Pmode == DImode, you can still use 32-bit
*pointer* sizes.  This is exactly what e.g. the Intel x32
mode does (as was mentioned by Andreas).

> I’d like to approach the problem from the other
> direction – what modifications are required to
> be made to “-m31” so that it does “-m32” instead?
> I’m happy to simply retire “-m31”, but I don’t care
> if both exist.

If you want to go for an "x32" like mode, I think this
is wrong approach.  The right approach would be to
start from "-m64", and simply modify the pointer size
to be 32 bits.

This would work by setting POINTER_SIZE to 32, while
leaving everything else like for -m64.  I'm sure there
will be a few other places that need adaptation, but
it should be pretty straightforward.  You can also
check the Intel back-end where they're using the
TARGET_X32 macro.


We've thought about implementing this mode for Linux,
but decided not to do it, since it would only provide
marginal performance improvements, and has the drawback
of being another new ABI that would be incompatible to
the whole existing software ecosystem.

(The latter point may not be an issue for you if you're
looking into a completely new OS anyway.)

Bye,
Ulrich

  parent reply	other threads:[~2021-09-03 11:18 UTC|newest]

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-05 12:45 i370 port Paul Edwards
2009-06-05 14:33 ` Joseph S. Myers
2009-06-05 14:57   ` Paul Edwards
2009-06-05 15:03     ` Joseph S. Myers
2009-06-05 15:24       ` Paul Edwards
2009-06-05 15:47         ` Joseph S. Myers
2009-09-11 17:35       ` i370 port - in search of hooks Paul Edwards
2017-03-31 10:34       ` i370 port Paul Edwards
2009-09-12 12:41   ` Paul Edwards
2009-06-05 15:21 ` Ulrich Weigand
2009-06-05 15:39   ` Paul Edwards
2009-06-05 15:49     ` Daniel Jacobowitz
2009-06-05 15:57       ` Paul Edwards
2009-06-05 20:20         ` Joseph S. Myers
2009-06-05 20:45           ` Paul Edwards
2009-06-06 15:00       ` Paul Edwards
2009-06-15 17:46         ` Ulrich Weigand
2009-06-19  0:06           ` Paul Edwards
2009-06-19 12:28             ` Ulrich Weigand
2009-07-18 11:28               ` Paul Edwards
2009-07-20 14:27                 ` Ulrich Weigand
2009-08-08 12:04                   ` Paul Edwards
2009-08-10 21:25                     ` Ulrich Weigand
2009-08-11  0:34                       ` Paul Edwards
2009-08-11 15:21                         ` Ulrich Weigand
2009-08-12 11:52                           ` Paul Edwards
2009-08-12 15:27                             ` Paolo Bonzini
2009-08-12 16:35                             ` Ulrich Weigand
2009-08-12 17:27                               ` Paul Edwards
2009-08-12 17:56                                 ` Paolo Bonzini
2009-08-12 19:46                                 ` Ulrich Weigand
2009-08-12 20:31                                   ` Paul Edwards
2009-08-19 12:07                               ` Paul Edwards
2009-08-19 12:27                                 ` Paolo Bonzini
2009-08-20 12:49                               ` Paul Edwards
2009-08-20 22:48                                 ` Ulrich Weigand
2009-08-21  2:37                                   ` Paul Edwards
2009-08-21 16:46                                     ` Ulrich Weigand
2009-06-05 15:44   ` Joseph S. Myers
2009-06-05 15:52     ` Paul Edwards
2009-09-08 15:55     ` Paul Edwards
2009-09-14 15:32       ` Ulrich Weigand
2021-09-02  8:15   ` s390 port Paul Edwards
2021-09-02 14:34     ` Ulrich Weigand
2021-09-02 14:50       ` Paul Edwards
2021-09-02 14:53         ` Ulrich Weigand
2021-09-02 15:01           ` Paul Edwards
2021-09-02 15:13             ` Ulrich Weigand
2021-09-02 15:26               ` Paul Edwards
2021-09-02 19:46                 ` Ulrich Weigand
2021-09-02 20:05                   ` Paul Edwards
2021-09-02 20:16                     ` Andreas Schwab
2021-09-03 11:18                     ` Ulrich Weigand [this message]
2021-09-03 11:35                       ` Paul Edwards
2021-09-03 12:12                         ` Ulrich Weigand
2021-09-03 12:38                           ` Paul Edwards
2021-09-03 12:53                             ` Jakub Jelinek
2021-09-03 13:12                               ` Paul Edwards
2022-12-20  4:27                           ` Paul Edwards
2021-09-02 10:56 Paul Edwards
2021-09-06 22:44 Build gcc question Gary Oblock
2021-09-07  7:21 ` s390 port Joe Monk
2021-09-08  3:46   ` Paul Edwards
2021-09-30  0:08 Paul Edwards
2021-09-30  0:59 ` Joe Monk
2021-09-30 21:39 Paul Edwards
2023-01-28 18:51 Paul Edwards
2023-01-29 13:08 ` Joe Monk
2023-01-29 14:30   ` Paul Edwards

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=OF84EAA015.F8030BB9-ONC1258745.003C61D5-C1258745.003E26D4@ibm.com \
    --to=ulrich.weigand@de.ibm.com \
    --cc=gcc@gcc.gnu.org \
    --cc=mutazilah@gmail.com \
    --cc=uweigand@de.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).