An advisor addendum to V

[David-Horner]

As we approach V V1.0 we will be scoping what is contained in the initial release.

Over time, especially as the basic model have evolved, many assumption have changed and as a consequence so have tradeoffs.

There is not time to revisit all the decisions and the basis upon which they were made.
However, there may be many suggestions that were once untenable that are now viable and easily co-exit with the V1.0 release.
These should be added to an addendum.

Categories that come to mind are

limited facilities certification.

Can an implementation be certified as V compatible if it excludes specific features?
We anticipate that once the Zfinx is ratified it will make backward compliant implementations that have float operations but do not address the FD registers.
Can these get conditional V cetification ? Or a limited certification for those features it does have? (e.g. CV-fscalar+finx)

subsets that coexist

Guidance on which subsets are interdependent to assist those who would opt for limited facilities (and perhaps contribute to certification effort for some subset to allow their choice certification.

relaxations of restrictions (and certification).

Many current restrictions are in place to ensure the burden to support more complete implementations is not born by all.
e.g. although vcompress could be restartable with a non-zero vstart, it is currently not allowed.
A machine that has custom extensions my already have to support the same complexity in their instruction restart and thus get that functionality for free. Will such a machine be penalized for being more robust?
Should software rely on vcompress trap forcing restart=0? (I don't think so)

custom expansion

gotchas that would invalidate a otherwise certifiable implementation.
Proposed methods that are consistent, and ideally partially supported by the various interaction spaces - Software Development and support Ecosystems, Operating Systems, Validation, Verification and certification, application domains/profiles, etc.

lessons learned

I envision lessons from gcc and LLVM collaboration with open cpu designs (RISCV, OpenRISC,...) both good and bad.
And from collaboration of gcc and LLVM with closed design vendors (x86, ARM, etc).
Lessons learned from certification efforts / standards bodies.
LL from any other source that will help guide adoption, implementation and delivery of the spec in all relevant application spaces.

This might best be set up as a wiki.

[David-Horner]

Raised over at #527
Another section for the V addendum would be adding issues that are to be resolved after V1.0 issues?
That would help give guidance on what parts of the design are being considered for relaxation and will allow ecosystem builders the possibility to retain flexibility, rather than hard-coding to the V1.0 spec.