i370 port

[Paul Edwards-9]

Hello GCC maintainers.

There used to be an i370 target for GCC.  It was written in 1989,
and put into GCC 2.5 in 1993.

It has always been semi-working, but never good enough to
actually use.

It was dropped from GCC 4 when there was supposedly no
maintainer available.  Actually, Dave Pitts and myself were
both maintaining it at that time, but we were both still working
on an old version of it (3.2). So gcc 3.4.6, circa 2004, was the
last time it was included in the normal GCC distribution.

We were both maintaining it, and continue to maintain it,
because MVS doesn't have any alternate free C compiler
available.

As of yesterday, after years of work, an i370 version was
released that is now fully working.  The code generator has
no known bugs that would stop it from being C90-compliant,
and GCC can fully regenerate itself, with full optimization.  

You can see it here:

http://gccmvs.sourceforge.net

It's based on GCC 3.2.3.

There is also a free i370 emulator (Hercules) and a free i370-based
operating system (MVS/380) that enables the compiler to be fully
tested and fully regenerate itself on its native environment.  Not
only that, but there is an effort underway to allow this free
environment to be made available on the internet so that Unix
users can do an MVS build (takes around 4 hours if done properly
- ie 3 stage, full optimization, on an emulated machine), from the
safety of their Unix box.

Both of those products are also under active development by a
community of mainframe enthusiasts.

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.

There is a lot of other activity (e.g. availability of REXX, PL/1, Cobol)
that rests on the C compiler being available.

So, my question is - what is required to get the i370 port reinstated
into the GCC mainline?

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.

So, here's hoping that the i370 port can end up where it was originally
intended to end up, and that all the effort that was spent in the GCC
mainline to get rid of the ASCII assumptions can now be put to good
use.

BFN.  Paul.

[Joseph S. Myers]

On Fri, 5 Jun 2009, Paul Edwards wrote:

> It was dropped from GCC 4 when there was supposedly no
> maintainer available.  Actually, Dave Pitts and myself were
> both maintaining it at that time, but we were both still working
> on an old version of it (3.2). So gcc 3.4.6, circa 2004, was the
> last time it was included in the normal GCC distribution.

(For reference, the port was removed in SVN revision 77216; before then it
had had various largely mechanical changes as part of changes to multiple
back ends or target-independent code, with r69086 as the last vaguely
i370-only change but no changes appearing to come from someone
specifically working and testing on i370 for some years before then.  "svn
log svn://gcc.gnu.org/svn/gcc/trunk/gcc/config/i370@77215" shows the
history.)

> We were both maintaining it, and continue to maintain it,
> because MVS doesn't have any alternate free C compiler
> available.

To merge back into FSF GCC, the people who have made changes that would be
merged back will need to have copyright assignments on file at the FSF
(and disclaimers from any relevant employers).  I don't have a current
copy of the assignments list (my very old copy does show assignments from
David G. Pitts with an employer disclaimer dating from 1993).

> So, my question is - what is required to get the i370 port reinstated
> into the GCC mainline?

The basic requirements for a resurrected port are the same as for a new
port; it needs to be assigned to the FSF, to pass the normal technical
review, and the SC needs to approve someone as a maintainer of the port
(there may be a bottleneck with the last stage, since there are currently
at least three new ports pending approval).  It is a very good idea if you
can run the testsuite for the port and will be posting results to
gcc-testresults regularly.

I would encourage going through all the changes made to the i370 port on
GCC mainline, after 3.1/3.2 branched and before the port was removed, to
see what should be merged into your version for mainline; ultimately it
would be up to you how you get it updated for all the mechanical changes
on mainline since 3.2, but those changes (see command above to get logs)
may be a useful guide to how to do some of the updates.

--
Joseph S. Myers
joseph@...

[Paul Edwards-9]

>> We were both maintaining it, and continue to maintain it,
>> because MVS doesn't have any alternate free C compiler
>> available.
>
> To merge back into FSF GCC, the people who have made changes that would be
> merged back will need to have copyright assignments on file at the FSF
> (and disclaimers from any relevant employers).  I don't have a current
> copy of the assignments list (my very old copy does show assignments from
> David G. Pitts with an employer disclaimer dating from 1993).

