The syntax is fine, but the version number was meant for pre-ratified extensions during development, not for final production use.  

There is a related issue of how the support is managed upstream.

There are going to be literally hundreds, if not thousands, of non-standard RISC-V vendor extensions over time, as well as many development versions of pre-ratified standard extensions (which are also non-standard).

As a general rule, we have to make sure upstream maintainers do not have to deal with non-standard extensions, or have to support pre-ratified versions indefinitely.

I believe this is the only practical approach.

This implies, non-standard extensions should be handled on something like a vendor branch, where vendor is responsible for keeping in sync with master (obviously each project has its own  source management policy).  This model should also work for pre-ratification development versions of new extensions, which will hopefully eventually merge into master, or move to vendor-specific branch.

Krste

On Sep 16, 2021, at 8:15 PM, "戎杰杰 via lists.riscv.org <jiejie.rjj=alibaba-inc.com@...> wrote:

Hi Krste,

    Sounds good.

    

    Also we are talking with @Philipp about how to keep compatible with vector v0.7.1 on toolchain interface,

    we suggest that we prefer this method to control it, e.g. -march=rv64gcv0p7 to specify vector v0.7.1,

   

    i think it's more consistent also,

    whether we use the 'v' extension with version number rather than 'x' extension to implement the requirement ?

--Jojo R

------------------------------------------------------------------

发件人：Krste Asanovic <krste@...>

发送时间：2021年8月28日(星期六) 04:45

收件人：Greg Favor <gfavor@...>

抄　送：Kito Cheng <kito.cheng@...>; Allen Baum <allen.baum@...>; mark <markhimelstein@...>; Philipp Tomsich <philipp.tomsich@...>; tech-privileged <tech-privileged@...>

主　题：Re: [RISC-V] [tech-privileged] [RFC] Toolchain interface for privilege spec related stuff.

Yes, that was the plan,
Krste

>>>>> On Fri, 27 Aug 2021 13:37:13 -0700, "Greg Favor" <gfavor@...> said:

| On Thu, Aug 26, 2021 at 8:31 PM Kito Cheng <kito.cheng@...> wrote:
|     For non-priverage extension, toolchain can control version for each
|     extension by ISA string, e.g. -march=rv64gcv0p10 to specify vector
|     extension with version 0.10.

| Should I assume that for the ratified vector spec simply 'v' can be specified?  And that a version number is only needed to refer to a pre-ratified version of the vector
| spec?

| Greg

|

On Thu, Sep 16, 2021 at 9:34 PM Krste Asanovic <krste@...> wrote:

The syntax is fine, but the version number was meant for pre-ratified extensions during development, not for final production use.  

There is a related issue of how the support is managed upstream.

There are going to be literally hundreds, if not thousands, of non-standard RISC-V vendor extensions over time, as well as many development versions of pre-ratified standard extensions (which are also non-standard).

As a general rule, we have to make sure upstream maintainers do not have to deal with non-standard extensions, or have to support pre-ratified versions indefinitely.

I believe this is the only practical approach.

This implies, non-standard extensions should be handled on something like a vendor branch, where vendor is responsible for keeping in sync with master (obviously each project has its own  source management policy).  This model should also work for pre-ratification development versions of new extensions, which will hopefully eventually merge into master, or move to vendor-specific branch.

+1.

RISC-V is a big tent, but we're bound together by our common need for a common ecosystem.  We've got to focus our limited engineering bandwidth on the things that benefit us all the most.

And that means rejecting all non-conforming contributions.

On Fri, 17 Sept 2021 at 09:39, Andrew Waterman <andrew@...> wrote:

On Thu, Sep 16, 2021 at 9:34 PM Krste Asanovic <krste@...> wrote:

The syntax is fine, but the version number was meant for pre-ratified extensions during development, not for final production use.  

There is a related issue of how the support is managed upstream.

There are going to be literally hundreds, if not thousands, of non-standard RISC-V vendor extensions over time, as well as many development versions of pre-ratified standard extensions (which are also non-standard).

