From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6127 invoked by alias); 11 Sep 2009 17:35:22 -0000 Received: (qmail 6119 invoked by uid 22791); 11 Sep 2009 17:35:21 -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-px0-f191.google.com (HELO mail-px0-f191.google.com) (209.85.216.191) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 11 Sep 2009 17:35:17 +0000 Received: by pxi29 with SMTP id 29so929249pxi.3 for ; Fri, 11 Sep 2009 10:35:15 -0700 (PDT) Received: by 10.114.30.4 with SMTP id d4mr5898715wad.49.1252690515340; Fri, 11 Sep 2009 10:35: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 21sm2458053pzk.11.2009.09.11.10.35.12 (version=SSLv3 cipher=RC4-MD5); Fri, 11 Sep 2009 10:35:14 -0700 (PDT) Message-ID: From: "Paul Edwards" To: References: <22637DCC73B54BD1B74D5A5F1939C6AF@Paullaptop> In-Reply-To: Subject: Re: i370 port - in search of hooks Date: Fri, 11 Sep 2009 17:35: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/msg00213.txt.bz2 I'm making quite good progress with cleaning up the 3.4.6 i370 port. I've even got optimization working to some degree. Meanwhile, on a different machine (a Linux machine I program on on the way to/from work), I have managed to build 4.4.0, which means I have an environment to work on a more modern version of GCC. That modern version is what I would like to ask about today. Leaving aside the issue of the actual target, I'm more interested in the intrusive hooks I expect I will need (I won't know until I start doing the work, and I can't do that until I find out whether 4.4 is good enough - chicken and egg). Here is what I needed for 3.4.6: 1. Ability to build a standalone executable. Simply put, I need gcc to do a function call like this: #ifdef SINGLE_EXECUTABLE { int cnt = 0; while (commands[i].argv[cnt] != NULL) { cnt++; } if (strcmp(string, "cc1") == 0) { ret_code = toplev_main(cnt, commands[i].argv); if (ret_code != 0) break; } } #else Doesn't need to be exactly like that, but some sort of hook to be made available so that I can bypass system() or any variation of that. C90 doesn't guarantee that system() will do anything in particular. And my C environment indeed doesn't work too well if you try that. Can't have two programs opening and closing the same DDNAME. Can only have 100 characters worth of parameters too. 2. A completely different way of handling include files. After going through the normal remap process, I then want the following transformations: #include "fred.h" gets translated into an fopen("dd:include(fred)", "r") #include gets translated into an fopen("dd:sysincl(fred)", "r") None of this checking to see if something is a directory etc. There's no such call available in C90, nor my C library on MVS. The code above looks trivial enough, but when it's time to actually find where to put that, it's non-trivial. 3. There is some complicated parameter lookup facility - it does a binary search on the parameters. This requires a whole lot of infrastructure to be present to generate the code. Infrastructure which I don't have. I'd like a simple sequential search to be available as an option I can activate. 4. There are a whole lot of includes that don't exist, like sys/types.h, and I'd like them to be masked out like all other includes are done (even things that are part of C90 have masks!!!). 5. It'd be cool if some of the names could be unique in the first 8 characters (C90 guarantees 6 for externals, but I have the luxury of 8). I have a mostly non-intrusive way of remapping everything, but there are a few that I need to do intrusively, because I can't #define away something that is already #defined. Problem is compounded by the fact that I link together code that normally isn't linked together. Note that I don't need things like an assembler and linker linked in together - I just need the stuff required for the "-S" option to work. ie text file (ie C code) in, and text file (ie assembler code) out - a text processing program that should be (and in fact, has already been made that way) possible to do in pure C90. 6. It would be nice if all the non-C90 Posix functions were masked out, but so far I have been able to kludge around that without requiring a lot of intrusive changes. It would be good to get the worst of them out though. My questions are: 1. Are changes like the above likely to be accepted into the head version going forward? 2. If they are, what version should I work on to get that to happen? Ideally I'd like to work on a stable version, perhaps 4.4, and later have those changes merged onto the head. But I fear if I do that I will end up in the same position I am in now with 3.4.6, ie too many changes such that my patches are never actually relevant. But it's quite daunting to get this working at all. So I thought that what I might be able to do instead is get the hooks in place first. Not necessarily all at once. Possibly over the course of a year. Eventually all the hooks will exist, there will be a stable release cut containing all the hooks I need, and then I may be in with a chance of getting i370 working on that environment. That would also be done over the course of a year or whatever, as the GMP and MPFR need to be set up on MVS too (just having a S/390 port is not sufficient - I need S/370 HLASM). Hopefully at the end of that process, I'll have an i370 port that is done in a "standard" way so that updating to the latest GCC is fairly trivial *regardless* of whether the i370 port is included in GCC proper due to the yet more technical challenges that requires, another job for another year. :-) This is a parallel effort to my 3.4.6 work which is done on a different PC at a different time. 3.4.6 is mostly about getting it to run on real MVS. 4.4/x is simply to get a cross-compile to work for now. Thanks. Paul.