On Fri, 13 May 2022 at 12:58, Florian Weimer <fwei...@redhat.com> wrote: > > * Christoph Müllner via Binutils: > > > I'd like to add two points to this topic and raise two questions. > > > > 1) Accepting vendor extensions = avoidance of fragmentation > > > > RISC-V implementors are actively encouraged to implement their > > own ISA extensions. To avoid fragmentation in the SW ecosystem > > (every vendor maintains a fork of tools, distros and binaries) there > > needs to be a principle acceptance to get vendor extension support > > upstream. > > If you eventually want portable binaries, it's necessary to converge on > a small set of widely implemented extensions. x86 didn't have this, and > adoption was poor outside specialized libraries (and JIT, of course). > Yet everything was as upstream as possible (ISA manuals, assemblers, > compiler intrinsics, even automated adoption by optimizers). So > upstreaming is only the first step.
Some of the earlier discussion seems to have mixed two different goals: 1. making the vendor-defined features available to the developer and ensuring that no unintended consequences (e.g., "accidental" interlinking) happen, so developers can choose to adopt them (e.g. through dynamic detection) where appropriate; 2. having widespread adoption for features across libraries/applications that take advantage of all implemented features As this is cross-posted to projects that provide the infrastructure, tools, and plumbing, we should IMO focus on goal #1. Coming from the RISC-V ISA philosophy, this also makes excellent sense: after all, RISC-V is (in its purest form) an "ISA construction kit": one can add extensions or leave extensions off. For the essential development tools, this flexibility is reflected in the myriad of combinations that "-march" can have (just consider that there are 4 distinct Zb[abcs] extensions that add addressing, basic bit-manipulation, carryless multiplication, and single-bit operations…). If individual downstream users see benefits from any of these (e.g., Zbb for strlen; Zbc for GHASH, …), they will contribute optimized code-paths under ifunc (or whatever other mechanism a given library/application uses); however: we first need to have our tools support these extensions (both standard and vendor-defined) and ensure that no accidental interlinking happens. Finally, to enable binary distributions, a basic architecture level that everyone agrees on (these are being defined at the RISC-V Foundation under the "Profiles" and "Platforms" umbrellas) provides a baseline to target that will provide some level of "runs everywhere" based on such a "small set of widely implemented extensions". Philipp.
