From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by sourceware.org (Postfix) with ESMTPS id 425AB3858C2C for ; Thu, 30 Sep 2021 16:05:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 425AB3858C2C Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id 4366F1FE7D; Thu, 30 Sep 2021 16:05:18 +0000 (UTC) Received: from wotan.suse.de (wotan.suse.de [10.160.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 3CD21A3B88; Thu, 30 Sep 2021 16:05:18 +0000 (UTC) Received: by wotan.suse.de (Postfix, from userid 10510) id 2EABB62F0; Thu, 30 Sep 2021 16:05:18 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by wotan.suse.de (Postfix) with ESMTP id 2CA5962C8; Thu, 30 Sep 2021 16:05:18 +0000 (UTC) Date: Thu, 30 Sep 2021 16:05:18 +0000 (UTC) From: Michael Matz To: Jesus Antonio cc: gcc@gcc.gnu.org Subject: Re: S390 should change the meaning of -m31 In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (LSU 67 2015-01-07) MIME-Version: 1.0 X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_NUMSUBJECT, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Sep 2021 16:05:20 -0000 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.