[PATCH v1] RISC-V: Support XVentanaCondOps extension

[lkcl]

On April 20, 2022 10:15:55 PM UTC, Jim Wilson <jim.wilson.gcc@gmail.com> wrote:
>On Wed, Apr 20, 2022 at 10:55 AM lkcl via Binutils
><binutils@sourceware.org>
>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.
>>
>
>The RISC-V ISA has always planned for support for custom extensions. 

yes. as isolated non-public usage.  for example, Western Digital's private usage within their SSD, HDD and USB Flash products.  such private usage is non-disruptive to the overall ecosystem.

>We
>have a part of the opcode space reserved for custom extensions,

i know [others on this list may not]. i followed RISC-V development for over 18 months.

>Custom extensions are a fact of life.  All major RISC-V vendors have
>them.
>You are suggesting that each vendor should maintain their own toolchain
>source tree.  But if they all do that, then there is a risk that none
>will
>contribute patches upstream. 

it not a risk that it *doesn't* happen, it's a risk if it *does* happen.

conflicting public usage of the exact same opcodes results in utter destruction of confidence in the entire ISA.  many people including ARM have warned the RISCV community about this.

one binary compiled for one vendor is absolutely impossible to run on another vendor's hardware.

and that starts the moment that any two uses of the exact same opcode become public.  [this was the altivec nightmare of powerpc, 20 years ago].

if they are *private* then that risk of the destruction of public confidence in the entire ISA is mitigated.

>If you don't want custom extensions, it is easy enough to avoid them by
>not
>enabling them in the arch string.  I expect that vendor independent
>linux
>distros will be built without any vendor custom extensions enabled.

mhm.  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 *specifically* by the Alibaba Group to compensate for the lacklustre performance of the standard authorised RV64GC?

https://news.ycombinator.com/item?id=24459041

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 support for the (faster) rogue, unauthorised custom instructions (in direct violation of the Trademark and Compliance Certification), and it quickly goes to hell in a handbasket from there.

to help the RISC-V ecosystem i did explain a way to avoid this mess: i went to a lot of trouble to document and propose it.  the response to those efforts was so shockingly abusive that several people contacted me privately to apologise.

now it is too late, the damage is done. the opportunity to mitigate the public ISA conflict scenario is literally unfolding and cannot be retroactively corrected.  the mechanism to solve this had to have been put in place *before* so many vendors started publicly competing for the same conflicting opcodes, *before* they committed tens to hundreds of millions of dollars in silicon product.

l.