S390 should change the meaning of -m31

S390 should change the meaning of -m31

[Jesus Antonio]

m31 is semantically the same as the m32 option.


The m31 option allows for 32 bit addressing and that is confusing since 
the m31 option in S390 would mean 2 GiB space addressing but it allows 
for 32 bit addressing, this is awkward, not only because the option is 
misleading but is also incorrect.


To use 32 bit mode you specify m31, however in S390 there are 32 and 31 
bit modes, which have only 1 bit in difference.


Code used:

     volatile uint64_t *gib_test = (volatile uint64_t *)0x7FFFFFFF;
     memset(gib_test, 1, 4096);


Hercules dump:

r 0x7FFFFFFF-0x800001FF
R:000000007FFFFFFF:K:06=01 .
R:000000008000000F:K:06=01 01010101 01010101 01010101 010101 
................
R:000000008000001F:K:06=01 01010101 01010101 01010101 010101 
................
R:000000008000002F:K:06=01 01010101 01010101 01010101 010101 
................
R:000000008000003F:K:06=01 01010101 01010101 01010101 010101 
................
R:000000008000004F:K:06=01 01010101 01010101 01010101 010101 
................
R:000000008000005F:K:06=01 01010101 01010101 01010101 010101 
................
R:000000008000006F:K:06=01 01010101 01010101 01010101 010101 
................
R:000000008000007F:K:06=01 01010101 01010101 01010101 010101 
................
R:000000008000008F:K:06=01 01010101 01010101 01010101 010101 
................
R:000000008000009F:K:06=01 01010101 01010101 01010101 010101 
................
R:00000000800000AF:K:06=01 01010101 01010101 01010101 010101 
................
R:00000000800000BF:K:06=01 01010101 01010101 01010101 010101 
................
R:00000000800000CF:K:06=01 01010101 01010101 01010101 010101 
................
R:00000000800000DF:K:06=01 01010101 01010101 01010101 010101 
................
R:00000000800000EF:K:06=01 01010101 01010101 01010101 010101 
................
R:00000000800000FF:K:06=01 01010101 01010101 01010101 010101 
................
R:000000008000010F:K:06=01 01010101 01010101 01010101 010101 
................
R:000000008000011F:K:06=01 01010101 01010101 01010101 010101 
................
R:000000008000012F:K:06=01 01010101 01010101 01010101 010101 
................
R:000000008000013F:K:06=01 01010101 01010101 01010101 010101 
................
R:000000008000014F:K:06=01 01010101 01010101 01010101 010101 
................
R:000000008000015F:K:06=01 01010101 01010101 01010101 010101 
................
R:000000008000016F:K:06=01 01010101 01010101 01010101 010101 
................
R:000000008000017F:K:06=01 01010101 01010101 01010101 010101 
................
R:000000008000018F:K:06=01 01010101 01010101 01010101 010101 
................
R:000000008000019F:K:06=01 01010101 01010101 01010101 010101 
................
R:00000000800001AF:K:06=01 01010101 01010101 01010101 010101 
................
R:00000000800001BF:K:06=01 01010101 01010101 01010101 010101 
................
R:00000000800001CF:K:06=01 01010101 01010101 01010101 010101 
................
R:00000000800001DF:K:06=01 01010101 01010101 01010101 010101 
................
R:00000000800001EF:K:06=01 01010101 01010101 01010101 010101 
................
R:00000000800001FF:K:06=01 01010101 01010101 01010101 010101 
................


The option i used was m31 of course, however this option is misleading 
since it allows 32 bit mode, and there is no m32 so you have to use m31 
- just lots of misleading options.


I'm requesting that m31 and m32 are semantically different to allow a 
less-misleading naming, since there is no 31 bit restriction whatsoever.

Re: S390 should change the meaning of -m31

[Michael Matz]

Hello,

On Wed, 29 Sep 2021, Jesus Antonio via Gcc wrote:

