From: "Paul Edwards" <mutazilah@gmail.com>
To: "Joe Monk" <joemonk64@gmail.com>
Cc: <gcc@gcc.gnu.org>
Subject: Re: s390 port
Date: Wed, 8 Sep 2021 13:46:31 +1000 [thread overview]
Message-ID: <CD730C01BAA34CF5BF5D03776E7057F8@DESKTOP0OKG1VA> (raw)
In-Reply-To: <CAPcd4G9crfy31zdT7rey3Oc6EFUAJvJa7ZtrNqazpt0cvZK=9Q@mail.gmail.com>
Hi Joe.
Thanks for your comments.
> It is unclear how this would even work.
> For instance, the LA instruction clears the top bit.
In AM64, LA does not clear any bits.
> Also, instructions like LPR, LNR,
These operate on data registers, not addresses,
and will continue to work unchanged.
> BXLE, BXH all treat the value in the register as signed,
> so the top bit is not available.
These are already a problem if you are putting
addresses in them and it is approaching the 2 GiB
mark. The POP has a special mention of that.
Fun fact: The z/Arch POP has the same problem with
the G version of those instructions, when it hits the
63-bit mark, but the POP incorrectly states that the
problem occurs near the 64-bit mark. I reported the
problem with the POP but nothing seems to have
been done.
The solution is to drop these instructions from the
repertoire. C-generated assembler for both i370 and
s390 targets does not use these.
BFN. Paul.
next prev parent reply other threads:[~2021-09-08 3:46 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
-- strict thread matches above, loose matches on Subject: below --
2023-01-28 18:51 Paul Edwards
2023-01-29 13:08 ` Joe Monk
2023-01-29 14:30 ` Paul Edwards
2021-09-30 21:39 Paul Edwards
2021-09-30 0:08 Paul Edwards
2021-09-30 0:59 ` Joe Monk
2021-09-02 10:56 Paul Edwards
2009-06-05 15:21 i370 port 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
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
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=CD730C01BAA34CF5BF5D03776E7057F8@DESKTOP0OKG1VA \
--to=mutazilah@gmail.com \
--cc=gcc@gcc.gnu.org \
--cc=joemonk64@gmail.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).