start filling in

[libreriscv.git] / isa_conflict_resolution.mdwn

diff --git a/isa_conflict_resolution.mdwn b/isa_conflict_resolution.mdwn
index 85da256d0320074ae3dd3c97d42d6fb789142c53..f7e06b30b8698d177e9231e0c000387cdf826cf3 100644 (file)
--- a/isa_conflict_resolution.mdwn
+++ b/isa_conflict_resolution.mdwn
@@ -41,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.
+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.
+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