Re: i370 port

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

Hi Joseph. (reviving a thread from 2009)

I have been streamlining the execution
of MVS (i370) via my "runmvs" script
recently, and now it only takes a few
seconds to do a test on MVS because
I have taken out all the unnecessary
pauses and made lots of other
improvements, and bypassing bugs
in Hercules.

Numerous other i370 bugs have been
fixed in GCC 3.2.3 too.

So I decided it was time to take a look
at the test suite to see what state that
was in.

With the aid of a script (below), I got
the following results:

C:\devel\gcc\gcc\config\i370\test>showres

C:\devel\gcc\gcc\config\i370\test>grep passed results.txt   | wc
   516    1032   10278

C:\devel\gcc\gcc\config\i370\test>grep failed results.txt   | wc
   117     234    2373

C:\devel\gcc\gcc\config\i370\test>


I looked at the first few errors. One
was deficiencies with "long long"
which is currently in the "too hard"
basket.

Some were ASCII assumptions (the
i370 port is EBCDIC).

And there was a genuine bug which I
have passed on to Dave Pitts for
analysis.

Regarding the ASCII errors, here’s an
example:

C:\devel\gcc\gcc\testsuite\gcc.c-torture\execute>type 20000412-3.c
typedef struct {
 char y;
 char x[32];
} X;

int z (void)
{
 X xxx;
 xxx.x[0] =
 xxx.x[31] = '0';
 xxx.y = 0xf;
 return f (xxx, xxx);
}

int main (void)
{
 int val;

 val = z ();
 if (val != 0x60)
   abort ();
 exit (0);
}

int f(X x, X y)
{
 if (x.y != y.y)
   return 'F';

 return x.x[0] + y.x[0];
}


They have assumed that '0' is 0x30,
but on EBCDIC it is 0xf0.

The documentation says:

C:\devel\gcc\gcc\testsuite>grep PORTABLE readme.gcc
DO NOT PUT NON-PORTABLE TESTCASES IN gcc.c-torture.


So what do you suggest I do with this class
of error?

The choices seem to be:

1. Remove/ignore it as it is non-portable so
shouldn't be there in the first place.

2. Create a new internal define like __EBCDIC__
and if that is set, do something different.

3. Create a user-define like -DEBCDIC to be
tested.

4. Do something like:

#if '0' == 0x30

(untested)

5. Use an existing define, like __MVS__
and if that is set, do something-or-other.


Any suggestions?

I know 3.2.3 is very old, but this is a very
long road, and this is where the most
stable i370.md environment is.

BTW, I saw someone mention something
about a "compile farm". MVS/380 is a
freely available i370 platform which
allows you to run tests on MVS pretty
easily, if a time comes when people
want to run tests on MVS to see if
their code works on EBCDIC as C90
allows.

Here is what it looks like on my system:

Just call this script:

call mvsgccr cprog.c output.txt

and it produces an output file that
includes:

07.28.30 JOB    1  $HASP373 MVSGCCR  STARTED - INIT  3 - CLASS C - SYS BSP1
07.28.30 JOB    1  IEF403I MVSGCCR - STARTED - TIME=07.28.30
07.28.30 JOB    1  IEFACTRT - Stepname  Procstep  Program   Retcode
07.28.31 JOB    1  MVSGCCR    S1        CREATE    IEFBR14   RC= 0000
07.28.31 JOB    1 *IEF233A M 401,PCTOMF,,MVSGCCR,COMP
07.28.32 JOB    1  MVSGCCR    S1        COMP      GCCNOMM   RC= 0000
07.28.33 JOB    1  MVSGCCR    S1        ASM       ASMA90    RC= 0000
07.28.33 JOB    1  MVSGCCR    S1        LKED      IEWL      RC= 0000
07.28.33 JOB    1  MVSGCCR    S1        EXECC     CPROG     RC= 0000
07.28.33 JOB    1  IEF404I MVSGCCR - ENDED - TIME=07.28.33
07.28.33 JOB    1  $HASP395 MVSGCCR  ENDED

On a failure of a test case, this line:

07.28.33 JOB    1  MVSGCCR    S1        EXECC     CPROG     RC= 0000

changes to:

07.28.33 JOB    1  MVSGCCR    S1        EXECC     CPROG     RC= 0012


MVS is a very interesting environment
in my opinion, and it's cool to have
code working there too.

I was thinking that maybe for people
who don't wish to install MVS/380
or TK4- on their system, there could
be some sort of hacked ftp so that
people could go:

ftp some.site
put cprog.c
put go.txt (this hangs while the C
program is compiled)
get output.txt
bye

Or for the more generic case:
ftp some.different.site
put in.jcl
put in.zip
put go.txt (hangs possibly 10 minutes)
get output.txt
get out.zip
bye

(for when you wish to build an entire
application, like "sed", on MVS).

go.txt could have the required runmvs
command, such as:

runmvs in.jcl output.txt in.zip out.zip


Usage here:

C:\mvs380>runmvs
Usage runmvs jcl.file print.file [aux_input.file|none] 
[aux_output.file|none] [ascii|binary|rdwund|rdwvar|vart] [ascii|binary] 
[awstap.file|none]
e.g. runmvs compile.jcl output.txt world.c world.s ascii ascii
or runmvs buildgcc.jcl output.txt source.zip xmit.dat
default is for files (if provided) to be binary


BTW, is that the main testsuite I should
be running? There's 633 C files there. Is
that enough, given that I'm only building
and testing C, or should I also compile
the stuff in the "compile" directory at the
same level as "execute"?

Thanks. Paul.





C:\devel\gcc\gcc\config\i370\test>type onecomp.bat
rem this should be run in a directory under config/i370
copy ..\..\..\testsuite\gcc.c-torture\execute\%1 cprog.c
call mvsgccr cprog.c output.txt
grep "EXECC     CPROG     RC= 0000" output.txt
if errorlevel 1 goto bad
echo %1 passed >>results.txt
goto exit
:bad
echo %1 failed >>results.txt
:exit

C:\devel\gcc\gcc\config\i370\test>



C:\devel\gcc\gcc\config\i370\test>head dotests.bat
del results.txt

call onecomp 20000112-1.c
call onecomp 20000113-1.c
call onecomp 20000121-1.c
call onecomp 20000205-1.c
call onecomp 20000217-1.c
call onecomp 20000223-1.c
call onecomp 20000224-1.c
call onecomp 20000225-1.c

C:\devel\gcc\gcc\config\i370\test>





-----Original Message----- 
From: Joseph S. Myers
Sent: Saturday, June 6, 2009 1:02 AM
To: Paul Edwards
Cc: gcc@gcc.gnu.org
Subject: Re: i370 port

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@codesourcery.com