There's only 3 people who have made changes.  Dave Pitts, Linas
Vepstas and myself.  Dave you already have apparently.  Linas's
code is largely already merged - just his last set of changes didn't
get put in.  That leaves me.  I work as a contractor and I'd probably
be sacked if I tried to either bring in or attempt to maintain gcc.
All my work was done at home.

>> So, my question is - what is required to get the i370 port reinstated
>> into the GCC mainline?
>
> The basic requirements for a resurrected port are the same as for a new
> port; it needs to be assigned to the FSF, to pass the normal technical
> review, and the SC needs to approve someone as a maintainer of the port
> (there may be a bottleneck with the last stage, since there are currently
> at least three new ports pending approval).  It is a very good idea if you
> can run the testsuite for the port and will be posting results to
> gcc-testresults regularly.

The port is to a pure C90 environment (ie not posix, not unix).  It was a
major effort to achieve that, and it has only just been completed to the
point where the compiler recompiles itself with full optimization.  The
environment where it runs is not set up to run shell scripts or makes
or test suites.  It's set up to run JCL, and there's a stack of JCL card
decks to allow GCC to compile, which would be good to have included
in the i370 directory.

It's difficult enough just to get GCC to know to open dd:include(xxx)
for an include of "xxx.h" and dd:sysincl(xxx) for an include of <xxx.h>.
That logic was revamped in gcc 3.4.6 so I haven't put it in yet.  It'll
probably be months before I do that, because I can't test it until it
gets up onto the mainframe.  And once again, in preparation for that,
I need to make it a pure C90 application.  So that is where I spend
my effort.

Note that the i370 port used to be in GCC even though it was riddled
with bugs.  It took literally years to get rid of them.  I would have
thought that GCC recompiling itself was a damn good start for
inclusion, irrespective of any test suites (assuming those test
suites are even C90 code - as they would need to be to work).

> I would encourage going through all the changes made to the i370 port on
> GCC mainline, after 3.1/3.2 branched and before the port was removed, to
> see what should be merged into your version for mainline; ultimately it
> would be up to you how you get it updated for all the mechanical changes
> on mainline since 3.2, but those changes (see command above to get logs)
> may be a useful guide to how to do some of the updates.

I have already merged the changes made from 3.2.3 to 3.4.6 into my
code, and have a diff against 3.4.6 available already.  ie, that covers
all known code changes.  But it only works as a cross-compiler at the
moment.  It's probably a few months away from being native.

BFN.  Paul.

[Joseph S. Myers]

On Sat, 6 Jun 2009, Paul Edwards wrote:

> The port is to a pure C90 environment (ie not posix, not unix).  It was a
> major effort to achieve that, and it has only just been completed to the
> point where the compiler recompiles itself with full optimization.  The
> environment where it runs is not set up to run shell scripts or makes
> or test suites.  It's set up to run JCL, and there's a stack of JCL card
> decks to allow GCC to compile, which would be good to have included
> in the i370 directory.

You can test a cross compiler if you have some way of copying a test
executable to the i370 system, running it and getting its output and exit
status back (actually you don't need to be able to get the exit status
since DejaGnu has wrappers to include it in the output if needed).  There
is no need for the target to be able to run shell scripts or makes.  You
would need to write your own DejaGnu board file that deals with copying
to/from the i370 system and running programs there.  The testsuite
routinely runs for much more limited embedded systems (using appropriate
board files).

--
Joseph S. Myers
joseph@...

[Ulrich Weigand]

Paul Edwards wrote:

> 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?
I assume those changes are not (primarily) in the back-end, but
throughout GCC common code?

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

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

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).

Bye,
Ulrich

--
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@...

[Paul Edwards-9]

>> The port is to a pure C90 environment (ie not posix, not unix).  It was a
>> major effort to achieve that, and it has only just been completed to the
>> point where the compiler recompiles itself with full optimization.  The
>> environment where it runs is not set up to run shell scripts or makes
>> or test suites.  It's set up to run JCL, and there's a stack of JCL card
>> decks to allow GCC to compile, which would be good to have included
>> in the i370 directory.
>
> You can test a cross compiler if you have some way of copying a test
> executable to the i370 system

It doesn't build executables either.

Only the "-S" option is used.

With that restriction, GCC merely reads a bunch of text files and
writes a text file, and thus is amenable to being a pure C90
application.  That's how it manages to work at all.

