From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) by sourceware.org (Postfix) with ESMTPS id A01D93858D1E for ; Wed, 20 Apr 2022 23:17:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A01D93858D1E Received: by mail-wr1-x42c.google.com with SMTP id w4so4220197wrg.12 for ; Wed, 20 Apr 2022 16:17:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:in-reply-to:references:mime-version :content-transfer-encoding:subject:to:cc:from:message-id; bh=nunTmd6XGp6nioyL/gOZjWb8qN+z9uNG54EEAY8g5jk=; b=0X1ivkz+ETLasDOKYyJhazjOUgS3C5NBGVk4lbR241AsggxFRZdvoyvrROneeEFxwX +GQHjz80HbyVIYdiNk19JLBl4S6QLLQZLBB//du3z6aMpKB6z4uHqgX9b5X8VsHQ5dhE MYgLQgomT/6TqwXNq7704XIySwp/+yxjdeQhdx/mVnbbu0Dp+CtW0S2tN2FAo2Av783b bFIGLcKB8JdLxyrIyaPv38j87FeCIbHQ2f/C++Zydj7cATwlOfF0nYTMiqy0D/fBHTom yWleBT8krBCdXT3npg4SAtBve1+QAe4/V0JewJbu/XjNfEbt9cJMndsMvrElB5z2cl2p Op6g== X-Gm-Message-State: AOAM531pQohWuFN0AiTsQy3+lq1b+pDhnFi0x3Ld+/kTOoY6TDsI4HDC pqFeEkfzlIpjCamUBrFpbNFzSGfcmCU= X-Google-Smtp-Source: ABdhPJy7sHzK6GptGE00xCF5uGVa8nLBkdIM7fdhaXz52SbJ8WrbaW1K7BiD7BMavCIS0Xi/xTAIjA== X-Received: by 2002:adf:ec47:0:b0:207:aa5a:4197 with SMTP id w7-20020adfec47000000b00207aa5a4197mr17019887wrn.195.1650496661036; Wed, 20 Apr 2022 16:17:41 -0700 (PDT) Received: from [192.168.1.100] (92.40.198.68.threembb.co.uk. [92.40.198.68]) by smtp.gmail.com with ESMTPSA id m65-20020a1ca344000000b0038ec75d90a8sm588066wme.2.2022.04.20.16.17.40 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Apr 2022 16:17:40 -0700 (PDT) Date: Wed, 20 Apr 2022 23:17:38 +0000 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [PATCH v1] RISC-V: Support XVentanaCondOps extension To: Jim Wilson CC: binutils@sourceware.org From: lkcl Message-ID: <66C40407-2045-403F-AB52-C9799F77B2E8@gmail.com> X-Spam-Status: No, score=4.5 required=5.0 tests=BAYES_20, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_ABUSEAT, RCVD_IN_DNSWL_NONE, RCVD_IN_SBL_CSS, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 X-Spam-Level: **** X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: Wed, 20 Apr 2022 23:17:44 -0000 On April 20, 2022 10:15:55 PM UTC, Jim Wilson wrote: >On Wed, Apr 20, 2022 at 10:55 AM lkcl via Binutils > >wrote: > >> my understanding of custom extensions is that they are intended >never, >> under any circumstances, to hit "upstream", due to the risk of >creating >> massive conflict and confusion due to dominance of one extension over >> another, particularly if that custom extension achieves extremely >> commonly-used and high profile public status=2E >> > >The RISC-V ISA has always planned for support for custom extensions=2E=20 yes=2E as isolated non-public usage=2E for example, Western Digital's pri= vate usage within their SSD, HDD and USB Flash products=2E such private us= age is non-disruptive to the overall ecosystem=2E >We >have a part of the opcode space reserved for custom extensions, i know [others on this list may not]=2E i followed RISC-V development for = over 18 months=2E >Custom extensions are a fact of life=2E All major RISC-V vendors have >them=2E >You are suggesting that each vendor should maintain their own toolchain >source tree=2E But if they all do that, then there is a risk that none >will >contribute patches upstream=2E=20 it not a risk that it *doesn't* happen, it's a risk if it *does* happen=2E conflicting public usage of the exact same opcodes results in utter destru= ction of confidence in the entire ISA=2E many people including ARM have wa= rned the RISCV community about this=2E one binary compiled for one vendor is absolutely impossible to run on anot= her vendor's hardware=2E and that starts the moment that any two uses of the exact same opcode beco= me public=2E [this was the altivec nightmare of powerpc, 20 years ago]=2E if they are *private* then that risk of the destruction of public confiden= ce in the entire ISA is mitigated=2E >If you don't want custom extensions, it is easy enough to avoid them by >not >enabling them in the arch string=2E I expect that vendor independent >linux >distros will be built without any vendor custom extensions enabled=2E mhm=2E and what happens when people complain, "these public common vendor= independent releases are S***! they're SO SLOW?" and people investigate, and find that it's because the base RV64GC (common= , independent) variant is missing 50% of the opcodes that were added *speci= fically* by the Alibaba Group to compensate for the lacklustre performance = of the standard authorised RV64GC? https://news=2Eycombinator=2Ecom/item?id=3D24459041 at that point, to ensure users do not abandon their product in droves, the= sheer overwhelming number of user requests will compel distros to add supp= ort for the (faster) rogue, unauthorised custom instructions (in direct vio= lation of the Trademark and Compliance Certification), and it quickly goes = to hell in a handbasket from there=2E to help the RISC-V ecosystem i did explain a way to avoid this mess: i wen= t to a lot of trouble to document and propose it=2E the response to those = efforts was so shockingly abusive that several people contacted me privatel= y to apologise=2E now it is too late, the damage is done=2E the opportunity to mitigate the = public ISA conflict scenario is literally unfolding and cannot be retroacti= vely corrected=2E the mechanism to solve this had to have been put in plac= e *before* so many vendors started publicly competing for the same conflict= ing opcodes, *before* they committed tens to hundreds of millions of dollar= s in silicon product=2E l=2E