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/i...@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.
