From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) by sourceware.org (Postfix) with ESMTPS id B48C03858D1E for ; Tue, 20 Dec 2022 04:27:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B48C03858D1E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-lj1-x229.google.com with SMTP id n6so5582424ljj.11 for ; Mon, 19 Dec 2022 20:27:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=U5rmv1+UUrqV6WzERjUiM2+vYc1xtoaDV0wvwxOwX2g=; b=CgKjujN2y+QQIL8WaxQt90od/vI9OLeiYB3C0MYlSag7NiRJbre7rY0osc9z3dwkae Ac9CWwqEOhE60DvbIURWWc0qkAdfOBekLENHmeUE5NNpyDa4D+WR0INnMOQMscY6GsT6 AkjVknvmBvM1JQZWJP0cJ++vHF4ieREbIv1PqdMYVcPS4A4N6kd5osF/S6qkCCo87TIH Tn1QfbwEqSYo1bzlFCWk7H5H3ZJ8Ubhz+OOaifRnYASjNAOFVmyDWsyn1dI9LrLVeTlF 772Q3FYwJY3n9e1xd8AJnExEqvdX4uLunyfZKDTC56bO7HEgAGEAW5dnEMHKk0sEXQvn uuxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=U5rmv1+UUrqV6WzERjUiM2+vYc1xtoaDV0wvwxOwX2g=; b=ku3DOgDTAqt67ovgj/kIoVnlByyV9rUwLKIelP0NqSNdoNAk1RJoBRMHCagMGEGd02 vEvmhpQB3dlxNAhCV65gHOWMrrBsyqQffXPNomMud+FUs/odjFwsjLmgz9vLVmx7p+m/ IgnqPO7c4xsrG9KIgVrdwDDAtZyHDbS4U4ggvECjUFEyIPKWGU5G1OWSIwnMFtt3Jy5/ I2dHrzIdZGn27sYu/BztrazoSPZwZZQyzlWmNa+TA+61JJPZ0SAe1Ed0Gf60KrCIo/Eq wiuUkK5YhR5exo0AjIWEDBtsVP4qC+GxMtqfE0EnDNuM888pFsL1nvL9yFAnucDW6QHH zXKg== X-Gm-Message-State: ANoB5pmnboJVChPQugx0cmZNQNx5eCv0lHauUSP1Hn6F2Kzt3dVKgZY/ 01SCd0VgXoc87oB1//jsMng4InJ2HaU4YE69ClU= X-Google-Smtp-Source: AA0mqf7iLYuAoXjYcuO4KO/sSPxo0usCAY6zAMfwNLBjne/BvpapvKcDQVZcuBHV7uRxU9WbjQ94mmbT4KRKQx1tERQ= X-Received: by 2002:a2e:a22d:0:b0:27a:23a:d786 with SMTP id i13-20020a2ea22d000000b0027a023ad786mr6610270ljm.428.1671510436048; Mon, 19 Dec 2022 20:27:16 -0800 (PST) MIME-Version: 1.0 References: <200906051520.n55FKg7T016481@d12av02.megacenter.de.ibm.com> <18CA5177BA304CEAB8464FD24D0DF307@DESKTOP0OKG1VA> <2D0FCE9CBE22470A9361F94E221775BA@DESKTOP0OKG1VA> In-Reply-To: From: Paul Edwards Date: Tue, 20 Dec 2022 12:27:01 +0800 Message-ID: Subject: Re: s390 port To: Ulrich Weigand Cc: gcc@gcc.gnu.org, Ulrich Weigand Content-Type: multipart/alternative; boundary="000000000000c772db05f03ad9a3" X-Spam-Status: No, score=0.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.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --000000000000c772db05f03ad9a3 Content-Type: text/plain; charset="UTF-8" On Fri, 3 Sept 2021 at 20:12, Ulrich Weigand wrote: > "Paul Edwards" wrote on 03.09.2021 13:35:10: > > > 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. > > The compiler naturally keeps them zero. The > > instructions that are used to load registers > > do not pollute the high-order 32 bits. > > While this is true for most instructions, the compiler will not > restrict itself to using only those. (As just one obvious > example, the compiler may use "lay" with a negative displacement, > which will set the high bits of a GPR in AMODE64.) > > (And, b.t.w. not the -m31 DImode, which is a pair of 32-bit > GPRs, but rather the -m64 DImode, which is a single 64-bit GPR.) > Hi all. Turns out I have been asking the wrong question for several years. I was going to generate a peephole (an idea from the author of UDOS, now KinnowOS) to detect when a negative index was being used, and force an addition instead of an index, when I realized that it wasn't just literals that could use a negative value. That is when I realized that negative numbers were perfectly valid/normal for indexing, and that it is the OS/hardware that needs to adapt to this reality when transitioning from 32-bit hardware to 64-bit hardware. As such, I have updated z/PDOS-32 to use DAT to map the 4 GiB to 8 GiB region to 0 to 4 GiB, so that negative indexing works fine. You can download this from http://pdos.org (down the bottom). So would it be possible now to update gcc to make -m32 and -m31 and -m24 all work, as they all generate the exact same code, regrardless of whether you are running as AM24 on S/370, AM31 on S/390 or AM32 on Hercules/380 or AM64 with DAT set appropriately on z/Arch. Thanks. Paul. --000000000000c772db05f03ad9a3--