On Thu, May 11, 2023 at 02:27:44PM -0700, Atish Patra wrote: > > The other thought I had was that perhaps some software may choose not to > > implement version x.y.0 of an extension and only support x.z.0, z > y > > for some reason. We'd want to refuse that extension if the extension is > > found, but the version is not listed as being something compatible with > > x.z.0, and while the ISA spec does say that the default assumption is > > 2p0 for unversioned extensions in its current form, I struggle to > > extrapolate that to extensions not currently part of the unpriv spec, > > but rather defined on their own. > > > > That's a fair point. However, any new RVI ISA extension will only have v1.0 > as per my knowledge. Any new feature will have to be part of a > different extension. > At least that was the plan discussed last year. That's more than last year at this point, and nothing has changed in the documentation! Talk's cheap, ehh? > https://github.com/riscv/riscv-isa-manual/issues/781#issuecomment-983222655 > > Are you aware of any discussion that changes this ? It's called "trust issues". I am far less worried about the addition of new features though than the removal of existing ones. Part of me fears for fence.i-less systems for example, but there would be other ways to bodge around the mess if it comes to pass. If we are *sure* that no extensions will modify features additively or subtractively, then this may not be needed at all & I can avoid having to bend dt-validate to my will. We have no guarantees for vendor extensions on that front either, they're free to do what they like w.r.t. versioning, no?
Attachment:
signature.asc
Description: PGP signature
