From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) by sourceware.org (Postfix) with ESMTPS id A368E3857001 for ; Thu, 2 Sep 2021 20:05:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A368E3857001 Received: by mail-pl1-x632.google.com with SMTP id k17so1914164pls.0 for ; Thu, 02 Sep 2021 13:05:45 -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=oX99f1cqrxWiN5JIzOFvoHehDxYs/wa0skF0up83fjc=; b=TGRBJ5ZdhEKNGB4s22l74ckEl+OfV9JmX97Cfzu+H80qAlmQFlJz4BFT2yIm6ZQmPm fX8H7I+UZGxdgadhFOWaVMt//LW2k9gcTJ0nb+tuINNxkJrmbBC4kX4vvRjsjfnTrmOr vwe9Z9zx/sFQRZH34mptfeS0dVDWDKXbFjjJ+4r8MEoYq7P27fDKz6qfDAj4eE5wFQ+z 5pX1NPx32qs++mEww0xgOHL4gW2DDN+waQGCSGJ38wjLvgh+HSTOviSaK34ZvFULCxs8 nw5xzffAN7GF7cP1GhdselL7M/O0v2plIG4Zd8jsVEGfrrlE7nhCVTp8iLLO1O/wP2xw VVsA== X-Gm-Message-State: AOAM532vJEM3hqAvm2g5h0Uej5J0WMD/g/gmbECEKSwjn4GncGMch/y0 ZYr8/WZfMhYnxvUanISCkzU= X-Google-Smtp-Source: ABdhPJz4/Wb/vIgF9yDz1sHtg7WWeY9YkQ6mDxiUTlPPYntfGkU2CayObwFxJWHazHoM9aePwYJUag== X-Received: by 2002:a17:902:ce87:b0:138:941a:5c72 with SMTP id f7-20020a170902ce8700b00138941a5c72mr4432494plg.24.1630613144270; Thu, 02 Sep 2021 13:05:44 -0700 (PDT) Received: from DESKTOP0OKG1VA ([202.169.113.201]) by smtp.gmail.com with ESMTPSA id 23sm3847649pgk.89.2021.09.02.13.05.42 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Sep 2021 13:05:43 -0700 (PDT) Message-ID: <2D0FCE9CBE22470A9361F94E221775BA@DESKTOP0OKG1VA> From: "Paul Edwards" To: "Ulrich Weigand" Cc: , "Ulrich Weigand" References: <200906051520.n55FKg7T016481@d12av02.megacenter.de.ibm.com> <18CA5177BA304CEAB8464FD24D0DF307@DESKTOP0OKG1VA> In-Reply-To: Subject: Re: s390 port Date: Fri, 3 Sep 2021 06:05:39 +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: Thu, 02 Sep 2021 20:05:47 -0000 Hi Ulrich. Thanks for your detailed reply. >> > 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 >> =E2=80=9C-m32=E2=80=9D in the S/390 target. I realize that z/Arch >> doesn=E2=80=99t have a specific AM32, but I don=E2=80=99t need a >> specific AM32. What would actually happen if you >> coded a =E2=80=9C-m32=E2=80=9D 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? Yes, correct. > (I'm not aware of that being used anywhere currently.) I=E2=80=99m about to use it. I just need to get past the problem with negative indexes being used, and I need your help. > 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.) Yes, all pointers will be 32-bit =E2=80=93 a normal 32-bit system. > Is it something else? Nope, you got it. > In either case, what is the actual benefit of that mode? > (I.e. what benefit would justify the effort to implement it?) The =E2=80=9Clegacy=E2=80=9D environment of z/Linux etc would be 32-bit instead of 31-bit. IBM=E2=80=99s reputation will be restored. IBM will have the best architecture on the planet. Better than x64 because no mode switch is required shifting between 32-bit and 64-bit applications. All run as AM64 =3D AM-infinity. >> >> Also, I just realized =E2=80=93 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. >=20 >> > 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) > =20 >> The compiler doesn=E2=80=99t 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. The i370 port produces code that works in AM24, AM31, AM32 and AM64 (except for negative indexes). I=E2=80=99m surprised the s390 port doesn=E2=80=99t too. As far as I can remember from using IBM C, it supports execution in any AMODE too. > Currently, the -m31/-m64 switch basically changes several > things (at the same time) > - the assumption on which AM the executable will run in=20 > - 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? Yes, correct. > 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. 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 =E2=80=9C-m31=E2=80=9D is retired, and made an alias for = =E2=80=9C-m32=E2=80=9D, my guess is that 20 lines of code need to be changed. The most important thing is to stop generating negative indexes. ie if you have =E2=80=9Cchar *p=E2=80=9D and you go p[-1] I = don=E2=80=99t want 0xFFFFFFFF generated as an index. I instead want a subtraction done. I was under the impression that this was governed by the Pmode =E2=80=93 whether it was set to DImode or SImode. But I tried forcing Pmode to DImode, even for =E2=80=9C=E2=80=93m31=E2=80=9D, but it gave an internal error, which = I showed you already. What am I missing? Thanks. Paul.