s390 port

["Paul Edwards" <mutazilah@gmail.com>]

Hi Ulrich.

Sorry for the necro - things happen slowly Down Under. :-)

Anyway, I am helping someone with their public domain
project, UDOS - https://github.com/udos-project/udos

(just a hobby, won't be big and professional like Linux)

We got the IPL process in place on ESA/390, and then
I decided that the next thing to do would be to switch
to z/Arch so that we could get rid of the AMODE 31
architectural limit on 32-bit programs.

It all worked fine, and we were able to use GCC 11 to
target S/390 and use the -m31 to generate 32-bit code,
run it under z/Arch as AM64, sort of making it the
equivalent of AM32. Really it is the equivalent of
AM-infinity, and there's the rub - GCC 11 is generating
negative indexes, which cause memory above 4 GiB
to be accessed (instead of wrapping at 2/4 GiB), which
of course fails.

Do you have any idea how to stop the S/390 target
from generating negative indexes? I thought the
solution might be to change the Pmode to DImode
even for non-TARGET64, but as you can see here:

http://www.pdos.org/gccfail.png

we got an internal compile error - maximum number
of generated reload insns per insn achieved (90).

I then tried changing the other SImode reference
(CASE_VECTOR_MODE) to DImode too, but that gave
the same internal error.

Here is what the failure looks like (see the large R4):

01:28:27 PSW=00042001 80000000 0000000000005870 INST=A73A0001     AHI   3,1 
add_halfword_immediate
01:28:27 R0=00000000000001FD R1=00000000000000E2 R2=000000000009E579 
R3=00000000000080B2
01:28:27 R4=00000000FFFFF000 R5=000000000001E5C8 R6=0000000000007FFF 
R7=0000000000002000
01:28:27 R8=000000000000201F R9=0000000000000000 RA=00000000000080B0 
RB=00000000000080B2
01:28:27 RC=000000000009E580 RD=0000000000008138 RE=0000000000007B4C 
RF=000000000001E4E4
01:28:27 PSW=00042001 80000000 0000000000005874 INST=42142FFF     STC 
1,4095(4,2)            store_character
01:28:27 R:000000010009E578: Translation exception 0005
01:28:27 R0=00000000000001FD R1=00000000000000E2 R2=000000000009E579 
R3=00000000000080B3
01:28:27 R4=00000000FFFFF000 R5=000000000001E5C8 R6=0000000000007FFF 
R7=0000000000002000
01:28:27 R8=000000000000201F R9=0000000000000000 RA=00000000000080B0 
RB=00000000000080B2
01:28:27 RC=000000000009E580 RD=0000000000008138 RE=0000000000007B4C 
RF=000000000001E4E4
01:28:27 HHCCP014I CPU0000: Addressing exception CODE=0005 ILC=4
01:28:27 PSW=00042001 80000000 0000000000005878 INST=42142FFF     STC 
1,4095(4,2)            store_character
01:28:27 R:000000010009E578: Translation exception 0005
01:28:27 R0=00000000000001FD R1=00000000000000E2 R2=000000000009E579 
R3=00000000000080B3
01:28:27 R4=00000000FFFFF000 R5=000000000001E5C8 R6=0000000000007FFF 
R7=0000000000002000
01:28:27 R8=000000000000201F R9=0000000000000000 RA=00000000000080B0 
RB=00000000000080B2
01:28:27 RC=000000000009E580 RD=0000000000008138 RE=0000000000007B4C 
RF=000000000001E4E4
01:28:27 HHCCP043I Wait state PSW loaded: PSW=00060001 80000000 
0000000000000444
01:28:40 quit
01:28:40 HHCIN900I Begin Hercules shutdown

Any idea what we can do?

Thanks. Paul.




-----Original Message----- 
From: Ulrich Weigand
Sent: Saturday, June 6, 2009 1:20 AM
To: Paul Edwards
Cc: gcc@gcc.gnu.org
Subject: Re: i370 port

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@de.ibm.com