> m31 is semantically the same as the m32 option.
> 
> 
> The m31 option allows for 32 bit addressing and that is confusing since 
> the m31 option in S390 would mean 2 GiB space addressing

Indeed that's exactly what it means, and what it's supposed to mean.  On 
s390, in AMODE(31) the toplevel bit of an (32bit) address is either 
ignored or an indicator to switch back to 24bit addresses from the s360 
times.  Either way that leaves 31 bits to generate the virtual address.  
On s390 you indeed have a 2GB address space, not more.

> Code used:
> 
>     volatile uint64_t *gib_test = (volatile uint64_t *)0x7FFFFFFF;
>     memset(gib_test, 1, 4096);
> 
> 
> Hercules dump:
> 
> r 0x7FFFFFFF-0x800001FF
> R:000000007FFFFFFF:K:06=01 .

I'm not sure what you believe to have demonstrated here.  The (virtual or 
physical) address 0x7FFFFFFF is either (in AMODE(24)) equivalent to 
0x00ffffff or to 0xffffffff (in AMODE(31)), either way, the top byte of 
the addressable range ...

> R:000000008000000F:K:06=01 01010101 01010101 01010101 010101 ................

... while address 0x80000001 is equivalent to address 0x1 (in AMODE(24) 
and AMODE(31)).  Again, the top bit (or bits in AMODE(24)) are ignored.  
So, you've built a memset that wraps around the line (AMODE(24)) or the 
bar (AMODE(32)).  Perhaps unusual and not what you expected, but as 
designed by IBM.

> The option i used was m31 of course, however this option is misleading 
> since it allows 32 bit mode, and there is no m32 so you have to use m31 
> - just lots of misleading options.

The -mXX options are supposed to reflect the address space's size, not the 
size of the general purpose registers.  An option that reflect AMODE(24) 
would also be called -m24, despite the registers still being 32bit in 
size.


Ciao,
Michael.

Re: S390 should change the meaning of -m31

[Paul Edwards]

Hi Michael.

I have sort of (I used the i370 target of GCC 3.2.3 instead
of the s390 target) reproduced Jesus's work with z/PDOS
which can be obtained from here:

http://www.pdos.org/zpdos.zip

You can see that with standard Hercules 3.13:

18:02:24 Hercules Version 3.13
18:02:24 (c)Copyright 1999-2015 by Roger Bowler, Jan Jaeger, and others
18:02:24 Built on Sep 28 2017 at 01:35:43
18:02:24 Build information:
18:02:24   Windows (MSVC) build for AMD64

This memcpy:

memcpy((char *)0x7ffffffe, "\x01\x02\x03\x04", 4);

straddles the 2 GiB bar, and the memory is distinct from
low memory:

18:03:05 r 7ffffff0
18:03:05 R:000000007FFFFFF0:K:06=00000000 00000000 00000000 00000102 
................
18:03:05 R:0000000080000000:K:06=03040000 00000000 00000000 00000000 
................
18:03:05 R:0000000080000010:K:06=00000000 00000000 00000000 00000000 
................
18:03:05 R:0000000080000020:K:06=00000000 00000000 00000000 00000000 
................

18:03:13 r 00000000
18:03:13 R:0000000000000000:K:06=000C0000 80002000 00000000 00000000 
................
18:03:13 R:0000000000000010:K:06=0071D4B0 00000000 00000000 00000000 
..M.............
18:03:13 R:0000000000000020:K:06=000C0001 8050327A 00000000 00000000 
.....&.:........
18:03:13 R:0000000000000030:K:06=00000000 00000000 00000000 00000000 
................


BFN. Paul.




-----Original Message----- 
From: Paul Edwards
Sent: Friday, October 1, 2021 8:01 AM
To: gcc@gcc.gnu.org
Cc: matz@suse.de ; jesusantonio30122016@gmail.com
Subject: S390 should change the meaning of -m31

Hi Michael.

Thanks for picking up this issue. I have been working
with Jesus on this.