As a general rule, we have to make sure upstream maintainers do not have to deal with non-standard extensions, or have to support pre-ratified versions indefinitely.

I believe this is the only practical approach.

Please consider that in all mature open-source projects, the upstream maintains are custodians: i.e. they only apply patchsets from downstream maintainers and act as gatekeepers for the process, IP right compliance, and quality.

This applies to toolchains, emulators, Linux kernel, bootloaders alike — and the burden to submit and maintain support clearly lies with the vendor's contributors.

For those pre-ratified extensions that are deployed in the field (and have a user-base), vendors will have to support these pre-ratified versions for the lifetime of their silicon ("indefinitely" is a strong word — although, yes, some industrial products can mandate 15+ years of software maintenance).  However, it is the original vendor that deployed this solution that will have to carry the maintenance burden and dedicate the resources to the relevant upstream projects.

 

This implies, non-standard extensions should be handled on something like a vendor branch, where vendor is responsible for keeping in sync with master (obviously each project has its own  source management policy).  This model should also work for pre-ratification development versions of new extensions, which will hopefully eventually merge into master, or move to vendor-specific branch.

+1.

RISC-V is a big tent, but we're bound together by our common need for a common ecosystem.  We've got to focus our limited engineering bandwidth on the things that benefit us all the most.

The original agreement explicitly put the burden on maintaining all such extensions on the proponent of those.  This also applied to x-thead-v (or v0p7, if you want one insists on that shorthand).

This is already a very strong assurance that we require from any such vendor: the consequence of a vendor's failure to maintain will result in the removal of the support from upstream—which will have major customer-support repercussions for a vendor that fails to maintain their extension in the tools.

Vendor branches are not practical for widely deployed hardware and will only lead to more—and harder to handle—fragmentation: imagine commonly provided toolchain packages (i.e., as part of software distributions) lacking support and vendors providing toolchain packages for established distributions (e.g. Fedora, CentOS, etc.), we'd only increase fragmentation in "what people are actually running/compiling with".

For the ecosystem as a whole, it is much better to embrace and reconcile these extensions into our tools: this encourages vendors to actively work with RVI on evolving RISC-V (instead of going off on their own and eventually forking off a "RISC-Vendor") and forces them to donate the resources to (a) support their own code in the upstream, and (b) help maintain the upstream as a whole.

 

And that means rejecting all non-conforming contributions.

We need to be more inclusive here, as we'd otherwise have to reject any contributions addressing errata.

Note that I am not advocating to white-wash any future misuse of the 'standard opcode' space, but the case of V 0.7 is different a wider membership implemented it: e.g. BSC also implemented 0.7 in their accelerators, as did StreamComputing.

As a standards-development organization, we have learned our lesson and made all new drafts very explicit about their lifecycle state and what is a draft, a freeze (release candidate), and a ratified standard.

