start filling in

[libreriscv.git] / isa_conflict_resolution.mdwn

diff --git a/isa_conflict_resolution.mdwn b/isa_conflict_resolution.mdwn
index d0ed7ad6f0b9daf60355bc4f620dedf7ee331248..f1a92a744ec7838809e950ae2c7bb57ea6e17062 100644 (file)
--- a/isa_conflict_resolution.mdwn
+++ b/isa_conflict_resolution.mdwn
@@ -13,12 +13,23 @@ within the current RISC-V Specification to transition to improved versions
 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,
@@ -30,15 +41,16 @@ the RISC-V Specification or not) without a bitter fight.
 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.
-
-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.
+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 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