From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) by sourceware.org (Postfix) with ESMTPS id D6EB63858C39 for ; Thu, 30 Sep 2021 22:01:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D6EB63858C39 Received: by mail-pj1-x1029.google.com with SMTP id om12-20020a17090b3a8c00b0019eff43daf5so5819042pjb.4 for ; Thu, 30 Sep 2021 15:01:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:from:to:cc:subject:date:mime-version :content-transfer-encoding:importance; bh=WJ3LsSBvFg6xP0cTypMcZRbo0xg9H2HWx/BiYGbeKXY=; b=CTn8rGYjcecNZNvTvxpX3RzndnWDfKUCGno9dqg1VJfcsb2OeRxjfofiKFPgwP07ad 0CDgulAewlGnvmTweNTTYgHoE72ra2+F6B5xpIl+oWvLugvrq0mPbXdJnT8QI4L1qmCu h+B1uyFgwqGi8Mk7+kwb2ss4Df4+dqFdqbkUHEdN+lBd8xtsCxzbJXp25mS7PICwFzXh 7mPdSqn5OP1GUumJU2Wg7qaCyv3Q6OFnsv42vtvNbsgjnjCmMPS1fMh9yiaSIIiiz5NZ SVLzx1nDmWvobQlvBEMuLXLc0YM8EN7qeA1d7Rsz3a9YwKlrrjKTw1q/X+j5Hh0GDvv3 86Dg== X-Gm-Message-State: AOAM5319MV14HFNSQKSK/G6xDJ0c8mi71V9mZ94zduPz28r03YXZjROz 2xlta7KeHBgGb1/TkjhLWP50cC+TpZ0= X-Google-Smtp-Source: ABdhPJzi3C7Irx5YqcRz/jKA6syEqOKz4FXvklQ2tXkcp+ovc+v5pAoyniHNAiZ3FP9AfJagLLEtpg== X-Received: by 2002:a17:90b:950:: with SMTP id dw16mr9037001pjb.25.1633039286378; Thu, 30 Sep 2021 15:01:26 -0700 (PDT) Received: from DESKTOP0OKG1VA ([202.169.113.201]) by smtp.gmail.com with ESMTPSA id z25sm3893641pfj.199.2021.09.30.15.01.23 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Sep 2021 15:01:25 -0700 (PDT) Message-ID: <565ECF9FBB50455BB3143CB350DEF7DE@DESKTOP0OKG1VA> From: "Paul Edwards" To: Subject: S390 should change the meaning of -m31 Date: Fri, 1 Oct 2021 08:01:22 +1000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_NUMSUBJECT, RCVD_IN_DNSWL_NONE, 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 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 22:01:30 -0000 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.