Finally, we have clearly put the burden to reconcile this into the upstream and maintain it (which is for everyone's benefit) on T-Head, so there really are only benefits to the community in getting this done.

This is really one of the few win-win cases.

Philipp.

On Fri, 17 Sept 2021 at 09:39, Andrew Waterman <andrew@...> wrote:

On Thu, Sep 16, 2021 at 9:34 PM Krste Asanovic <krste@...> wrote:

The syntax is fine, but the version number was meant for pre-ratified extensions during development, not for final production use.  

There is a related issue of how the support is managed upstream.

There are going to be literally hundreds, if not thousands, of non-standard RISC-V vendor extensions over time, as well as many development versions of pre-ratified standard extensions (which are also non-standard).

As a general rule, we have to make sure upstream maintainers do not have to deal with non-standard extensions, or have to support pre-ratified versions indefinitely.

I believe this is the only practical approach.

Please consider that in all mature open-source projects, the upstream maintains are custodians: i.e. they only apply patchsets from downstream maintainers and act as gatekeepers for the process, IP right compliance, and quality.

This applies to toolchains, emulators, Linux kernel, bootloaders alike — and the burden to submit and maintain support clearly lies with the vendor's contributors.

For those pre-ratified extensions that are deployed in the field (and have a user-base), vendors will have to support these pre-ratified versions for the lifetime of their silicon ("indefinitely" is a strong word — although, yes, some industrial products can mandate 15+ years of software maintenance).  However, it is the original vendor that deployed this solution that will have to carry the maintenance burden and dedicate the resources to the relevant upstream projects.

 

This implies, non-standard extensions should be handled on something like a vendor branch, where vendor is responsible for keeping in sync with master (obviously each project has its own  source management policy).  This model should also work for pre-ratification development versions of new extensions, which will hopefully eventually merge into master, or move to vendor-specific branch.

+1.

RISC-V is a big tent, but we're bound together by our common need for a common ecosystem.  We've got to focus our limited engineering bandwidth on the things that benefit us all the most.

The original agreement explicitly put the burden on maintaining all such extensions on the proponent of those.  This also applied to x-thead-v (or v0p7, if you want one insists on that shorthand).

This is already a very strong assurance that we require from any such vendor: the consequence of a vendor's failure to maintain will result in the removal of the support from upstream—which will have major customer-support repercussions for a vendor that fails to maintain their extension in the tools.

Vendor branches are not practical for widely deployed hardware and will only lead to more—and harder to handle—fragmentation: imagine commonly provided toolchain packages (i.e., as part of software distributions) lacking support and vendors providing toolchain packages for established distributions (e.g. Fedora, CentOS, etc.), we'd only increase fragmentation in "what people are actually running/compiling with".

For the ecosystem as a whole, it is much better to embrace and reconcile these extensions into our tools: this encourages vendors to actively work with RVI on evolving RISC-V (instead of going off on their own and eventually forking off a "RISC-Vendor") and forces them to donate the resources to (a) support their own code in the upstream, and (b) help maintain the upstream as a whole.

 

And that means rejecting all non-conforming contributions.

We need to be more inclusive here, as we'd otherwise have to reject any contributions addressing errata.

Note that I am not advocating to white-wash any future misuse of the 'standard opcode' space, but the case of V 0.7 is different a wider membership implemented it: e.g. BSC also implemented 0.7 in their accelerators, as did StreamComputing.

As a standards-development organization, we have learned our lesson and made all new drafts very explicit about their lifecycle state and what is a draft, a freeze (release candidate), and a ratified standard.

Finally, we have clearly put the burden to reconcile this into the upstream and maintain it (which is for everyone's benefit) on T-Head, so there really are only benefits to the community in getting this done.

This is really one of the few win-win cases.

Philipp.

On 2021-09-17 4:48 a.m., Andrew Waterman wrote:

On Fri, Sep 17, 2021 at 1:37 AM Philipp Tomsich <philipp.tomsich@...> wrote:

On Fri, 17 Sept 2021 at 09:39, Andrew Waterman <andrew@...> wrote:

On Thu, Sep 16, 2021 at 9:34 PM Krste Asanovic <krste@...> wrote:

The syntax is fine, but the version number was meant for pre-ratified extensions during development, not for final production use.  

There is a related issue of how the support is managed upstream.

There are going to be literally hundreds, if not thousands, of non-standard RISC-V vendor extensions over time, as well as many development versions of pre-ratified standard extensions (which are also non-standard).

As a general rule, we have to make sure upstream maintainers do not have to deal with non-standard extensions, or have to support pre-ratified versions indefinitely.

I believe this is the only practical approach.

Please consider that in all mature open-source projects, the upstream maintains are custodians: i.e. they only apply patchsets from downstream maintainers and act as gatekeepers for the process, IP right compliance, and quality.

This applies to toolchains, emulators, Linux kernel, bootloaders alike — and the burden to submit and maintain support clearly lies with the vendor's contributors.

For those pre-ratified extensions that are deployed in the field (and have a user-base), vendors will have to support these pre-ratified versions for the lifetime of their silicon ("indefinitely" is a strong word — although, yes, some industrial products can mandate 15+ years of software maintenance).  However, it is the original vendor that deployed this solution that will have to carry the maintenance burden and dedicate the resources to the relevant upstream projects.

 

This implies, non-standard extensions should be handled on something like a vendor branch, where vendor is responsible for keeping in sync with master (obviously each project has its own  source management policy).  This model should also work for pre-ratification development versions of new extensions, which will hopefully eventually merge into master, or move to vendor-specific branch.

+1.

RISC-V is a big tent, but we're bound together by our common need for a common ecosystem.  We've got to focus our limited engineering bandwidth on the things that benefit us all the most.

The original agreement explicitly put the burden on maintaining all such extensions on the proponent of those.  This also applied to x-thead-v (or v0p7, if you want one insists on that shorthand).

This is already a very strong assurance that we require from any such vendor: the consequence of a vendor's failure to maintain will result in the removal of the support from upstream—which will have major customer-support repercussions for a vendor that fails to maintain their extension in the tools.

Vendor branches are not practical for widely deployed hardware and will only lead to more—and harder to handle—fragmentation: imagine commonly provided toolchain packages (i.e., as part of software distributions) lacking support and vendors providing toolchain packages for established distributions (e.g. Fedora, CentOS, etc.), we'd only increase fragmentation in "what people are actually running/compiling with".

For the ecosystem as a whole, it is much better to embrace and reconcile these extensions into our tools: this encourages vendors to actively work with RVI on evolving RISC-V (instead of going off on their own and eventually forking off a "RISC-Vendor") and forces them to donate the resources to (a) support their own code in the upstream, and (b) help maintain the upstream as a whole.

 

And that means rejecting all non-conforming contributions.

Hidden in plain sight we have a

tactical decision defeating

a strategic objective.

I believe Andrew is conflating custom extension with non-conformance.

Strategically we benefit most when we leverage our strengths and minimize our weaknesses.

In this specific instance, that means providing some commonality of support for custom instructions.

This is likely to evolve by multiple vendors providing a framework that supports their respective extension that will ultimately be further extended and incorporated upstream.

However, we can substantially reduce that timeframe by directly addressing that need now through planning the inclusion of such a facility.

Consider Linux "device" drivers. They evolve by incremental inclusion into the Linux subsystem of common elements of the drivers and refactoring the vendor specific code to incorporate them.

Ten years from now I expect this to be common place.

We can reduce that time down to two years for many common cases, including errata support,  if we embark on it now.  [ Isaac Asimov's Foundation approach]

Regarding "hidden in plain sight", I have frequently asked to have our philosophical reasoning and justification be readily available, so that we can debate the greater direction and objectives of RISCV.org.

Here is one such. Buried in the bowels of a discussion on compiler directives.

We do not do a good job [nor do we have good tools or even convention] to start a new thread when a related topic arises,

Opportunity for greater awareness of concerns and issues is lost because of it.

Further, there is the perception of those that participated in the quasi-private discussion,

when the discussion does come up more formally, that we already dealt with that; nothing new to see here, lets move on ....

We need to be more inclusive here, as we'd otherwise have to reject any contributions addressing errata.

Coping with errata is qualitatively different than dealing with deliberately non-conforming extensions.

But even this is a sticky wicket.  Some vendors have implemented non-standard things, then have claimed they thought that they had been implementing standard things.  (Some of those vendors are copied on this email chain.)  So we need to hold the line on the definition of "erratum" as well.

Note that I am not advocating to white-wash any future misuse of the 'standard opcode' space, but the case of V 0.7 is different a wider membership implemented it: e.g. BSC also implemented 0.7 in their accelerators, as did StreamComputing.

As a standards-development organization, we have learned our lesson and made all new drafts very explicit about their lifecycle state and what is a draft, a freeze (release candidate), and a ratified standard.

Finally, we have clearly put the burden to reconcile this into the upstream and maintain it (which is for everyone's benefit) on T-Head,

what is T-Head?

so there really are only benefits to the community in getting this done.

This is really one of the few win-win cases.

Philipp.