> running it and getting its output and exit
> status back (actually you don't need to be able to get the exit status
> since DejaGnu has wrappers to include it in the output if needed).  

It so happens that MVS/380 has the ability to be run in batch, and
extracting the exit code won't be a problem either.

Note however that I normally do all my GCC work in Windows,
and the batch running etc is done with batch files.

> There
> is no need for the target to be able to run shell scripts or makes.  You
> would need to write your own DejaGnu board file that deals with copying
> to/from the i370 system and running programs there.  The testsuite
> routinely runs for much more limited embedded systems (using appropriate
> board files).

I have a large backlog of work to do with the i370 port already, starting
with getting gcc 3.4.6 running natively.  Isn't that a more productive
thing to do?  Even after 3.4.6 is done, so that every scrap of code is
available, then there's version 4 to do!

BFN.  Paul.

[Paul Edwards-9]

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.

[Joseph S. Myers]

On Fri, 5 Jun 2009, Ulrich Weigand wrote:

> 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.   If there are other problems related to MVS host

I think the EBCDIC support is largely theoretical and not tested on any
actual EBCDIC host (or target).  cpplib knows the character set name
UTF-EBCDIC, but whenever it does anything internally that involves the
encoding of its internal character set it uses UTF-8 rules (which is not
something valid to do with UTF-EBCDIC).

--
Joseph S. Myers
joseph@...

[Joseph S. Myers]

On Sat, 6 Jun 2009, Paul Edwards wrote:

> > There is no need for the target to be able to run shell scripts or makes.
> > You would need to write your own DejaGnu board file that deals with copying
> > to/from the i370 system and running programs there.  The testsuite routinely
> > runs for much more limited embedded systems (using appropriate board files).
>
> I have a large backlog of work to do with the i370 port already, starting
> with getting gcc 3.4.6 running natively.  Isn't that a more productive
> thing to do?  Even after 3.4.6 is done, so that every scrap of code is
> available, then there's version 4 to do!

It's up to you what priorities you assign to different things involved in
getting this on mainline, but we use test results postings as evidence of
what sort of state each port is in, where a particular test failure is
appearing and whether each port is being used, so there may be reluctance
to accept a port that will not have test results posted regularly for
mainline.  (This is much less of a problem for OS ports than for CPU
ports; if one OS for a given CPU has results routinely posted, it doesn't
matter so much if other OSes don't, though having results for different
OSes is still useful.)

--
Joseph S. Myers
joseph@...

[Daniel Jacobowitz-2]

On Sat, Jun 06, 2009 at 01:39:07AM +1000, Paul Edwards wrote:
>> 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.

Why are you migrating to 3.4.6 now, instead of to a current version?
If you want to include this in mainline some day, then eventually it
has to be caught up - and 3.4.6 is older than it may appear from the
release date, since it branched off of mainline five years ago.  A lot
has changed since then.

--
Daniel Jacobowitz
CodeSourcery

[Paul Edwards-9]

>> 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.   If there are other problems related to MVS host
>
> I think the EBCDIC support is largely theoretical and not tested on any
> actual EBCDIC host (or target).  cpplib knows the character set name
> UTF-EBCDIC, but whenever it does anything internally that involves the
> encoding of its internal character set it uses UTF-8 rules (which is not
> something valid to do with UTF-EBCDIC).

From the hercules-os380 files section, here's the relevant change
to 3.4.6 to stop it being theoretical:

Index: gccnew/gcc/cppcharset.c
diff -c gccnew/gcc/cppcharset.c:1.1.1.1 gccnew/gcc/cppcharset.c:1.6
*** gccnew/gcc/cppcharset.c:1.1.1.1 Wed Apr 15 16:26:16 2009
--- gccnew/gcc/cppcharset.c Wed May 13 11:07:08 2009
***************
*** 23,28 ****
--- 23,30 ----
  #include "cpplib.h"
  #include "cpphash.h"
  #include "cppucnid.h"
