From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from libre-soc.org (libre-soc.org [IPv6:2a00:1098:82:f::1]) by sourceware.org (Postfix) with ESMTPS id AADCB3857373 for ; Sun, 29 May 2022 09:13:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org AADCB3857373 Received: from mail-vs1-f53.google.com ([209.85.217.53]) by libre-soc.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nvEz8-0004L6-ME for binutils@sourceware.org; Sun, 29 May 2022 10:13:18 +0100 Received: by mail-vs1-f53.google.com with SMTP id h4so8149877vsr.13 for ; Sun, 29 May 2022 02:13:18 -0700 (PDT) X-Gm-Message-State: AOAM530LOqdcnbZ/b6Jm46k8l6H7EMSGXxMYDEeR1sZO4pajgrT828+X X0ilNwrMyQJJRXQwRva1KBATnxvCI6u2D0HG90I= X-Google-Smtp-Source: ABdhPJzle2D9N4uYE7kzlU37c/dDpfJxw6PYDbkwJLsje9fbh8KvHzo1SvzU4HsFOMkHGjWqXbKMeT7mt5nPZwRFEy0= X-Received: by 2002:a67:df10:0:b0:32d:ba4:8f73 with SMTP id s16-20020a67df10000000b0032d0ba48f73mr20262956vsk.74.1653815597565; Sun, 29 May 2022 02:13:17 -0700 (PDT) MIME-Version: 1.0 References: <17f6beb2-db1a-0bec-b022-168373c3921b@linux.ibm.com> In-Reply-To: <17f6beb2-db1a-0bec-b022-168373c3921b@linux.ibm.com> From: Luke Kenneth Casson Leighton Date: Sun, 29 May 2022 10:13:06 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Plugin-based opcode table To: Peter Bergner Cc: Dmitry Selyutin , Alan Modra , binutils@sourceware.org, Paul Mackerras , Alain Williams Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=1.6 required=5.0 tests=BAYES_00, DKIM_INVALID, DKIM_SIGNED, KAM_DMARC_NONE, KAM_DMARC_STATUS, LIKELY_SPAM_BODY, SPF_HELO_PASS, TXREP, T_SCC_BODY_TEXT_LINE, T_SPF_PERMERROR autolearn=no autolearn_force=no version=3.4.6 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 May 2022 09:13:22 -0000 On Sun, May 29, 2022 at 3:30 AM Peter Bergner wrote: > I'm just catching up on my email backlog after being on vacation last > week, nice. i mean the vacation :) > but I agree with everything Alan said and also agree with how > you're going about things. appreciated the reassurance. i'm not going to get over being nervous about adding to EXT01 (25% of v3.1 prefix space), and to EXT019, 005 and 004, before all these have been approved by the OPF ISA Working Group. certainly, the 005 and 022 (sandbox) opcodes will *not* be permanently in the places we'll initially submit them in. 004 we can make a good case for madded and divmod2du [0] staying where proposed. still, the good news is that people can go "oh, er, so that's what the Libre-SOC team plans to propose to add to Power ISA, i didn't quite have time to work it out before". > That said, I assume your -mlibresoc flag enables more than just the > PPC_OPCODE_SVP64 flag, since there is a lot of "base" POWER instructions > like addi, etc. that I'm sure your cpu implements. yes, we aim for the SFFS (Scalar Fixed Floating Point Subset) subset, described right at the very beginning of the Power ISA Spec (page viii) and have confirmed with Mendy that it's fine to add whatever you like: we therefore choose to add BE, AMO, TLBIE and a RADIX MMU in order to run scalar Linux. following microwatt, basically [1] keenly aware that a corresponding revival of runtime capability detection is needed in glibc6 there (removed a few years ago because noone was using it, because there was only POWER8/POWER9) but one step at a time. > If for some reason, > one of those "base" instructions enabled by -mlibresoc isn't implemented > by your cpu or conflicts in some way with your new instructions, you > can add the PPC_OPCODE_SVP64 to the deprecated field for the problematic > instruction to disable it when using -mlibresoc. fortunately as an entirely from-scratch design with a focus on mass-volume general-purpose compute we have no legacy instructions to support. > For example, POWER9 uses all the flags POWER8 enables plus PPC_OPCODE_POWER9. > However, the "lxvx" instruction changed between POWER8 (where it was an > extended mnemonic for lxvd2x) and POWER9 where is became a real instruction > with a different opcode than lxvd2x (I'm ignoring that doing that was > a very bad idea!). yowser that would have been painful. and a costly mistake that won't go away for at least another decade [i'm aware that IBM still gets 3rd parties asking to license POWER8, *for new designs*] > How that was solved, was adding PPC_OPCODE_POWER9 > to the old lxvx instruction's deprecated field to disable that on POWER9 > and later cpus. POWER9 and later cpus get the new lxvx instruction, > because we enable it with the PPC_OPCODE_POWER9. ok. so this is good to know, because you know what it costs to have to support a conflicting opcode, long-term. now imagine that a binary program needs *both* the old *and* the new behaviour of lxvx, in the same binary - in public usage. part of upstream binutils, part of upstream glibc6, and so on. a solution here is to set the PCR bit that flips back to POWER8 compatibility. if that's protected it would be necessary to have a kernel syscall call to flip back and forth. performance would suck, but at least runtime binary compatibility would be achieved and people don't scream [except to hoot somewhat in derision at such a terrible hack, but hey]. now imagine - even worse - that there's no PCR register bit that can be deployed to flip back and forth between POWER8 and POWER9 compatiblity. now imagine that this happens on two or more high-profile public uses of the Sandbox (EXT022). the spec said it was "perfectly ok". page xii "Facilities described in proposals that are not adopted into the architecture may be implemented as Custom Extensions using the architecture sandbox" this is the nightmare scenario that i'd like to see avoided [understatement] we've another meeting coming up, wed 01jun2022, i have an idea to put in a proposal for some "pre-reservations" of opcode space as ISA RFCs. my biggest concern is that there's no two-way communications path to the IBM Engineers submitting instructions for future IBM POWER 11/12 designs. we have no idea - at all - whether there's already a conflict. l. [0] https://libre-soc.org/openpower/sv/biginteger/ [1] https://shenki.github.io/boot-linux-on-microwatt/