This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: i370 port

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

Results are finally in.

EBCDIC (or arbitrary character set) support was introduced in 3.4.6,
and continues to be the same today, correct?

I've just succeeded today in getting gcc 3.4.6 to self-compile on an
EBCDIC host.  :-)  That's after a gcc 3.4.6 ascii to ebcdic cross-compile.

It's fascinating to look back at what it took.  Note that there are still
some relatively minor cleanups I have yet to do, but it won't change


1. The generated (from machine definition) files are still generated on
the PC.

2. I am unable to do an optimized compile even as a cross-compile,
I get an internal error in this function:


static void
compute_hash_table_work (struct hash_table *table)
 if (!current_bb) /* +++ why are we getting NULL here? */
     printf("internal error in gcse\n");
 FOR_EACH_BB (current_bb)

and indeed, I can't see anything that would initialize that current_bb,
so it's not that surprising that it's NULL!

3. As with gcc 3.2.3, the compiler is still producing slightly different
results on the PC vs mainframe, probably still because of floating
point comparisons being done to select the next register to use
or something like that.

4. There is one thing that doesn't have proper ASCII to EBCDIC
translation being done - the __FUNCTION__ builtin.

So here is the code generated on the PC:

        COPY  PDPTOP
* Program text area
@@V1     EQU   *
        DC    X'78'
        DC    X'31'
        DC    X'32'
        DC    X'33'
        DC    X'0'
LC0      EQU   *
        DC    C'%s %d %s'
        DC    X'15'
        DC    X'0'
LC1      EQU   *
        DC    C'zatest.c'
        DC    X'0'
        DS    0F
* X-func x123 prologue
        B     FEN0
FEN0     EQU   *
        DROP  12
        BALR  12,0
        USING *,12
PG0      EQU   *
        LR    11,1
        L     10,=A(PGT0)
* Function x123 code
        MVC   88(4,13),=A(LC0)
        MVC   92(4,13),=A(LC1)
        MVC   96(4,13),=F'5'
        MVC   100(4,13),=A(@@V1)
        LA    1,88(,13)
        L     15,=V(PRINTF)
        BALR  14,15
* Function x123 epilogue
* Function x123 literal pool
        DS    0F
* Function x123 page table
        DS    0F
PGT0     EQU   *
        DC    A(PG0)

for this source:

#include <stdlib.h>

void x123(void)
   printf("%s %d %s\n", __FILE__, __LINE__, __FUNCTION__);

However, that anomaly is not integral to getting the compiler on the
mainframe, and once on the mainframe, the problem goes away
with the next pass.  :-)

I think the problem is this function:

c_make_fname_decl (tree id, int type_dep)

needs to call cpp_interpret_string or something like that to get
converted into EBCDIC.

There's not that much mainline code that needs to be changed. You can see for youself here:

The file is 250k compressed containing diffs, but most of them are
simply the generated files (which appear as new).  Here are the
real file changes:

