Re: i370 port - in search of hooks

["Paul Edwards" <mutazilah@gmail.com>]

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 <fred.h>

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.