From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) by sourceware.org (Postfix) with ESMTPS id BA0E13858C52 for ; Fri, 13 May 2022 10:37:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BA0E13858C52 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=vrull.eu Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=vrull.eu Received: by mail-wr1-x435.google.com with SMTP id j25so9842527wrc.9 for ; Fri, 13 May 2022 03:37:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vrull.eu; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=d36RXr15qKk5MNsJHTtmjeYgc6dN8RGXHILh7SDEAo0=; b=V/mzD99/niLcdY2fgN9Chh5gcWfKDpGk8w3ywQWSw1kmLbHkjhse8AWDbNXPs3pKA7 s9tRctjslJ9RtBKWe8dAR+AwvOPltEGMPg3TPP45q61FuWddX0gF1HIks0n3TyGcJyOO waSV3pta1syFvlC5urgHhyEmRkyYawBuIksf90TUD+imkY2yvi2mr7p7G3UCHAdQx70C pgd0e8s3QBU9TWXhLKz44qw7qYEQJR+ugqnerncy0Zt9wU6A0+3WRH82yNxqc7eSJvO7 V6SQWpw5MEqY3o4DonR7RorxtAqf7/PdwIK0ud4hQ0l3yr/yL5FuglyNiG2c8roF9pBK Fbog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=d36RXr15qKk5MNsJHTtmjeYgc6dN8RGXHILh7SDEAo0=; b=uKa3ebRAF6nh6aqcFpt9NkmUNGP1D7fMmrvSXwHIhwtQjbmgYpxUa6s7Ub92eXgxOC 1eVpHxxSA/rHWirIR3+1MK1hqOafx+8riauffWdxsZfsWl1raDFbQKxTG2ZNnKWX+xKE kpu1Vk2i74G8JiaQ1HOS4XY16B/iTpNN38gDvHh4xh9ebqh2qIkIOWEFaFt25sNMGEvT cvJcabg8IkiPemoKP0O/4M4HpiOSlEHCVv0ZkBFNJ4RfQStIdKEBv9njFVVDix7Lr9yC IvKC+31mRD1E8W8GQuGtFwRZr98fwCIOuQtbOq3tLw8FyGL7CPcsA9w43qSXpSZltjW5 8qDg== X-Gm-Message-State: AOAM533cuY/qW2t9SiIzQpcXcZi7/kuVC3SvbJq4cM3qOkZ/38vxKdJq 85M1MDHUG2GTpHVVcuQ3Chs9GnmqsgMhEpMOexyPpg== X-Google-Smtp-Source: ABdhPJyYcrOUfoPPKqN6zSkripL0g2vI4xUVvgruazgDOz35u93NhU9KqP/5SPIdE4q/tn7QNHmw1sXQnijZ86U6Rt8= X-Received: by 2002:adf:cc81:0:b0:20c:df10:6c5d with SMTP id p1-20020adfcc81000000b0020cdf106c5dmr3414387wrj.312.1652438253341; Fri, 13 May 2022 03:37:33 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Philipp Tomsich Date: Fri, 13 May 2022 12:37:22 +0200 Message-ID: Subject: Re: Supporting RISC-V Vendor Extensions in the GNU Toolchain To: =?UTF-8?Q?Christoph_M=C3=BCllner?= Cc: Palmer Dabbelt , Binutils , GCC Patches , GNU C Library , gdb-patches@sourceware.org, Greg Favor Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, JMQ_SPF_NEUTRAL, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 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: Fri, 13 May 2022 10:37:37 -0000 On Fri, 13 May 2022 at 12:00, Christoph M=C3=BCllner wrote: > > On Wed, May 11, 2022 at 2:02 AM Palmer Dabbelt wrote= : > > > > [Sorry for cross-posting to a bunch of lists, I figured it'd be best to > > have all the discussions in one thread.] > > > > We currently only support what is defined by official RISC-V > > specifications in the various GNU toolchain projects. There's certainl= y > > some grey areas there, but in general that means not taking code that > > relies on drafts or vendor defined extensions, even if that would resul= t > > in higher performance or more featured systems for users. > > > > The original goal of these policies were to steer RISC-V implementers > > towards a common set of specifications, but over the last year or so > > it's become abundantly clear that this is causing more harm that good. > > All extant RISC-V systems rely on behaviors defined outside the officia= l > > specifications, and while that's technically always been the case we've > > gotten to the point where trying to ignore that fact is impacting real > > users on real systems. There's been consistent feedback from users tha= t > > we're not meeting their needs, which can clearly be seen in the many ou= t > > of tree patch sets in common use. > > > > There's been a handful of discussions about this, but we've yet to have > > a proper discussion on the mailing lists. From the various discussions > > I've had it seems that folks are broadly in favor of supporting vendor > > extensions, but the devil's always in the details with this sort of > > thing so I thought it'd be best to write something up so we can have a > > concrete discussion. > > > > The idea is to start taking code that depends on vendor-defined behavio= r > > into the core GNU toolchain ports, as long as it meets the following > > criteria: > > > > * An ISA manual is available that can be redistributed/archived, define= s > > the behaviors in question as one or more vendor-specific extensions, > > and is clearly versioned. The RISC-V foundation is setting various > > guidelines around how vendor-defined extensions and instructions > > should be named, we strongly suggest that vendors follow those > > conventions whenever possible (this is all new, though, so exactly > > what's necessary from vendor specifications will likely evolve as we > > learn). > > * There is a substantial user base that depends on the behavior in > > question, which probably means there is hardware in the wild that > > implements the extensions and users that require those extensions in > > order for that hardware to be useful for common applications. This i= s > > always going to be a grey area, but it's essentially the same spot > > everyone else is in. I must take exception to the "There is a substantial user base" rule, as this conflicts with the goal of avoiding fragmentation: the support for vendor-defined extensions should ideally have landed in an upstream release before the silicon is widely released. This would see these extensions being sent upstream significantly before widespread sampling (and sometimes around the time of the announcement of a device on the roadmap). Simply put: I want everyone defining vendor extensions to contribute to our mainline development efforts instead of extending their own ancient forks. I suspect that this rule is intended to ensure that experimental, purely academic, or "closed" (as in: even if you have the silicon, it will be so deeply embedded that no one can run their own software =E2=80=94 e.g. radio baseband controllers) extensions don't make the maintenance work harder. If that is the case: could we use wording such as (a native speaker might wordsmith something more accurate) "accessible to run user-developed software" and "intended for a wider audience"? > > * There is a mechanism for testing the code in question without direct > > access to hardware, which in practice means a QEMU port (or whatever > > simulator is relevant in the space and that folks use for testing) or > > some community commitment to long-term availability of the hardware > > for testing (something like the GCC compile farm, for example). > > * It is possible to produce binaries that are compatible with all > > upstream vendors' implementations. That means we'll need mechanisms > > to allow extensions from multiple vendors to be linked together and > > then probed at runtime. That's not to say that all binaries will be > > compatible, as users are always free to skip the compatibility code > > and there will be conflicting definitions of instruction encodings, > > but we can at least provide users with the option of compatibility. We today have: - Tag_RISCV_arch (see https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/master/riscv-elf.= adoc#tag_riscv_arch-5-ntbssubarch) - ifunc support Admittedly, there's some loose ends in the end-to-end story (e.g. Unified Discovery -> DTB -> glibc ifunc initialisation): we know just too well how this plays out as there are optimised string/memory functions (Zbb, Zicboz, cache-block-length, =E2=80=A6) in our pipeline as w= ell as OpenSSL support for Zbb and Zbc. However, this is a known gap and will be fully addressed in the future. Is there something specific beyond this that you'd be looking for? Thanks, Philipp. > > > > These are pretty loosely written on purpose, both because this is all > > new and because each project has its own set of contribution > > requirements so it's going to be all but impossible to have a single > > concrete set of rules that applies everywhere -- that's nothing specifi= c > > to the vendor extensions (or even RISC-V), it's just life. Specificall= y > > a major goal here is to balance the needs of users, both in the short > > term (ie, getting new hardware to work) and the long term (ie, the long > > term stability of their software). We're not talking about taking code > > that can't be tested, hasn't been reviewed, isn't going to be supported > > long-term, or doesn't have a stable ABI; just dropping the specific > > requirement that a specification must be furnished by the RISC-V > > foundation in order to accept code. > > > > Nothing is decided yet, so happy to hear any thought folks have. This > > is certainly a very different development methodology than what we've > > done in the past and isn't something that should be entreated into > > lightly, so any comments are welcome. > > I'd like to add two points to this topic and raise two questions. > > 1) Accepting vendor extensions =3D 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. > > 2) Leading upstream maintainers already agreed on supporting vendor-exten= sions > > We have discussed the topic of vendor extensions in many forums last year= . > This topic was also part of the discussions at the Linux Plumbers confere= nce. > Further, there exists a place for documenting toolchain conventions of > the RISC-V > ecosystem ([1]), which everyone in the RISC-V ecosystem is aware about. > > As a result of the discussions last year, a PR ([2]) has been crafted to = clarify > the rules for upstreaming vendor extension support. These RISC-V > toolchain conventions recently added a section for vendor extensions > which covers important aspects like: > > * naming schemes > * assembly mnemonic prefixes > * links to the documentation and version information > > The PR even includes an explicit rule to clarify that maintainers decide = on > upstream inclusion: > """ > Open source toolchain maintainer has final say on accepting vendor extens= ion, > comply with this conventions isn't guarantee upstream will accept. > """ > > A lot of people (maintainers and active developers) were notified > (including you) > and many also actively contributed to the PR. In the end there was an agr= eement > of how to document vendor extensions (as a requirement for upstreaming). > > I believe that your set of rules is compatible with what is specified the= re. > Note however, that you could have mentioned them during the PRs review > process as you were notified when the PR was created. > > My questions are now the following: > > * Where to document the requirements? > > Most RISC-V upstream maintainers are accepting the riscv-toolchains-con= vention > repository. Where if not there should we document requirements for the = tool's > conventions? Why not accept what has already been agreed upon? > > * Where to track the status? > > You mentioned testing requirements (e.g. QEMU support). > I've created a wiki page to show the adoption status of all the > RISC-V extensions ([3]) > last year. As the chair of the Toolchains SIG, I'm willing to create > and maintain one for > vendor extensions as well. This allows users to see which projects > support which > extensions upstream. However, a wiki is a joint effort. So > maintainers that merge > changes upstream need to update the page. Will you support this? > If not what is your proposal to track the status of the upstream > extension support? > > BR > Christoph > > [1] https://github.com/riscv-non-isa/riscv-toolchain-conventions#conventi= ons-for-vendor-extension > [2] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/17 > [3] https://wiki.riscv.org/display/HOME/RISC-V+extension+and+feature+supp= ort+in+the+Open+Source+SW+Ecosystem