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: Thu, 2 Sep 2021 21:46:12 +0200	[thread overview]
Message-ID: <OF8B90A1F6.92B21F9E-ONC1258744.0069F959-C1258744.006C9999@ibm.com> (raw)
In-Reply-To: <E41D99FF4BE74203A75CA628E1C9E25B@DESKTOP0OKG1VA>



"Paul Edwards" <mutazilah@gmail.com> wrote on 02.09.2021 17:26:25:

> > Therefore again my question, what is the actual goal
> > you want to achieve?   I'm still not sure I understand
> > that ...
> I would like to know what is required to implement
> “-m32” in the S/390 target. I realize that z/Arch
> doesn’t have a specific AM32, but I don’t need a
> specific AM32. What would actually happen if you
> coded a “-m32” and then ran it in an AM64
> environment?

That depends on what that would actually do.  I'm still not
quite sure what the actual requirements are.

Is this about supporting a 4GB address space instead
of a 2GB space?  (I'm not aware of that being used
anywhere currently.)

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

Is it something else?

In either case, what is the actual benefit of that mode?
(I.e. what benefit would justify the effort to implement it?)


> >> Also, I just realized – if GCC is using LA for maths
> >> for 32-bit registers, then values will be limited to
> >> 2 GiB instead of 4 GiB for unsigned, but that is not
> >> the case.
>
> > That's why GCC makes sure to only use the instruction
> > when a 31-bit addition is wanted.  This can be the
> > case either when GCC can prove that the involved
> > operands are pointer values (which are by definition
> > restricted to 31-bit values in -m31 mode)
>
> The compiler doesn’t create a restriction there.
> It just generates a simple LA and it works
> differently depending on whether it is AM24/31/64.

It is the other way around.  The compiler knows
exactly how the LA instruction behaves in hardware,
and will use the instruction whenever that behavior
matches the semantics of (a part of) the program.
Since the behavior of the instruction differs based
on the addressing mode, the compiler will have to
know which mode the executable will be running in.


Currently, the -m31/-m64 switch basically changes several
things (at the same time):
- the assumption on which AM the executable will run in
- the (used) size of a general-purpose register
- the (default) size of a pointer type
- ABI (function calling convention) details

In theory, it would be possible to split this apart
into distinct features, so that it would be possible
to implement a mode where you can have code that uses
32-bit pointers but is running in AM64 (which would
then support a 4 GB address space).

Is this what you mean by an "-m32" mode?


Basically, this would involve looking at all uses of
the TARGET_64BIT macro in the back-end and determine
which of them actually depend on which of the above
features, and disentangle it accordingly.

I guess that would be possible, but it requires a
nontrivial effort.


Bye,
Ulrich

  reply	other threads:[~2021-09-02 19:46 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 [this message]
2021-09-02 20:05                   ` Paul Edwards
2021-09-02 20:16                     ` Andreas Schwab
2021-09-03 11:18                     ` Ulrich Weigand
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=OF8B90A1F6.92B21F9E-ONC1258744.0069F959-C1258744.006C9999@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).