From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) by sourceware.org (Postfix) with ESMTPS id 1911B385840F for ; Fri, 3 Sep 2021 12:38:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1911B385840F Received: by mail-pf1-x42e.google.com with SMTP id u6so4231150pfi.0 for ; Fri, 03 Sep 2021 05:38:44 -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=9cJ+vYi0W5LPEN/YEyYg0s4yc7/hvSCK07XbXqNAqL0=; b=tJm7jtfIZc2q2CCucmPkt5fqC/rkR/VFzcwqjEhM5cKtBZwctNVYKdIQd5lctxTM23 WrucAd8Q2w+Q59xZtzEs9Cyq2eQAmhfROLY/z2nw2XcxtZz3ddViIEr434YhIUFvt5GK TtthO/UL9o4YW0rofvwxct/2f1hbzLULJDEpZEOVoRPiKOoxJ/D/O2uHzUmNhs+w3QQV VUhhEezttAew2famj54+Jol+kgXorOPbLZTOk8Su89hHtZlh7+S3ufxPg4G4rfHbzt3g LuOmqeyOcCgoBe8KSZBsNNJi2xZiCLIATa8Cs0lyPONou136pg8U5E++YUZQSQUd0v3z u7Vw== X-Gm-Message-State: AOAM533vbWkCLgpzlr4APRnnlPzMRSMTF9j3fDzg3XafwgY48N8/Wov1 TVNpfdw7386l+gxPS4+qilI= X-Google-Smtp-Source: ABdhPJw8W1gIDsvPtmxdRgxRtlgmOymTJiRW9PpJBv1E3s0rXUFqivQtUG8rpCEesYg6oEZ/Qb4gyw== X-Received: by 2002:a62:a20d:0:b029:35b:73da:dc8d with SMTP id m13-20020a62a20d0000b029035b73dadc8dmr3244912pff.54.1630672722305; Fri, 03 Sep 2021 05:38:42 -0700 (PDT) Received: from DESKTOP0OKG1VA ([202.169.113.201]) by smtp.gmail.com with ESMTPSA id m26sm2218043pfo.146.2021.09.03.05.38.39 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Sep 2021 05:38:41 -0700 (PDT) Message-ID: <0A22522993EB4341AFA02779328F247D@DESKTOP0OKG1VA> 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 22:38:36 +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 12:38:46 -0000 >> > 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? > This is not in one single place, but spread throughout the > compiler, both common code and back-end. I do not think it will > be possible to get the compiler to generate correct code if > you do not specify the address size correctly. 1. Is there any way to put a constraint on index registers, to say that a particular machine can only index in the range of =E2=80=93512 to +512 or some other arbitrary set? If so, I can do 0 to 2 GiB. 2. Is there a way of saying a machine doesn=E2=80=99t support indexing at all? >> > 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. > =20 >> That will generate 64-bit z/Arch instructions. >> I wish to generate ESA/390 instructions. > Why? AMODE64 exists only in z/Arch, so of course there > will be z/Arch instructions available ... For the same reason people constructed Babbage=E2=80=99s invention, I wish to demonstrate the minor changes that would have been required to the S/360 so that we would never have arrived at a 31-bit black hole, and we could have in fact had the perfect 32-bit machine. Almost identical to the 31-bit machine. A S/360+, a S/370+ and a S/390+.=20 >> > 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? > It's open source, of course everybode can decide what they > want to work on themselves. But we decide what we spend > our own time on based on we think is useful ... Sure. >> No-one at all is interested in 32-bit mainframes? > Not any more, at least not in Linux. Linux is pretty much > 64-bit only at this point. I think z/OS is pretty much still 31-bit only, as far as apps are concerned, right? I=E2=80=99d like to bump that up to 32-bit. BFN. Paul.