From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com [IPv6:2607:f8b0:4864:20::633]) by sourceware.org (Postfix) with ESMTPS id 4AB5D385840F for ; Fri, 3 Sep 2021 11:35:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4AB5D385840F Received: by mail-pl1-x633.google.com with SMTP id e7so3133334plh.8 for ; Fri, 03 Sep 2021 04:35:17 -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=6W1NaFxhOrLNUx/tMpbcb3C7nhkU2v3L1Veac3FBP4c=; b=GFNgtWft0SGSbytYktfCsUHp3r3/9gm1v2FuJcz1V5gmNr7PekqIo0xZ8MHe5mIlCD lRiWxBWfFXCgbLTbTzDCgvOosHQo413DIq1NSJg0Yp44KjeVQvHgDwrozoxV69ktTELN wvviHj95W2F6zhZPzPav/bhWBwgkxkbwPbfAQYZPYTLpVCLwh66JA4zlEQJ+y+bZfFWa jqm8kXV1m9eX05qgke+Ljv2wsFgHyzjjAIE/S8y+sePQsUm75pjblBDLWe5zCCMSpexD rS3NX3xd9fXtLPtdTv/Z4FXyDGa/bsP5IBUSUiVAfRWUwEGASghdSF+yMj8c3VCmaTAo sNWQ== X-Gm-Message-State: AOAM532oRKhcrY4cWzeWpYzMcYOFkxhJ7fAGV2py15vT7piKDFO0OT9e PWVmaJ/K5jVxgjBQI0+hH/c= X-Google-Smtp-Source: ABdhPJyi9CQXfyrj5N4C8AH2sbcTLic4AuZ+o8WeEamWfdK5JXA2BmxwY00qiY54XmhJZQ3NzXISZQ== X-Received: by 2002:a17:902:7e0d:b0:139:f742:6a78 with SMTP id b13-20020a1709027e0d00b00139f7426a78mr2887146plm.9.1630668916324; Fri, 03 Sep 2021 04:35:16 -0700 (PDT) Received: from DESKTOP0OKG1VA ([202.169.113.201]) by smtp.gmail.com with ESMTPSA id c11sm5423242pfm.55.2021.09.03.04.35.13 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Sep 2021 04:35:15 -0700 (PDT) Message-ID: From: "Paul Edwards" To: "Ulrich Weigand" Cc: , "Ulrich Weigand" References: <200906051520.n55FKg7T016481@d12av02.megacenter.de.ibm.com> <18CA5177BA304CEAB8464FD24D0DF307@DESKTOP0OKG1VA> <2D0FCE9CBE22470A9361F94E221775BA@DESKTOP0OKG1VA> In-Reply-To: Subject: Re: s390 port Date: Fri, 3 Sep 2021 21:35:10 +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: Fri, 03 Sep 2021 11:35:18 -0000 > - 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. The compiler naturally keeps them zero. The instructions that are used to load registers do not pollute the high-order 32 bits. > 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. Where is this logic please? Can I do a #if 0 or similar to disable it? > Note that even if Pmode =3D=3D 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=E2=80=99m happy to try the approach from BOTH directions and see which one hits =E2=80=9C-m32=E2=80=9D first. >> I=E2=80=99d like to approach the problem from the other >> direction =E2=80=93 what modifications are required to >> be made to =E2=80=9C-m31=E2=80=9D so that it does = =E2=80=9C-m32=E2=80=9D instead? >> I=E2=80=99m happy to simply retire =E2=80=9C-m31=E2=80=9D, but I = don=E2=80=99t 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. That will generate 64-bit z/Arch instructions. I wish to generate ESA/390 instructions. > I'm sure there > will be a few other places that need adaptation, but > it should be pretty straightforward. No, modifying GCC is beyond my ability. I need 20 lines of code from someone who is familiar with the system. > You can also > check the Intel back-end where they're using the > TARGET_X32 macro. See above about beyond my ability. > 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. Shouldn=E2=80=99t the end user be able to decide this for themselves? No-one at all is interested in 32-bit mainframes? > (The latter point may not be an issue for you if you're > looking into a completely new OS anyway.) Correct. Thanks. Paul.