[RFC] Toolchain interface for privilege spec related stuff.


Krste Asanovic
 

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

|





Andrew Waterman
 



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.
 

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

|





Philipp Tomsich <philipp.tomsich@...>
 



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.


Andrew Waterman
 



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.

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, so there really are only benefits to the community in getting this done.
This is really one of the few win-win cases.

Philipp.


Andrew Waterman
 



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.

Of course vendor branches are undesirable--but that is part of the reinforcement mechanism to prevent this behavior from happening in the first place.  If you don't like it, don't diverge from the standard.

 
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.


David Horner
 


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.


Andrew Waterman
 



On Fri, Sep 17, 2021 at 3:32 AM David Horner <ds2horner@...> wrote:


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.

Andrew is not.

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.


Krste Asanovic
 

For the case of the Alibaba vector extension based on pre-frozen 0.7.1 draft, we had already agreed to use the -X custom extension name for this, so there is no confusion about this being a RISC-V standard.

We are trying to be crystal clear at which point the standards are ready for production use.  Apparently, our earlier statements were not clear enough and we are striving to be clearer.
Using the 0.7.1 version name in long-lived upstream tool chains will only add to confusion about standard status of pre-frozen drafts.

In some cases, an upstream software project can support non-standard extensions in a modular way such that a vendor can maintain in the same tree with little impact on others, and hopefully over time the architecture of the software projects will evolve to increase their support for this modularity (not only RISC-V, but other ISAs are seeing demand for custom ISA extensions).

But with the current state (or even imagined future state) of the software architecture of some projects, some forms of non-standard extension can not be quarantined in this way and propagate complexity throughout the entire code base to the detriment of standard code development and maintenance.  We cannot let non-standard code interfere with the standard RISC-V code base in these cases.

These statements are necessarily somewhat abstract as the details of each upstream project’s software architecture and the consequences of each form of non-standard extension vary widely, but I hope the community agrees on these general principles.

Krste

On Sep 17, 2021, at 3:41 AM, Andrew Waterman <andrew@...> wrote:



On Fri, Sep 17, 2021 at 3:32 AM David Horner <ds2horner@...> wrote:


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.

Andrew is not.

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.