+ #include "coretypes.h"
+ #include "tm.h"

  /* Character set handling for C-family languages.

***************
*** 529,534 ****
--- 531,561 ----
    return conversion_loop (one_utf32_to_utf8, cd, from, flen, to);
  }

+ #ifdef MAP_OUTCHAR
+ /* convert ASCII to EBCDIC */
+ static bool
+ convert_asc_ebc (iconv_t cd ATTRIBUTE_UNUSED,
+          const uchar *from, size_t flen, struct _cpp_strbuf *to)
+ {
+   size_t x;
+   int c;
+
+   if (to->len + flen > to->asize)
+     {
+       to->asize = to->len + flen;
+       to->text = xrealloc (to->text, to->asize);
+     }
+   for (x = 0; x < flen; x++)
+     {
+       c = from[x];
+       c = MAP_OUTCHAR(c);
+       to->text[to->len + x] = c;
+     }
+   to->len += flen;
+   return true;
+ }
+ #endif
+
  /* Identity conversion, used when we have no alternative.  */
  static bool
  convert_no_conversion (iconv_t cd ATTRIBUTE_UNUSED,
***************
*** 606,611 ****
--- 633,641 ----
    { "UTF-32BE/UTF-8", convert_utf32_utf8, (iconv_t)1 },
    { "UTF-16LE/UTF-8", convert_utf16_utf8, (iconv_t)0 },
    { "UTF-16BE/UTF-8", convert_utf16_utf8, (iconv_t)1 },
+ #if defined(TARGET_EBCDIC)
+   { "UTF-8/UTF-EBCDIC", convert_asc_ebc, (iconv_t)0 },
+ #endif
  };

  /* Subroutine of cpp_init_iconv: initialize and return a
***************
*** 683,688 ****
--- 713,722 ----

    bool be = CPP_OPTION (pfile, bytes_big_endian);

+ #if defined(TARGET_EBCDIC)
+   ncset = "UTF-EBCDIC";
+   wcset = "UTF-EBCDIC";
+ #else
    if (CPP_OPTION (pfile, wchar_precision) >= 32)
      default_wcset = be ? "UTF-32BE" : "UTF-32LE";
    else if (CPP_OPTION (pfile, wchar_precision) >= 16)
***************
*** 696,701 ****
--- 730,736 ----
      ncset = SOURCE_CHARSET;
    if (!wcset)
      wcset = default_wcset;
+ #endif

    pfile->narrow_cset_desc = init_iconv_desc (pfile, ncset,
SOURCE_CHARSET);
    pfile->wide_cset_desc = init_iconv_desc (pfile, wcset, SOURCE_CHARSET);


The generated code appears to be fine from visual inspection.

BFN.  Paul.

[Paul Edwards-9]

>>> 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.
>
> Why are you migrating to 3.4.6 now, instead of to a current version?
> If you want to include this in mainline some day, then eventually it
> has to be caught up - and 3.4.6 is older than it may appear from the
> release date, since it branched off of mainline five years ago.  A lot
> has changed since then.

3.4.6 made some revamps to the i370 port (compared to 3.2.3), and I
need to make sure those changes have been digested, and no code
has been lost, so that I can pick up the final i370 port and move it.

It's less daunting to get 3.4.6 working first.  At least there the target
actually exists and does obstensibly appear to work!

Migrating from 3.4.6 to 4.x is not going to be made any bigger a deal.
It's not like someone else is making incompatible changes to the
i370 port at the same time as me!

BFN.  Paul.

[Joseph S. Myers]

On Sat, 6 Jun 2009, Paul Edwards wrote:

> 3.4.6 made some revamps to the i370 port (compared to 3.2.3), and I
> need to make sure those changes have been digested, and no code
> has been lost, so that I can pick up the final i370 port and move it.

But there were probably also (mechanical) changes to the port between when
3.4 branched (long before 3.4.6 was released) and when the port was
removed from trunk - that's why the last revision before it was removed
from trunk may be a better starting point.

--
Joseph S. Myers
joseph@...

[Paul Edwards-9]

>> 3.4.6 made some revamps to the i370 port (compared to 3.2.3), and I
>> need to make sure those changes have been digested, and no code
>> has been lost, so that I can pick up the final i370 port and move it.
>
> But there were probably also (mechanical) changes to the port between when
> 3.4 branched (long before 3.4.6 was released) and when the port was
> removed from trunk - that's why the last revision before it was removed
> from trunk may be a better starting point.

Ok, I understand now.  So there were some changes, that would
nominally have made it to GCC 4, but were in fact never officially
released, because it was dropped before release.

So, prior to starting a GCC 4 port (ie the changes may not be
desirable for the GCC 3.4.6 port I am currently working on), I
need to get GCC 3.4 as a base, GCC 3.4.6 as one derivative,
and SVN 77215, then do a 3-way diff/merge to obtain the
"nominal GCC 4" changes.

Or perhaps not.

I don't want the 3.4.6 changes at that point, since anything of
value will be covered by SVN 77215.  So I need to use GCC 3.4.6
as the base, my personal version as one derivative, SVN 77215
as the second derivative, and feed that into the 3-way diff.

Ok, I'll do that when I'm in a position to do the GCC 4 port
attempt.  I'm still months away from completing the GCC 3.4.6
port, and there are other MVS-related projects that are more
important than what is basically a transparent 3.2.3 to 4
upgrade that will only start being useful when it enables something
else to happen (such as the PL/1 front-end).

So I'll be working on that stable 3.4.6 before taking my chances
with what is basically an axed beta (SVN 77215), with still no
indication of whether even a perfectly working self-compiling
i370 target will be accepted unless the testsuite is working first
(and even if it was working, that still may not be enough - as
the next hoop may be an s390 merge - and a requirement to
switch from 370 to 390).

BFN.  Paul.

[Paul Edwards-9]

> Why are you migrating to 3.4.6 now, instead of to a current version?
> If you want to include this in mainline some day, then eventually it
> has to be caught up - and 3.4.6 is older than it may appear from the
> release date, since it branched off of mainline five years ago.  A lot
> has changed since then.

A question about those changes.

One of the things that I experienced when porting 3.2.3 to MVS
was that GCC was sensitive to the exact floating point representation.

Register selection was different depending on those slight differences.

Below is what documentation I have for it.  Dave Edwards, who
wrote another S/370 emulator, was the one who discovered that.

Does anyone know if that was changed somewhere along the line?

BFN.  Paul.



17. The assembler code generated by gccmvs when run on the
PC is slightly different (even when the same parameters
are used for code generation) from that when run on the
mainframe, if -O2 is used instead of -Os. But functionally
equivalent. This non-deterministic nature of the compiler
is disconcerting. It seems to not always allocate registers
consistently. This has been traced to floating point code
in predict.c and local-alloc.c which is sensitive to the
very small changes in floating point representation. This
should be changed to include deltas when comparing floating
point values. Here's an example of what's happening:

*** c-lex.s Mon Jan 14 20:48:35 2008
--- temp.dat Mon Jan 14 21:14:04 2008
***************
*** 1328,1335 ****
           SLR   15,15
           STC   15,0(3,4)
           SLR   6,6
-          LR    9,6
           LR    8,6
           L     2,192(13)
           CLR   2,5
           BNL   L303
--- 1328,1335 ----
           SLR   15,15
           STC   15,0(3,4)
           SLR   6,6
           LR    8,6
+          LR    9,6
           L     2,192(13)
           CLR   2,5
           BNL   L303

[Ulrich Weigand]

Paul Edwards wrote:

> One of the things that I experienced when porting 3.2.3 to MVS
> was that GCC was sensitive to the exact floating point representation.
>
> Register selection was different depending on those slight differences.
>
> Below is what documentation I have for it.  Dave Edwards, who
> wrote another S/370 emulator, was the one who discovered that.
>
> Does anyone know if that was changed somewhere along the line?
>
> BFN.  Paul.
>
>
>
> 17. The assembler code generated by gccmvs when run on the
> PC is slightly different (even when the same parameters
> are used for code generation) from that when run on the
> mainframe, if -O2 is used instead of -Os. But functionally
> equivalent. This non-deterministic nature of the compiler
> is disconcerting. It seems to not always allocate registers
> consistently. This has been traced to floating point code
> in predict.c and local-alloc.c which is sensitive to the
> very small changes in floating point representation. This
> should be changed to include deltas when comparing floating
> point values. Here's an example of what's happening:

I agree that GCC output should not depend on details of the host
floating point representation.  (Ideally, the output of GCC built
as a cross-compiler should not depend on the host architecture
at all.)

However, it is hard to say whether such observations made on a
GCC 3.2 code base have any relevance to the current code -- for
example, local-alloc.c does not even exist any more, we now have
a completely new register allocator.

I'd recommend you go ahead with a port to current mainline and
verify whether you still see problems along those lines; if so,
it would be appropriate to open a bug report against GCC.

Bye,
Ulrich

--
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@...

[Paul Edwards-9]

Hi guys.

The last class of warning I have from the machine definition is this:

./config/i370/i370.md:784: warning: destination operand 0 allows non-lvalue

which is because I have used r_or_s_operand like this:

;
; movdi instruction pattern(s).
;

(define_insn ""
  [(set (match_operand:DI 0 "r_or_s_operand" "=dm,dS")
        (match_operand:DI 1 "r_or_s_operand" "dm*fF,i"))]
  "TARGET_CHAR_INSTRUCTIONS"
  "*
{
  check_label_emit ();
  if (REG_P (operands[0]))

and I believe what is happening is that r_or_s_operand allows
a constant.

But sometimes r_or_s_operand is being used as a source, in
which case, the constant is fine.  But when it is used as a
destination, it is not fine.

What is the *simplest* way of changing the setup so that the
code generation remains the same, but the warning is eliminated?

Note that this is 3.2.3 and I'm not wanting to restructure the
whole thing to be the same as s390.md.  I am thinking I can
define something like r_or_s_lval_operand which would be
the same as r_or_s_operand except not allow constants.

But wondering if there's something simpler and neater.

Thanks.  Paul.

[Ulrich Weigand]

Paul Edwards wrote:

> But sometimes r_or_s_operand is being used as a source, in
> which case, the constant is fine.  But when it is used as a
> destination, it is not fine.
>
> What is the *simplest* way of changing the setup so that the
> code generation remains the same, but the warning is eliminated?

Well, I guess you need to do two things:

- Define the PREDICATE_CODES macro -- if this is undefined,
  genrecog will consider *any* target-defined predicate as
  potentially allowing non-lvalues, because it cannot know
  better.

- Actually define two distinct predicates, one that allows
  non-lvalue and one that doesn't, and use them as appropriate.

> But wondering if there's something simpler and neater.

Well, you could also simply ignore the warning -- nothing
is going to go wrong because of it.

Bye,
Ulrich

--
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@...

[Paul Edwards-9]

>> But sometimes r_or_s_operand is being used as a source, in
>> which case, the constant is fine.  But when it is used as a
>> destination, it is not fine.
>>
>> What is the *simplest* way of changing the setup so that the
>> code generation remains the same, but the warning is eliminated?
>
> Well, I guess you need to do two things:
>
> - Define the PREDICATE_CODES macro -- if this is undefined,
>  genrecog will consider *any* target-defined predicate as
>  potentially allowing non-lvalues, because it cannot know
>  better.
>
> - Actually define two distinct predicates, one that allows
>  non-lvalue and one that doesn't, and use them as appropriate.
>
>> But wondering if there's something simpler and neater.
>
> Well, you could also simply ignore the warning -- nothing
> is going to go wrong because of it.

Thanks for pointing me in the right direction Ulrich.  Unfortunately
just short of what would have been best for this situation.

I defined the PREDICATE_CODES macro and put in the things
I thought were appropriate:

C:\devel\gcc\gcc\config\i370>cvs diff -r 1.33 -r 1.34 i370.h
Index: i370.h
===================================================================
RCS file: c:\cvsroot/gcc/gcc/config/i370/i370.h,v
retrieving revision 1.33
retrieving revision 1.34
diff -r1.33 -r1.34
200a201,204
> #define PREDICATE_CODES \
>   {"r_or_s_operand", { REG, SUBREG, MEM, CONST_INT }}, \
>   {"s_operand", { MEM, CONST_INT }},
>

It had no effect on anything that I could see, but that was to be expected.

I then had a closer look at the machine definitions and realised that some
of them that were defined as r_or_s_operand could instead be
nonimmediate_operand, which started eliminating warnings.

So I proceeded down this track, eliminating things here and there, or
in some cases, opening things up to be more general, with the hope
that I would eventually have things so that the only r_or_s_operand
I needed were ones that didn't require literals, so that I could (at the
end), make this change:

C:\devel\gcc\gcc\config\i370>cvs diff -r 1.34 -r 1.35 i370.h
Index: i370.h
===================================================================
RCS file: c:\cvsroot/gcc/gcc/config/i370/i370.h,v
retrieving revision 1.34
retrieving revision 1.35
diff -r1.34 -r1.35
202,203c202,203
<   {"r_or_s_operand", { REG, SUBREG, MEM, CONST_INT }}, \
<   {"s_operand", { MEM, CONST_INT }},
---
>   {"r_or_s_operand", { REG, SUBREG, MEM }}, \
>   {"s_operand", { MEM }},

and something similar in i370.c, to make constants invalid, so that I
could eliminate the warnings.

It took a month to do that, because I kept on being hit by presumed
bugs, which started generating bad or unexpected code when I made
a seemingly innocuous change.  To make matters worse, sometimes
I could only find out whether the code was good or not by running it on
MVS, via the emulator, which means a 2 hour wait for a result.

However, I did get it down to just a handful of warnings, which would
be eliminated now that I could drop the CONST_INT.  And I would
check the generated code to see what I had missed when I took
off the CONST_INT.

Anyway, I took off the CONST_INT, and the warnings all disappeared,
and the code didn't change!

I then found out that even with old versions of the machine definition,
I can have the warning removed by simply not defining CONST_INT
in the PREDICATE_CODES, even though it is allowed when the
function is called.  ie it seems to have no effect on the code
generation, but succeeds in eliminating the warning, and without
needing to define an extra constraint for non-constant situations.

So I've revamped the machine definition unnecessarily.  Well, I
did make things defined more consistently, and did make code
generation improvements, but they're not major, and I wouldn't
have done any of it if I knew I could have just defined a predicate
that wasn't really going to be used.

Oh well.  At the end of the day, the warning has gone, the code
is better and the machine definition is more correct.  :-)

I've also got 3.4.6 working to some extent.  I have managed to
build an single GCC executable, and if I call it with no parameters,
it prints its usage (as designed).

However, if I try to pass parameters it doesn't recognize them.
It could be something to do with not having run the appropriate
stuff through bison (or flex) on an EBCDIC platform.

Normally I use this to get around that problem:

C:\devel\gccnew\gcc>cvs diff -r release-3_4_6 c-parse.c
Index: c-parse.c
===================================================================
RCS file: c:\cvsroot/gccnew/gcc/c-parse.c,v
retrieving revision 1.1.1.1
retrieving revision 1.4
diff -r1.1.1.1 -r1.4
497a498,503
> #if defined(__MVS__) || defined(__CMS__)
> #define YYTRANSLATE(YYX)                      \
>   ((unsigned int) (YYX) <= YYMAXUTOK ? \
>   ((unsigned int) (YYX) < 256 ? yytranslate[_sch_ebcasc[YYX]] \
>   : yytranslate[YYX]) : YYUNDEFTOK)
> #else
499a506
> #endif

But perhaps the new gengtyp lex and yacc, although not used in the
actual GCC executable, are causing a problem by being run on the
ASCII machine.

Next step is to see if I can run the generated files all on MVS so
that that is eliminated from the equation.  Since I actually do have
an EBCDIC flex and bison available now (thanks to 3.2.3).

I also had problems with 3.4.6 when I switched on optimization.
A couple of internal errors popped up, which will presumably
trace back to the i370 code, but be outside my knowledge to
fix.

BFN.  Paul.

[Ulrich Weigand]

Paul Edwards wrote:

> I then found out that even with old versions of the machine definition,
> I can have the warning removed by simply not defining CONST_INT
> in the PREDICATE_CODES, even though it is allowed when the
> function is called.  ie it seems to have no effect on the code
> generation, but succeeds in eliminating the warning, and without
> needing to define an extra constraint for non-constant situations.

Actually PREDICATE_CODES does have to match the predicate definitions.
If it does not, you can run into subtle bugs, as the code in genrecog.c
that generates the finite state automaton matching an RTX pattern
against the .md insn definitions *does* make use of PREDICATE_CODES;
for example, it will assume that two predicates with disjoint sets
of PREDICATE_CODES can never both match the same RTX.

This may or may not lead to visible differences when compiling simple
test cases, but I'd expect effects to be visible in more complex
scenarios.

Bye,
Ulrich

--
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@...