From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5047 invoked by alias); 8 Aug 2009 11:01:09 -0000 Received: (qmail 4715 invoked by uid 22791); 8 Aug 2009 11:01:08 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_05,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-pz0-f202.google.com (HELO mail-pz0-f202.google.com) (209.85.222.202) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 08 Aug 2009 11:01:01 +0000 Received: by pzk40 with SMTP id 40so2058487pzk.14 for ; Sat, 08 Aug 2009 04:00:59 -0700 (PDT) Received: by 10.114.47.14 with SMTP id u14mr3143144wau.22.1249729258942; Sat, 08 Aug 2009 04:00:58 -0700 (PDT) Received: from Paullaptop (203-206-7-21.dyn.iinet.net.au [203.206.7.21]) by mx.google.com with ESMTPS id m34sm3330545waf.57.2009.08.08.04.00.55 (version=SSLv3 cipher=RC4-MD5); Sat, 08 Aug 2009 04:00:57 -0700 (PDT) Message-ID: From: "Paul Edwards" To: "Ulrich Weigand" Cc: "Daniel Jacobowitz" , References: <200907201426.n6KEQwOf024382@d12av02.megacenter.de.ibm.com> In-Reply-To: <200907201426.n6KEQwOf024382@d12av02.megacenter.de.ibm.com> Subject: Re: i370 port Date: Sat, 08 Aug 2009 12:04: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-08/txt/msg00139.txt.bz2 >> I then found out that even with old versions of the machine definition, >> I can have the warning removed by simply not defining CONST_INT >> in the PREDICATE_CODES, even though it is allowed when the >> function is called. ie it seems to have no effect on the code >> generation, but succeeds in eliminating the warning, and without >> needing to define an extra constraint for non-constant situations. > > Actually PREDICATE_CODES does have to match the predicate definitions. > If it does not, you can run into subtle bugs, as the code in genrecog.c > that generates the finite state automaton matching an RTX pattern > against the .md insn definitions *does* make use of PREDICATE_CODES; > for example, it will assume that two predicates with disjoint sets > of PREDICATE_CODES can never both match the same RTX. > > This may or may not lead to visible differences when compiling simple > test cases, but I'd expect effects to be visible in more complex > scenarios. Thanks Ulrich. When I went back to this I found that I had misdiagnosed - actually the r_or_s didn't allow constants after all. It was only const_rtx that it allowed. So the machine definition no longer has any warnings and all looks good. That's with 3.2.3. With 3.4.6 I have now managed to get an MVS load module, unoptimized (I already know that optimized doesn't work), to compile a hello world program successfully, although it abends at the end of that and I haven't investigated that yet. So the theoretical EBCDIC support is less theoretical now. I "needed" to change the parameter search algorithm to stop being binary search though. GCC 4 complained (on my Linux system) that I didn't have various things (gimp etc) installed, which means I would need that other software to be ported too, which is not a project I want to work on at the moment. However, at least it means that i have successfully merged all the GCCMVS changes to 3.2.3 in with the (last available) 3.4.6 development, which was a precursor to any GCC 4 port anyway. I'll see over time how GCC 3.4.6 pans out. Until then, back at GCC 3.2.3, I have a "need" to make the entry point 0 in my MVS modules. Currently I generate this: COPY PDPTOP CSECT * X-var bytes ENTRY BYTES * Program data area DS 0F BYTES EQU * DC F'258' * Program text area LC0 EQU * DC C'bytes is %d' DC X'15' DC X'0' DS 0F DC C'GCCMVS!!' EXTRN @@CRT0 ENTRY @@MAIN @@MAIN DS 0H USING *,15 L 15,=V(@@CRT0) BR 15 DROP 15 LTORG * X-func main prologue MAIN PDPPRLG CINDEX=0,FRAME=96,BASER=12,ENTRY=YES ... * Function main page table DS 0F PGT0 EQU * DC A(PG0) END @@MAIN for a main program. In order to get the entry point to 0, I need to move that @@MAIN function to the top of the file. But I only really want that function if this is a main program. I have found somewhere where I can add some code to see if the function "main" is being compiled, and set a global variable. Unfortunately, the place that happens (c-decl) isn't called until after all the data has been written out! I looked at the documentation: http://gcc.gnu.org/onlinedocs/gcc-3.2.3/gccint/Assembler-Format.html#Assembler%20Format but maybe I'm looking in the wrong place. Any ideas? And I have another question - where is the code for __asm__? Currently that is generating garbage for me: unsigned int bytes = 258; __asm__("? :"); int main(void) BYTES EQU * DC F'258' o@z * Program text area when done in cross-compiler mode, and need to find out where the literal is being translated (or more likely - failing to be translated in the first instance). Any idea where that is? And final thing - the interest in the __asm__ comes from the hope that in the generated 370 assembler, it would be possible to have the C code interspersed to whatever extent possible. The plan was to basically somehow get every line of C code, e.g. "int main(void)" above, and automatically generate an: __asm__("int main void)"); although I'm not sure what to do about this: int main(void) __asm__("? :"); { which gives a syntax error. Any idea how to get the mixed C/assembler when I'm running with the "-S" option and don't have the luxury of calling the normal "as" which would normally handle that? Thanks. Paul.