Re: i370 port - constructing compile script

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

I tried again but I'm not making much progress.

Maybe I need to go further than Canada, let's say Alaska.

1. First I need to use my current build machine, Linux,
to first of all convert the i370.md into insn*.c files, then
generate an xgcc.  The xgcc would be capable of producing
i370 code so long as I use the "-S" option.  It doesn't really
matter how this xgcc was created (ie using non-C90
stuff like fork available on my build machine).

2. It is now (at the Alaskan stage) that I need a different sort
of config.h/auto-host.h that excludes things like fork.  I can
present my i370 include files here, that only include C90
functions.  It is at this stage that I need it to invoke xgcc
(still on the build machine), but it will be with the -S option,
so there will be no .o files (although I could perhaps fake
that via a scipt to keep "make" happy) and no executable
built.  The "fake" script could generate JCL at the same time.
The C90 library (for MVS) also needs to be cross-compiled
here.

3. Then I need to assemble all the assembler on real i370
(MVS).  It is at this point that a real host (ie on i370 MVS)
xgcc is built.

4. Then I can use that xgcc (on MVS) to compile arbitary
C programs.  Technically I could have had a requirement
for this i370-mvs host compiler to produce say sparc target
code.

All of the above ignores the bootstrap on MVS, which I know
is easy to add on later.

To fit into the standard Canadian Cross 3-step model, I need
to either collapse steps 2 and 3 into 1 theoretical step, executed
across 2 platforms (compile on one, assemble on another), or I
need to omit step 4, and say that I cannot target any platform
other than the host.  Which is fine by me anyway.  If combining
steps 2 and 3, we could ignore the fact that step 3 happens at
all, and assume that there is a theoretical machine that directly
executes assembler code.

I suspect that it will only take 20 lines or similar of intrusive
Makefile/shell script changes to shoe-horn my way into the
existing gcc methodology.  All I need to do is force it to use
my C90 headers at the right spot, so that it stops thinking
that I have fork etc, and stop it trying to build an executable.

Can someone tell me where to put those 20 lines?  I have been
playing around with something like this:

./configure --host=i370-mvspdp --enable-languages=c --with-local-prefix=/devel/pdos/pdpclib

but haven't been getting very far.

I have one more option, and in fact, maybe it's even a preference.

The C90-only library (PDPCLIB) I have on MVS is also on Linux,
and gives me advance warning of problems about to happen on
MVS.  As such, I could force the build machine to use this C90 library
to build the first xgcc.  Then the config file etc would be correct
for the next step.  Mostly correct, anyway.  It would probably get
the stack direction wrong instead of leaving it unknown.

What suggestions for a configure command that would come
closest to what I want?  Note that with the above host I had to
copy "ar" to "i370-mvspdp-ar" to get it to the stage of building
the xgcc.

Note - prior to this latest exercise, in order to get some initial
feedback, I had been manually constructing the auto-host
and using my manually-created compile script to compile.
But that's a pretty horrible life, when I'm pretty sure that a
judiciously-placed 20 lines of code and some nifty config
parameters for host and target will automate the thing.

Any suggestions that don't involve "forget about MVS - no-one
even knows how to spell MVS these days"?

Thanks.  Paul.