Status of the various RISC-V specification and policy

Thu Sep 30 10:30:08 PDT 2021

On Thu, 30 Sep 2021 08:06:42 PDT (-0700), markhimelstein at riscv.org wrote:
> Palmer,
>
>
>
> Thank you for your input.
>
>
>
> Our strong intention is to not change specs once frozen. I speak for the
> committees here and say that, in our opinion, declaring something frozen
> sets a very high bar for making any changes and is sufficient to allow code
> supporting an extension to be upstreamed. Of course if an unexpected and
> significant issue is discovered during the public review that absolutely
> must be addressed and cannot be deferred to a future extension (where the
> cost of not addressing the issue exceeds the cost of addressing it. for
> example introduces security vulnerabilities), then we will do so, as anyone
> should expect from a public review.
>
>
>
> We do not have versions of extensions. If an extension has a problem once
> ratified, we will issue errata. All implementers have to publish the errata
> if they use branding. We may release a new extension with the bulk of the
> original extension plus the errata fix at some future date.

This is probably at the core of my confusion here.

At the preface of the user ISA there is a table with the headings  
"Extension", "Version", and "Frozen"; contains a list of letters that 
look like extension name; and contains a list of numbers that look like 
versions of those extensions.

That nomenclature seems to carry on to some more recent specifications.  
For example the first page of 
https://github.com/riscv/riscv-v-spec/releases/download/v1.0/riscv-v-spec-1.0.pdf 
(tagged 11 days ago) is

    RISC-V "V" Vector Extension
    Version 1.0

I'm happy to answer the rest of the questions here, but I think trying 
to get on the same page about what is versioned and is proabbly the 
first step because that's a pretty key component of my worries.

> New extensions reserve the right to be incompatible with existing
> extensions but our philosophy is very much to minimize that and only allow
> the rare well-justified exceptions.  Reasons may include errata, security
> issues discovered, or new functionality we need to add that justifies
> creating an incompatibility, etc.
>
> What specifically do you see as an issue? What are you blocked on by our
> conventions? We need specific details to resolve any issues. Right now, I
> don't feel I have enough information from you.
>
>
>
> Thanks
>
> Mark
>
>
>
> P.S. We had some situations in the past, in part due to vendors not waiting
> for the specification processes to conclude, where implementers implemented
> non-confoming chips either with vendor-specific extensions using reserved
> opcodes and state, or implementing early drafts of standards-track
> proposals in the development state (will likely change). This is in the
> past and resolved. Anyone implementing non-standard extensions must
> advertise them as such and make it clear that these are not standard RISC-V
> extensions: this should make it clear for upstream projects that they will
> be dealing with the respective vendors for support and maintenance, and
> that any code implementing support for these extensions will be different
> from what covers the respective standard extensions. Whether upstream
> projects accept such changes, and what conditions they stipulate for
> acceptance of these changes, are beyond the control of RISC-V.  We also, as
> I have described to you many times, have instituted mandatory standards
> specification states for the front page of each specification to ensure
> clarity (any divergence from this is a bug and we work to fix these
> quickly).
>
>
> On Tue, Sep 28, 2021 at 11:34 AM Palmer Dabbelt <palmer at dabbelt.com> wrote:
>
>> On Mon, 27 Sep 2021 08:57:15 PDT (-0700), markhimelstein at riscv.org wrote:
>> > the words in this document :
>> >
>> >
>> https://wiki.riscv.org/plugins/servlet/mobile?contentId=13098230#content/view/13098230
>> >
>> > make it very clear when changes are allowed or not and likely or not.
>> >
>> > if you think the verbiage is somehow ambiguous please help us make it
>> better.
>>
>> I'm not really worried about changes, I'm worried about a committment to
>> future compatibility.  When we take code into the kernel (and most other
>> core systems projects) we're taking on the burden of supporting (until
>> someone can prove there are no more users), which is very difficult to
>> do when the ISA changes in an incompatible fashion.  The whole point of
>> agreeing on the frozen thing was that it gave us a committment from the
>> specifcation authors that the future ISA would be compatible with th
>> frozen extensions.
>>
>> We're already in this spot with the V extension and the whole stable
>> thing, this definitaion of frozen looks very much like what was has led
>> to the issues there.  Saying the spec won't change really isn't
>> meaningful, it's saying future specs will be compatible that's
>> important.  Nothing in this whole rule touches on compatibility, and I
>> really don't want to end up in a bigger mess than we're already in.
>>
>> (Also: some PGE subcontractor drove a crane into my house, so things are
>> a bit chaotic on my end.  If you have that list of what's officially
>> frozen, can you send it out?  I'll try to take a look ASAP, as then I
>> can at least focus the discussion on what's relevant right now.)
>>
>> >
>> > Mark
>> > --------
>> > sent from a mobile device. please forgive any typos.
>> >
>> >> On Sep 27, 2021, at 8:50 AM, Palmer Dabbelt <palmer at dabbelt.com> wrote:
>> >>
>> >> On Tue, 21 Sep 2021 17:20:17 PDT (-0700), atishp at atishpatra.org wrote:
>> >>> Hi All,
>> >>> Please find the below email from Stephano about the freeze
>> announcement for
>> >>> various RISC-V specifications that will be part of privilege
>> specification
>> >>> v1.12.
>> >>> All the review discussions are happening in the isa-dev mailing list.
>> The
>> >>> review period will be open for 45 days ending Sunday October 31, 2021.
>> >>>
>> >>> I just want to highlight the fact that the *H*, *V, SvPBMT, CMO
>> extensions
>> >>> are frozen now. *This will help us merge some patches that have been
>> >>> present in the mailing list for a while.
>> >>>
>> >>> Here are the ratification policy and extension life cycle documents
>> present
>> >>> in the public. If you have any questions regarding this, please check
>> with
>> >>> Mark/Stephano (cc'd).
>> >>>
>> >>> Ratification policy:
>> >>>
>> https://docs.google.com/document/d/1-UlaSGqk59_myeuPMrV9gyuaIgnmFzGh5Gfy_tpViwM/edit
>> >>>
>> >>> Extension life cycle:
>> >>>
>> https://docs.google.com/presentation/d/1nQ5uFb39KA6gvUi5SReWfIQSiRN7hp6z7ZPfctE4mKk/edit#slide=id.p1
>> >>
>> >> I'm still buried after Plumbers, but one of the bits on my TODO list
>> was to look throught the new definitions for frozen and stable.  Nothing in
>> this extension life cycle talks about the point at which compatibility will
>> be maintained, which was really the central point behind frozen before.
>> >>
>> >> Are there more concrete definitions somewhere?
>>