diff -c gccnew/gcc/builtins.c: gccnew/gcc/builtins.c:1.3
diff -c gccnew/gcc/c-common.c: gccnew/gcc/c-common.c:1.2
diff -c gccnew/gcc/c-incpath.c: gccnew/gcc/c-incpath.c:1.3
diff -c gccnew/gcc/c-opts.c: gccnew/gcc/c-opts.c:1.2
diff -c gccnew/gcc/c-parse.c: gccnew/gcc/c-parse.c:1.5
diff -c gccnew/gcc/c-pch.c: gccnew/gcc/c-pch.c:1.3
diff -c gccnew/gcc/cppcharset.c: gccnew/gcc/cppcharset.c:1.6
diff -c gccnew/gcc/cpperror.c: gccnew/gcc/cpperror.c:1.2
diff -c gccnew/gcc/cppfiles.c: gccnew/gcc/cppfiles.c:1.7
diff -c gccnew/gcc/cpplib.h: gccnew/gcc/cpplib.h:1.2
diff -c gccnew/gcc/cppmacro.c: gccnew/gcc/cppmacro.c:1.2
diff -c gccnew/gcc/cppspec.c: gccnew/gcc/cppspec.c:1.3
diff -c gccnew/gcc/gcc.c: gccnew/gcc/gcc.c:1.6
diff -c gccnew/gcc/gcc.h: gccnew/gcc/gcc.h:1.2
diff -c gccnew/gcc/gcov-io.c: gccnew/gcc/gcov-io.c:1.2
diff -c gccnew/gcc/gcov-io.h: gccnew/gcc/gcov-io.h:1.2
diff -c gccnew/gcc/gcse.c: gccnew/gcc/gcse.c:1.3
diff -c gccnew/gcc/hwint.h: gccnew/gcc/hwint.h:1.2
diff -c gccnew/gcc/longlong.h: gccnew/gcc/longlong.h:1.2
diff -c gccnew/gcc/opts.c: gccnew/gcc/opts.c:1.2
diff -c gccnew/gcc/opts.h: gccnew/gcc/opts.h:1.3
diff -c gccnew/gcc/ gccnew/gcc/
diff -c gccnew/gcc/pretty-print.c: gccnew/gcc/pretty-print.c:1.2
diff -c gccnew/gcc/read-rtl.c: gccnew/gcc/read-rtl.c:1.2
diff -c gccnew/gcc/real.c: gccnew/gcc/real.c:1.3
diff -c gccnew/gcc/system.h: gccnew/gcc/system.h:1.2
diff -c gccnew/gcc/toplev.c: gccnew/gcc/toplev.c:1.3
diff -c gccnew/gcc/varasm.c: gccnew/gcc/varasm.c:1.2
diff -c gccnew/gcc/version.c: gccnew/gcc/version.c:1.2
diff -c gccnew/gcc/config/i370/i370-c.c: gccnew/gcc/config/i370/i370-c.c:1.2
diff -c gccnew/gcc/config/i370/i370-protos.h: gccnew/gcc/config/i370/i370-protos.h:1.2
diff -c gccnew/gcc/config/i370/i370.c: gccnew/gcc/config/i370/i370.c:1.23
diff -c gccnew/gcc/config/i370/i370.h: gccnew/gcc/config/i370/i370.h:1.15
diff -c gccnew/gcc/config/i370/ gccnew/gcc/config/i370/
diff -c gccnew/gcc/config/i370/linux.h: gccnew/gcc/config/i370/linux.h:
diff -c gccnew/gcc/config/i370/oe.h: gccnew/gcc/config/i370/oe.h:
diff -c gccnew/include/fnmatch.h: gccnew/include/fnmatch.h:1.2
diff -c gccnew/include/safe-ctype.h: gccnew/include/safe-ctype.h:
diff -c gccnew/include/sort.h: gccnew/include/sort.h:1.2
diff -c gccnew/include/xregex2.h: gccnew/include/xregex2.h:1.2
diff -c gccnew/libiberty/argv.c: gccnew/libiberty/argv.c:1.4
diff -c gccnew/libiberty/concat.c: gccnew/libiberty/concat.c:1.2
diff -c gccnew/libiberty/cplus-dem.c: gccnew/libiberty/cplus-dem.c:1.2
diff -c gccnew/libiberty/fdmatch.c: gccnew/libiberty/fdmatch.c:1.2
diff -c gccnew/libiberty/getpagesize.c: gccnew/libiberty/getpagesize.c:1.2
diff -c gccnew/libiberty/getpwd.c: gccnew/libiberty/getpwd.c:1.2
diff -c gccnew/libiberty/getruntime.c: gccnew/libiberty/getruntime.c:1.2
diff -c gccnew/libiberty/hashtab.c: gccnew/libiberty/hashtab.c:1.2
diff -c gccnew/libiberty/hex.c: gccnew/libiberty/hex.c:
diff -c gccnew/libiberty/lrealpath.c: gccnew/libiberty/lrealpath.c:1.2
diff -c gccnew/libiberty/make-temp-file.c: gccnew/libiberty/make-temp-file.c:1.2
diff -c gccnew/libiberty/md5.c: gccnew/libiberty/md5.c:1.2
diff -c gccnew/libiberty/mkstemps.c: gccnew/libiberty/mkstemps.c:1.2
diff -c gccnew/libiberty/obstack.c: gccnew/libiberty/obstack.c:1.2
diff -c gccnew/libiberty/physmem.c: gccnew/libiberty/physmem.c:1.2
diff -c gccnew/libiberty/regex.c: gccnew/libiberty/regex.c:1.2
diff -c gccnew/libiberty/safe-ctype.c: gccnew/libiberty/safe-ctype.c:1.4
diff -c gccnew/libiberty/vasprintf.c: gccnew/libiberty/vasprintf.c:
diff -c gccnew/libiberty/xmalloc.c: gccnew/libiberty/xmalloc.c:1.3
diff -c gccnew/libiberty/xmemdup.c: gccnew/libiberty/xmemdup.c:1.2
diff -c gccnew/libiberty/xstrdup.c: gccnew/libiberty/xstrdup.c:1.2

(most files are just a few lines of change though).

The most intrusive change was the #include processing which is
done differently on MVS.

Anyway, I'm planning on spending a bit more time consolidating this
build.  Not sure if the optimization problem can be solved, but even if
it can't, at least all the i370 code is now consolidated ready for the
push forward.  Hopefully these issues are more readily solved in the
latest codebase.

Hopefully also some of those other minor issues (like including
non-standard header files like sys/types) can also be remedied.  :-)

This has certainly taken a while.  The number of people who have
asked me why I don't use 3.4.6 as if it is trivial to do these things,
just change a couple of numbers surely.  :-)

Interesting how well the EBCDIC conversion held up too.  GCC 3.2.3
was a lot more intrusive to get working in that regard.

Let me know if you find anything that should have been done
differently too.  :-)

BFN. Paul.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]