From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) by sourceware.org (Postfix) with ESMTPS id A074C3851C3B for ; Wed, 8 Sep 2021 03:46:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A074C3851C3B Received: by mail-pl1-x629.google.com with SMTP id d18so442532pll.11 for ; Tue, 07 Sep 2021 20:46:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:from:to:cc:references:in-reply-to :subject:date:mime-version:importance; bh=DNSmKBdxRVj7K2rvV6zBAINXMTLCFWQUqmABXCbM9Fo=; b=R76jJRJoBJU4V8ZxlfHgglWKLYgZPUw+UbXjSiKO3oosPO4BlhDbsnlAEEIu1i/Y37 WC9EUWka4LDi02J0zHR9wmMlWf5uczLf5N+2DM90H8LYiWZiW3PSrHmBG66EiZP2Y+8/ SjMp7a2LPbQElFmKwnX5xm6owSunwHx6Gm3t8v+TprhCicOVEbIhwRZhHH3RibmALLJl qw4nzA57IO04cgilCLfh0AZdQIODD7HXO8SyBcBIVNEC+VcpqReoYeWcS1Q9Wnix3mPT rxjEk+R8ZitYzgqsLYpUXZxQH1Eocd/mLs+dF5/KgptxdEFxh7E9tJJfbDaz0CGfNpcH WwvA== X-Gm-Message-State: AOAM53216/vrd8WjQyICDDday0NA4mNu46j5S/6+qdC0FyLyyey59Xmd uy8v9trj/z2TvWKhMz/UlwM= X-Google-Smtp-Source: ABdhPJxdj0HrYIJdJ2fYroV2C7c71zQWKs/CwIVbAuW24Qg9TM9F30FGOMZWl/RzjscAKO5XQa+z3g== X-Received: by 2002:a17:90b:ec9:: with SMTP id gz9mr1818617pjb.24.1631072796763; Tue, 07 Sep 2021 20:46:36 -0700 (PDT) Received: from DESKTOP0OKG1VA ([202.169.113.201]) by smtp.gmail.com with ESMTPSA id i7sm671230pgd.56.2021.09.07.20.46.34 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Sep 2021 20:46:36 -0700 (PDT) Message-ID: From: "Paul Edwards" To: "Joe Monk" Cc: References: In-Reply-To: Subject: Re: s390 port Date: Wed, 8 Sep 2021 13:46:31 +1000 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2021 03:46:38 -0000 Hi Joe. Thanks for your comments. > It is unclear how this would even work.=20 > 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.