of the standard, regardless of whether the fixes are absolutely critical
show-stoppers or whether they are just keeping the standard up-to-date (2).
+With no transition path there is guaranteed to be tension and conflict
+within the RISC-V Community over whether revisions should be made:
+should existing legacy designs be prioritised, mutually-exclusively over
+future designs (and what happens during the transition period is absolute
+chaos, with the compiler toolchain, software ecosystem and ultimately
+the end-users bearing the full brunt of the impact). If several
+overlapping revisions are required that have not yet transitioned out
+of use (which could take well over two decades to occur) the situation
+becomes disastrous for the credibility of the entire RISC-V ecosystem.
+
It was also pointed out that Compliance is an extremely important factor
to take into consideration, and that Custom Extensions (as being optional)
-effectively fall entirely outside of the Compliance Testing. At this
-point in the discussion however it was not yet noted the stark problem
-that the *mandatory* RISC-V Specification also faces, by virtue of there
-being no transitional way to bring in show-stopping critical alterations.
+effectively and quite reasonably fall entirely outside of the scope of
+Compliance Testing. At this point in the discussion however it was not
+yet noted the stark problem that the *mandatory* RISC-V Specification
+also faces, by virtue of there being no transitional way to bring in
+show-stopping critical alterations.
To put this into perspective, just taking into account hardware costs
alone: with production mask charges for 28nm being around USD $1.5m,
It was also pointed out that there will be significant software tool
maintenance costs for manufacturers, meaning that the probability will
be extremely high that they will refuse to shoulder such costs, and
-publish hopelessly out-of-date unpatched tools. This practice is
-well-known to result in security flaws going unpatched, with one
-of many immediate consequences being that product gets discarded into
-landfill.
+will publish and continue to publish (and use) hopelessly out-of-date
+unpatched tools. This practice is well-known to result in security
+flaws going unpatched, with one of many immediate undesirable consequences
+being that product in extremely large volume gets discarded into landfill.
-All and any of the issues that were discussed, and all of those that
-were not, can be avoided by providing a forwards and backwards
-compatible transition path between the current and future *mandatory*
-parts of revisions of the RISC-V ISA Standard.
+**All and any of the issues that were discussed, and all of those that
+were not, can be avoided by providing a hardware-level runtime-enabled
+forwards and backwards compatible transition path between *all* parts
+(mandatory or not) of current and future revisions of the RISC-V ISA
+Standard.**
The rest of the discussion - indicative as it was of the stark mutually
exclusive gap being faced by the RISC-V ISA Standard given that it does
made efforts to point out that the consequences of not taking action
are clearly extreme and irreversible (which, unfortunately, given the
severity, some of the first group were unable to believe, despite there
-being clear historical precedent for the same mistake being made in
-other architectures).
+being clear historical precedent for the exact same mistake being made in
+other architectures, and the consequences on the same being absolutely
+clear).
However after a significant amount of time, certain clear requirements came
out of the discussion:
* "Do nothing": problem is not severe: no action needed.
* "Do nothing": problem is out-of-scope for RISC-V Foundation.
+* "Do nothing": problem complicates Compliance Testing (and is out of scope)
* "MISA": the MISA CSR enables and disables extensions already: use that
* "MISA-like": a new CSR which switches in and out new encodings
(without destroying state)
# Do nothing (no problem exists)
-TBD
+TBD (basically not an option).
+
+There were several solutions offered that fell into this category.
+A few of them are listed in the introduction; more are listed below,
+and it was exhaustively (and exhaustingly) established that none of
+them are workable.
+
+Initially it was pointed out that Fabless Semiconductor companies could
+simply license multiple Custom Extensions and a suitable RISC-V core, and
+modify them accordingly. The Fabless Semi Company would be responsible
+for paying the NREs on re-developing the test vectors (as the extension
+licensers would be extremely unlikely to do that without payment), and
+given that said Companies have an "integration" job to do, it would
+be reasonable to expect them to have such additional costs as well.
+
+The costs of this approach were outlined and discussed as being
+disproportionate and extreme compared to the actual likely cost of
+licensing the Custom Extensions in the first place. Additionally it
+was pointed out that not only hardware NREs would be involved but
+custom software tools (compilers and more) would also be required
+(and maintained separately, on the basis that upstream would not
+accept them except under extreme pressure, and then only with
+prejudice).
+
+All similar schemes involving customisation of the custom extensions
+were likewise rejected, but not before the customisation process was
+mistakenly conflated with tne *normal* integration process of developing
+a custom processor (Bus Architectures, Cache layouts, peripheral layouts).
+
+The most compelling hardware-related reason (excluding the severe impact on
+the software ecosystem) for rejecting the customisation-of-customisation
+approach was the case where Extensions were using an instruction encoding
+space (48-bit, 64-bit) *greater* than that which the chosen core could
+cope with (32-bit, 48-bit).
+
+Overall, none of the options presented were feasible, and, in addition,
+with no clear leadership from the RISC-V Foundation on how to avoid
+global world-wide encoding conflict, even if they were followed through,
+still would result in the failure of the RISC-V ecosystem due to
+irreversible global conflicting ISA binary-encoding meanings (POWERPC's
+Altivec / SPE nightmare).
+
+This in addition to the case where the RISC-V Foundation wishes to
+fix a critical show-stopping update to the Standard, post-release,
+where billions of dollars have been spent on deploying RISC-V in the
+field.
# Do nothing (out of scope)
-TBD
+TBD (basically, may not be RV Foundation's "scope", still results in
+problem, so not an option)
+
+This was one of the first arguments presented: The RISC-V Foundation
+considers Custom Extensions to be "out of scope"; that "it's not their
+problem, therefore there isn't a problem".
+
+The logical errors in this argument were quickly enumerated: namely that
+the RISC-V Foundation is not in control of the uses to which RISC-V is
+put, such that public global conflicts in binary-encoding are a hundred
+percent guaranteed to occur, and a hundred percent guaranteed to occur in
+*commodity* hardware where Debian, Fedora, SUSE and other distros will
+be hardest hit by the resultant chaos, and that will just be the more
+"visible" aspect of the underlying problem.
+
+# Do nothing (Compliance too complex, therefore out of scope)
+
+TBD (basically, may not be RV Foundation's "scope", still results in
+problem, so not an option)
+
+Two interestingly diametrically-opposed equally valid arguments exist here:
+
+* Whilst Compliance testing of Custom Extensions is definitely legitimately
+ out of scope, Compliance testing of simultaneous legacy (old revisions of
+ ISA Standards) and current (new revisions of ISA Standard) definitely
+ is not. Efforts to reduce *Compliance Testing* complexity is therefore
+ "Compliance Tail Wagging Standard Dog".
+* Beyond a certain threshold, complexity of Compliance Testing is so
+ burdensome that it risks outright rejection of the entire Standard.
+
+Meeting these two diametrically-opposed perspectives requires that the
+solution be very, very simple.
# MISA
-TBD
+TBD, basically MISA not suitable
-> * MISA Extension disabling is permitted (optionally) to DESTROY the state
-> information (which means that it *has* to be re-initialised just to be
-> safe... mistake in the standard, there), and
-> * MISA was only designed to cover Standard Extensions.
+MISA permits extensions to be disabled by masking out the relevant bit.
+Hypothetically it could be used to disable one extension, then enable
+another that happens to use the same binary encoding.
+
+*However*:
+
+* MISA Extension disabling is permitted (optionally) to **destroy**
+ the state information. Thus it is totally unsuitable for cases
+ where instructions from different Custom extensions are needed in
+ quick succession.
+* MISA was only designed to cover Standard Extensions.
+* There is nothing to prevent multiple Extensions being enabled
+ that wish to simultaneously interpret the same binary encoding.
+Overall, whilst the MISA concept is a step in the right direction it's
+a hundred percent unsuitable for solving the problem.
+
# MISA-like
-TBD
+TBD, basically same as mvend/march WARL except needs an extra CSR where
+mv/ma doesn't.
# mvendorid/marchid WARL
-TBD
+TBD paraphrase and clarify
> In an earlier part of the thread someone kindly pointed out that MISA
> already switches out entire sets of instructions [which interacts at the
# ioctl-like
-TBD
+TBD - [[ioctl]] for full details, summary kept here
# Discussion and analysis
projects / libreriscv.git / blobdiff