Wow, what a lot of responses. Last time I tried making
contact, I didn't get a single response!
In addition, that code has been ported to GCC 3.4.6, which is now
working as a cross-compiler at least. It's still some months away
from working natively though. It takes a lot of effort to convert
the Posix-expecting GCC compiler into C90 compliance. This has
been done though, in a way that has minimal code changes to the
GCC mainline.
You're referring to building GCC for a non-Posix *host*, right?
Yep.
I assume those changes are not (primarily) in the back-end, but
throughout GCC common code?
Yes. Or rather, they would be, if it weren't for sleight-of-hand to
minimize that. I dummied up all the Posix calls to point back to
C90 functions.
Please take a look at the actual changes to GCC. There's not
a lot:
Here's the exact file:
https://sourceforge.net/project/downloading.php?group_id=195127&filename=gccmvs-3_2_3-7_0.zip&a=50206324
Most of the size is generated code from the md, or other new files,
and not changes to GCC proper.
However, in fact, GCC is turned on its head. It's a single executable.
C90 doesn't guarantee, and the host doesn't support, the ability to do
a fork() and exec().
Yes, I'm aware that there is an S/390 port, but it isn't EBCDIC, isn't
HLASM, isn't 370, isn't C90, isn't MVS. It may well be possible to
change all those things, and I suspect that in a few years from now
I may be sending another message asking what I need to do to get
all my changes to the s390 target into the s390 target. At that time,
I suspect there will be a lot of objection to "polluting" the s390 target
with all those "unnecessary" things.
Actually, I would really like to see the s390 target optionally support
the MVS ABI and HLASM assembler format, so I wouldn't have any objection
to patches that add these features ...
Great.
I understand current GCC supports various source and target character
sets a lot better out of the box, so it may be EBCDIC isn't even an
issue any more.
It looks that way from what I've seen of 3.4.6 so far. However, I
won't know for sure until it's on the host and self-generating.
If there are other problems related to MVS host
support, I suppose those would need to be fixed in common code anyway,
no matter whether the s390 or i370 back-ends are used.
Well, I would like to see that - I don't know why there are all
those calls to open() instead of fopen() etc in the first place,
but I don't see that happening.
The only point in your list I'm sceptical about is 370 architecture
support -- I don't quite see why this is still useful today (the s390
port does require at a minimum a S/390 G2 with the branch relative
instructions ... but those have been around for nearly 15 years).
The last free MVS was MVS 3.8j which runs on the S/370 architecture.
If you want to write MVS software, for free, your only option is to
pick that up. It doesn't run on S/390 hardware.
However. :-)
That's where MVS/380 comes in.
http://mvs380.sourceforge.net
So yes, we can sort of cope with S/390 instructions. It's just not as
widely supported as the proper S/370 (emulated) machine. Or rather,
I think we can. It's into unchartered territory what restrictions
S/380 actually has in its current form. It's known that it's enough to
run 31-bit GCC using 20 MB of memory though. Which again, is a
damn good start.
BFN. Paul.
