Re: i370 port - constructing compile script

["Paul Edwards" <mutazilah at gmail dot com>]

> > I am happy to construct all of this on a Unix system with the various
> > tools (m4 etc) available.
> >
> > But from the Unix system, I need to be able to generate the
> > above very simple compile script, which is a precursor to creating
> > very simple JCL steps (trust me, you don't want to see what
> > ST2CMP looks like).  Note that the JCL has the filenames
> > truncated to 8 characters, listed twice, uppercased, and '-'
> > and '_' converted to '@'.
>
> Have you considered the obvious solution: Don't do that?
> i.e. use a cross compiler from a sane system. If you really want to a 
> native
> compiler than I still suggest building it as a canadian cross.

That's what this is.

Or at least, replace ST2CMP with ST1CMP and it is the Canadian Cross.

ST1CMP will run the assemblies using HLASM.

Almost identical JCL will run a compile, then an assemble with HLASM.

> My guess is
> that getting gcc hosted in a bizarre environment is much easier than 
> getting

Not so bizarre when so many of the Fortune 500 use it.

> the gcc build system working. Trying to bootstrap gcc there seems like a 
> lot
> of pain for no real benefit.

The effort is mostly in the Canadian Cross.  The changes to get it to
bootstrap from that point are relatively small.  The extra things
required are:

1. header.gcc to remap includes.
2. scripts to rename includes.
3. 20 lines of JCL in the stage 2 procs, to do compiles.

Here's the first of those from 3.4.6, so you can see the scope of
the work:

builtin-attrs.def builtina.h
builtin-types.def builtint.h
builtins.def builtind.h
c-common.def ccommond.h
diagnostic.def diagndef.h
machmode.def machmodd.h
params.def paramsd.h
predict.def predictd.h
rtl.def rtld.h
stab.def stabd.h
timevar.def timevard.h
tree.def treed.h
insn-constants.h i-constants.h
langhooks-def.h langhdef.h
hosthooks-def.h hosthdef.h
gt-dwarf2asm.h gt-dwasm.h
gcov-io.c gcovioc.h

It's now very rare to have a problem on the MVS EBCDIC host that
doesn't also occur on a Unix ASCII cross-compiler.

So for that extra bit of work, mainframers are able to modify the
C compiler on their native platform instead of having to mess
around with a Unix system they know nothing about.

Part of open source is making the source available and
usable on the native environment, I think.  Otherwise, the job
of providing a free, open source C compiler on the mainframe
hasn't really been done, I think.  And I was dreaming of that
way back in 1987 when I had a 3270 terminal plus a
mainframe.  Although admittedly I only wanted to use it, not
build it.  But the easier it is for a mainframer to access the
code, the more likely it is that they will be inspired to add
a PL/S or Cobol front-end to it.

BFN.  Paul.