add executive summary

[libreriscv.git] / isa_conflict_resolution.mdwn

diff --git a/isa_conflict_resolution.mdwn b/isa_conflict_resolution.mdwn
index d09b0c7c9c4bd6a066dd09c013232c26eb54ba1e..01e93d5e71a035b9cfcb7a127db5ae42c2293938 100644 (file)
--- a/isa_conflict_resolution.mdwn
+++ b/isa_conflict_resolution.mdwn
@@ -1,5 +1,18 @@
 # Resolving ISA conflicts and providing a pain-free RISC-V Standards Upgrade Path
 
+**Executive Summary:** A non-invasive backwards-compatible change to make
+mvendorid and marchid being read-only to be a formal declaration of an
+architecture having no Custom Extensions, and being permitted to be
+WARL in order to support multiple simultaneous architectures on the
+same processor (or hart) permits not only backwards and forwards
+compatibility with existing implementations of the RISC-V Standard,
+not only permits seamless transitions to future versions of the
+RISC-V Standard (something that is not possible at the moment), but
+permanently fixes the problem of clashes in Custom Extension opcodes
+on a global basis.
+
+--------
+
 In a lengthy thread that ironically was full of conflict indicative
 of the future direction in which RISC-V will go if left unresolved,
 multiple Custom Extensions were noted to be permitted free rein to
@@ -552,7 +565,8 @@ So to summarise:
   cannot take a back seat.  If it does, clear historical precedent shows
   100% what the outcome will be (1).
 * Making the mvendorid and marchid CSRs WARL solves the problem in a
-  minimal to zero-disruptive fashion.
+  minimal to zero-disruptive backwards-compatible fashion that provides
+  indefinite transparent *forwards*-compatibility.
 * The retro-fitting cost onto existing implementations (even though the
   specification has not been finalised) is zero to negligeable
   (only changes to words in the specification required at this time:
@@ -567,10 +581,10 @@ So to summarise:
 * 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,
-  simultaneously), in order to 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 (legacy) hardware.
+  simultaneously), in order to support end-customer legacy scenarios and
+  provide the same with a way to avoid "impossible-to-make" decisions that
+  throw out ultra-costly multi-decade-investment in proprietary legacy
+  software at the same as the (legacy) hardware.
 
 -------