start filling in

[libreriscv.git] / isa_conflict_resolution.mdwn

diff --git a/isa_conflict_resolution.mdwn b/isa_conflict_resolution.mdwn
index 13f0c56813e14b0e7e45a2d258ca4bdac7bef847..b7d187add35c5ececa614919fa8b5a0ba5e7305a 100644 (file)
--- a/isa_conflict_resolution.mdwn
+++ b/isa_conflict_resolution.mdwn
@@ -366,6 +366,27 @@ and is the only idea that meets the three requirements:
   that have Custom Extensions, come under the "vendor/arch-id read only
   is a declaration of having no Custom Extensions" fall-back category)
 
+So to summarise:
+
+* The consequences of not tackling this are severe: the RISC-V Foundation
+  cannot take a back seat.  If it does, clear historical precedent shows
+  100% what the outcome will be (1).
+* The retro-fitting cost onto existing implementations (even though the
+  specification has not been finalised) is negligeable
+  (changes to words in the specification)
+* The benefits are clear (pain-free transition path for vendors to safely
+  upgrade over time; no fights over Custom opcode space; no hassle for
+  software toolchain; no hassle for GNU/Linux Distros)
+* The implementation details are clear (and problem-free except for
+  vendors who insist on deploying dozens of conflicting Custom Extensions:
+  an extreme unlikely outlier).
+* Compliance Testing is straightforward and allows vendors to seek and
+  obtain *multiple* Compliance Certificates with past, present and future
+  variants of the RISC-V Standard (in the exact same processor), in order
+  support legacy customers and provide same customers with a way to avoid
+  "impossible-to-make" decisions that throw out ultra-expensive multi-decade
+  proprietary legacy software at the same as the hardware.
+
 # Conversation Exerpts
 
 The following conversation exerpts are taken from the ISA-dev discussion