From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) by sourceware.org (Postfix) with ESMTPS id 372433857823 for ; Thu, 2 Sep 2021 08:15:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 372433857823 Received: by mail-pf1-x42d.google.com with SMTP id 2so1030058pfo.8 for ; Thu, 02 Sep 2021 01:15:50 -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:content-transfer-encoding:importance; bh=Ss3Fz7zBgBSBOQUur6yodY2rwByjd6foTBs5pR2Hdho=; b=VbjqYAyClnbKDiPOhKzpe2tnQGWNqJ2QqY7vv4qwfEl1R++WguAXXnqWFM2vmppfP0 QFVc6UC30KmYlFWhPI144HpHUlhDLpfpdbn1xNuY/yNymj49/Wb0zTKOum2EJmRob+h8 0gbZl6pqhVmqVeUCMRpJbKgzquW2oOe1G0Z3qzbOOAerkx6vp8xDKgBLuLus26wkcVTo qsZ+pyIJSl5u8c71qBOYaoDtaHi5qC9X6AMZa2TGUtWtQZHc4g7Xvjc4RJ2A1zNy03sE W8iiLzaJX8zvKQao+ogdNNl2VXVlVPc1sgj/RTv6M4Ko8fuifEAnhqTb7VQi5hlCcfQF urIw== X-Gm-Message-State: AOAM533bm73EjPKYJYyb/o0xobWkF8DSqslUaQHKoIa2m0FcGakCbPds Gedy6n7csdcuxRj5eiZG0+M= X-Google-Smtp-Source: ABdhPJyd85ToQNKpOU6j1O9BSyCL4LtB0HF5XOHe9NkITmm+8GjIEGjFOwD+3jyXu3U2LLw2t1PZLw== X-Received: by 2002:a63:1c1e:: with SMTP id c30mr2089643pgc.352.1630570549111; Thu, 02 Sep 2021 01:15:49 -0700 (PDT) Received: from DESKTOP0OKG1VA ([202.169.113.201]) by smtp.gmail.com with ESMTPSA id g140sm1352521pfb.100.2021.09.02.01.15.46 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Sep 2021 01:15:48 -0700 (PDT) Message-ID: From: "Paul Edwards" To: "Ulrich Weigand" Cc: References: <200906051520.n55FKg7T016481@d12av02.megacenter.de.ibm.com> In-Reply-To: <200906051520.n55FKg7T016481@d12av02.megacenter.de.ibm.com> Subject: s390 port Date: Thu, 2 Sep 2021 18:15:44 +1000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit 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=-0.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, STOX_REPLY_TYPE, STOX_REPLY_TYPE_WITHOUT_QUOTES, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org 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 08:16:00 -0000 Hi Ulrich. Sorry for the necro - things happen slowly Down Under. :-) Anyway, I am helping someone with their public domain project, UDOS - https://github.com/udos-project/udos (just a hobby, won't be big and professional like Linux) We got the IPL process in place on ESA/390, and then I decided that the next thing to do would be to switch to z/Arch so that we could get rid of the AMODE 31 architectural limit on 32-bit programs. It all worked fine, and we were able to use GCC 11 to target S/390 and use the -m31 to generate 32-bit code, run it under z/Arch as AM64, sort of making it the equivalent of AM32. Really it is the equivalent of AM-infinity, and there's the rub - GCC 11 is generating negative indexes, which cause memory above 4 GiB to be accessed (instead of wrapping at 2/4 GiB), which of course fails. Do you have any idea how to stop the S/390 target from generating negative indexes? I thought the solution might be to change the Pmode to DImode even for non-TARGET64, but as you can see here: http://www.pdos.org/gccfail.png we got an internal compile error - maximum number of generated reload insns per insn achieved (90). I then tried changing the other SImode reference (CASE_VECTOR_MODE) to DImode too, but that gave the same internal error. Here is what the failure looks like (see the large R4): 01:28:27 PSW=00042001 80000000 0000000000005870 INST=A73A0001 AHI 3,1 add_halfword_immediate 01:28:27 R0=00000000000001FD R1=00000000000000E2 R2=000000000009E579 R3=00000000000080B2 01:28:27 R4=00000000FFFFF000 R5=000000000001E5C8 R6=0000000000007FFF R7=0000000000002000 01:28:27 R8=000000000000201F R9=0000000000000000 RA=00000000000080B0 RB=00000000000080B2 01:28:27 RC=000000000009E580 RD=0000000000008138 RE=0000000000007B4C RF=000000000001E4E4 01:28:27 PSW=00042001 80000000 0000000000005874 INST=42142FFF STC 1,4095(4,2) store_character 01:28:27 R:000000010009E578: Translation exception 0005 01:28:27 R0=00000000000001FD R1=00000000000000E2 R2=000000000009E579 R3=00000000000080B3 01:28:27 R4=00000000FFFFF000 R5=000000000001E5C8 R6=0000000000007FFF R7=0000000000002000 01:28:27 R8=000000000000201F R9=0000000000000000 RA=00000000000080B0 RB=00000000000080B2 01:28:27 RC=000000000009E580 RD=0000000000008138 RE=0000000000007B4C RF=000000000001E4E4 01:28:27 HHCCP014I CPU0000: Addressing exception CODE=0005 ILC=4 01:28:27 PSW=00042001 80000000 0000000000005878 INST=42142FFF STC 1,4095(4,2) store_character 01:28:27 R:000000010009E578: Translation exception 0005 01:28:27 R0=00000000000001FD R1=00000000000000E2 R2=000000000009E579 R3=00000000000080B3 01:28:27 R4=00000000FFFFF000 R5=000000000001E5C8 R6=0000000000007FFF R7=0000000000002000 01:28:27 R8=000000000000201F R9=0000000000000000 RA=00000000000080B0 RB=00000000000080B2 01:28:27 RC=000000000009E580 RD=0000000000008138 RE=0000000000007B4C RF=000000000001E4E4 01:28:27 HHCCP043I Wait state PSW loaded: PSW=00060001 80000000 0000000000000444 01:28:40 quit 01:28:40 HHCIN900I Begin Hercules shutdown Any idea what we can do? Thanks. Paul. -----Original Message----- From: Ulrich Weigand Sent: Saturday, June 6, 2009 1:20 AM To: Paul Edwards Cc: gcc@gcc.gnu.org Subject: Re: i370 port Paul Edwards wrote: > In addition, that code has been ported to GCC 3.4.6, which is now > working as a cross-compiler at least. It's still some months away > from working natively though. It takes a lot of effort to convert > the Posix-expecting GCC compiler into C90 compliance. This has > been done though, in a way that has minimal code changes to the > GCC mainline. You're referring to building GCC for a non-Posix *host*, right? I assume those changes are not (primarily) in the back-end, but throughout GCC common code? > Yes, I'm aware that there is an S/390 port, but it isn't EBCDIC, isn't > HLASM, isn't 370, isn't C90, isn't MVS. It may well be possible to > change all those things, and I suspect that in a few years from now > I may be sending another message asking what I need to do to get > all my changes to the s390 target into the s390 target. At that time, > I suspect there will be a lot of objection to "polluting" the s390 target > with all those "unnecessary" things. Actually, I would really like to see the s390 target optionally support the MVS ABI and HLASM assembler format, so I wouldn't have any objection to patches that add these features ... I understand current GCC supports various source and target character sets a lot better out of the box, so it may be EBCDIC isn't even an issue any more. If there are other problems related to MVS host support, I suppose those would need to be fixed in common code anyway, no matter whether the s390 or i370 back-ends are used. The only point in your list I'm sceptical about is 370 architecture support -- I don't quite see why this is still useful today (the s390 port does require at a minimum a S/390 G2 with the branch relative instructions ... but those have been around for nearly 15 years). Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com