>> m31 is semantically the same as the m32 option.
>>
>>
>> The m31 option allows for 32 bit addressing and that is confusing since 
>> the m31 option in S390 would mean 2 GiB space addressing

> Indeed that's exactly what it means, and what it's supposed to mean.  On 
> s390, in AMODE(31) the toplevel bit of an (32bit) address is either 
> ignored or an indicator to switch back to 24bit addresses from the s360 
> times.  Either way that leaves 31 bits to generate the virtual address. On 
> s390 you indeed have a 2GB address space, not more.

He is using z/Arch and AM64.

But building with -m31.

>> Code used:
>>
>>     volatile uint64_t *gib_test = (volatile uint64_t *)0x7FFFFFFF;
>>     memset(gib_test, 1, 4096);
>>
>>
>> Hercules dump:
>>
>> r 0x7FFFFFFF-0x800001FF
>> R:000000007FFFFFFF:K:06=01 .

> I'm not sure what you believe to have demonstrated here.  The (virtual or 
> physical) address 0x7FFFFFFF is either (in AMODE(24)) equivalent to 
> 0x00ffffff or to 0xffffffff (in AMODE(31)), either way, the top byte of 
> the addressable range ...

I don't think that's what Hercules does for a real
memory display - it will instead say out of range.
But it doesn't matter, because we're using
64-bit Hercules with 4 GiB of memory and it doesn't
matter what the AMODE happens to be at any moment
in time, what is important is what is in that 4 GiB of
memory.

> The -mXX options are supposed to reflect the address space's size, not the 
> size of the general purpose registers.  An option that reflect AMODE(24) 
> would also be called -m24, despite the registers still being 32bit in 
> size.

The code generated by -m24 would be identical to
code generated by -m31 which would be identical to
code generated by -m32.

Why can't we just have a normal -m32 and accept -m31
and maybe -m24 too, and flag them as "obsolete"?

Thanks. Paul. 

S390 should change the meaning of -m31

[Paul Edwards]

Hi Michael.

Thanks for picking up this issue. I have been working
with Jesus on this.

>> m31 is semantically the same as the m32 option.
>>
>>
>> The m31 option allows for 32 bit addressing and that is confusing since 
>> the m31 option in S390 would mean 2 GiB space addressing

> Indeed that's exactly what it means, and what it's supposed to mean.  On 
> s390, in AMODE(31) the toplevel bit of an (32bit) address is either 
> ignored or an indicator to switch back to 24bit addresses from the s360 
> times.  Either way that leaves 31 bits to generate the virtual address. 
> On s390 you indeed have a 2GB address space, not more.

He is using z/Arch and AM64.

But building with -m31.

>> Code used:
>>
>>     volatile uint64_t *gib_test = (volatile uint64_t *)0x7FFFFFFF;
>>     memset(gib_test, 1, 4096);
>>
>>
>> Hercules dump:
>>
>> r 0x7FFFFFFF-0x800001FF
>> R:000000007FFFFFFF:K:06=01 .

> I'm not sure what you believe to have demonstrated here.  The (virtual or 
> physical) address 0x7FFFFFFF is either (in AMODE(24)) equivalent to 
> 0x00ffffff or to 0xffffffff (in AMODE(31)), either way, the top byte of 
> the addressable range ...

I don't think that's what Hercules does for a real
memory display - it will instead say out of range.
But it doesn't matter, because we're using
64-bit Hercules with 4 GiB of memory and it doesn't
matter what the AMODE happens to be at any moment
in time, what is important is what is in that 4 GiB of
memory.

> The -mXX options are supposed to reflect the address space's size, not the 
> size of the general purpose registers.  An option that reflect AMODE(24) 
> would also be called -m24, despite the registers still being 32bit in 
> size.

The code generated by -m24 would be identical to
code generated by -m31 which would be identical to
code generated by -m32.

Why can't we just have a normal -m32 and accept -m31
and maybe -m24 too, and flag them as "obsolete"?

Thanks. Paul.