From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14657 invoked by alias); 12 Sep 2009 12:41:25 -0000 Received: (qmail 14644 invoked by uid 22791); 12 Sep 2009 12:41:24 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-pz0-f188.google.com (HELO mail-pz0-f188.google.com) (209.85.222.188) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 12 Sep 2009 12:41:17 +0000 Received: by pzk26 with SMTP id 26so1437247pzk.27 for ; Sat, 12 Sep 2009 05:41:15 -0700 (PDT) Received: by 10.114.163.26 with SMTP id l26mr7480921wae.173.1252759275169; Sat, 12 Sep 2009 05:41:15 -0700 (PDT) Received: from Paullaptop (203-206-7-21.dyn.iinet.net.au [203.206.7.21]) by mx.google.com with ESMTPS id 23sm2935379pzk.8.2009.09.12.05.41.11 (version=SSLv3 cipher=RC4-MD5); Sat, 12 Sep 2009 05:41:13 -0700 (PDT) Message-ID: <064442E0DC8844A9A09FB7D1054BDEE0@Paullaptop> From: "Paul Edwards" To: "Joseph S. Myers" Cc: References: In-Reply-To: Subject: Re: i370 port Date: Sat, 12 Sep 2009 12:41:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2009-09/txt/msg00224.txt.bz2 >> It was dropped from GCC 4 when there was supposedly no >> maintainer available. Actually, Dave Pitts and myself were >> both maintaining it at that time, but we were both still working >> on an old version of it (3.2). So gcc 3.4.6, circa 2004, was the >> last time it was included in the normal GCC distribution. > > (For reference, the port was removed in SVN revision 77216; before then it > had had various largely mechanical changes as part of changes to multiple > back ends or target-independent code, with r69086 as the last vaguely > i370-only change but no changes appearing to come from someone > specifically working and testing on i370 for some years before then. "svn > log svn://gcc.gnu.org/svn/gcc/trunk/gcc/config/i370@77215" shows the > history.) I just took a look to see if there was anything changed on the head that didn't make it into 3.4.6. Short answer: no. Long answer: C:\devel\gccoff>diff gccnew gcchead Only in gcchead: .svn diff gccnew/i370.h gcchead/i370.h 530,531c530 < #define INIT_CUMULATIVE_ARGS(CUM, FNTYPE, LIBNAME, INDIRECT, N_NAMED_ARGS) \ < ((CUM) = 0) --- > #define INIT_CUMULATIVE_ARGS(CUM, FNTYPE, LIBNAME, INDIRECT) ((CUM) = 0) I just need to delete that N_NAMED_ARGS when upgrading. I'm sure that will be the least of my worries though. I'm more worried about things like the below. :-) Incidentally, 15 years of effort to get a hosted GCC compiler on real MVS (not USS) came to realization on Jan 11, 2004: http://osdir.com/ml/emulators.hercules390.mvs/2004-01/msg00031.html (although it wasn't released until March 2004 when it was good enough to self-compile.) The revision that deleted i370 was made on Feb 4th, 2004. How's that for timing? Incidentally, while it may look from this angle like the i370 port wasn't being worked on, it's actually had a huge amount of effort put into it. The activity has just been in different forums (like the one above). It wasn't just GCC though. A lot of infrastructure was required. E.g. even the assembler didn't support such a huge number of externals that was being generated by GCC, so first I hacked around that in GCC itself, mapping a whole lot of "unused" flags to be the same, and then reversed that out when someone came up with a modification to the assembler. Then we needed to switch from 24-bit mode to 31-bit mode to get the required memory for GCC to self-compile. Another huge enterprise. > I would encourage going through all the changes made to the i370 port on > GCC mainline, after 3.1/3.2 branched and before the port was removed, to > see what should be merged into your version for mainline; ultimately it > would be up to you how you get it updated for all the mechanical changes > on mainline since 3.2, but those changes (see command above to get logs) > may be a useful guide to how to do some of the updates. All the merging has already been done in the 3.4.6 effort. The only thing that I know of that is still "at large" is someone else who was working "offline" and made some changes. Specifically this: http://osdir.com/ml/emulators.hercules390.mvs/2004-01/msg00008.html as I just discovered the same problem with both of these strict moves now that I too am using 3.4.6. The i370.md looks correct to me (this is the movstricthi one): > ;(define_insn "" > ; [(set (strict_low_part (match_operand:HI 0 "register_operand" "+d")) > ; (match_operand:HI 1 "general_operand" "dSi"))] > ; "" > ; "* > ;{ > ; check_label_emit (); > ; if (REG_P (operands[1])) > ; { > ; mvs_check_page (0, 8, 0); > ; return \"STH %1,\" CONVLO \"(,13)\;ICM %0,3,\" CONVLO > \"(13)\"; > ; } > ; else if (GET_CODE (operands[1]) == CONST_INT) > ; { > ; mvs_check_page (0, 4, 2); > ; return \"ICM %0,3,%H1\"; > ; } > ; mvs_check_page (0, 4, 0); > ; return \"ICM %0,3,%1\"; > ;}" > ; [(set_attr "length" "8")] > ;) but I have had to comment it out, because otherwise I get code like this generated: L691 EQU * SLR 2,2 IC 2,0(8) LA 5,92(0,0) CLR 2,5 BE L699 BH L702 ICM 5,3,=H'64' BE L696 ICM 5,3,=H'78' BE L694 B L701 ie the LA and CLR combination are what I would expect, but gcc 3.4.6 has decided to use an ICM to move a constant in, which seems an awful waste to me instead of using LA, but the real problem is that it hasn't generated a CLR afterwards (it needs to compare against register 2), so isn't taking a branch it should be. I didn't have this problem in 3.2.3, which has a virtually identical machine definition. But I'd be really surprised to find a serious compiler bug outside of the i370 code?! I assume I'm just looking in the wrong spot. But at least I'm making progress. :-) BFN. Paul.