start filling in

[libreriscv.git] / isa_conflict_resolution.mdwn

diff --git a/isa_conflict_resolution.mdwn b/isa_conflict_resolution.mdwn
index 746928ff14b9397d2f01ed7d54219b1954315f39..bf036f64907955bde74e7b1eee0b7823d5a247ee 100644 (file)
--- a/isa_conflict_resolution.mdwn
+++ b/isa_conflict_resolution.mdwn
@@ -148,7 +148,8 @@ 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
+percent guaranteed to occur (*outside* of the control and remit of the
+RISC-V Foundation), 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.
@@ -216,13 +217,14 @@ take into account the flaws pointed out by trying to use "MISA":
 * Each custom-defined bit of the MISA-like CSR would (mutually-exclusively)
   redirect binary encoding(s) to specific encodings
 * No Extension would *actually* be disabled: its internal state would
-  be left on (permanently) so that switching could be done inside
-  inner loops.
+  be left on (permanently) so that switching of ISA decoding
+  could be done inside inner loops without adverse impact on
+  performance.
 
 Whilst it was the first "workable" solution it was also noted that the
-scheme is quite invasive: it requires an entirely new CSR to be added
-to the privileged spec.  This does not completely fulfil the "minimum
-impact" requirement.
+scheme is invasive: it requires an entirely new CSR to be added
+to the privileged spec (thus making existing implementations redundant).
+This does not fulfil the "minimum impact" requirement.
 
 Also interesting around the same time an additional discussion was
 raised that covered the *compiler* side of the same equation.  This
@@ -237,13 +239,13 @@ separate page?  review this para?**)
 
 TBD paraphrase and clarify
 
-Coming out of the software-related proposal by Jacob, which hinged on
-the idea of a global gcc / binutils database that kept and coordinated
-architectural encodings, was to quite simply make the mvendorid and
-marchid CSRs have WARL (writeable) characteristics.  For instances
-where mvendorid and marchid are readable, that would be taken to be
-a Standards-mandatory "declaration" that the architecture has *no*
-Custom Extensions.
+Coming out of the software-related proposal by Jacob Bachmeyer, which
+hinged on the idea of a globally-maintained gcc / binutils database
+that kept and coordinated architectural encodings (curated by the Free
+Software Foundation), was to quite simply make the mvendorid and marchid
+CSRs have WARL (writeable) characteristics.  For instances where mvendorid
+and marchid are readable, that would be taken to be a Standards-mandatory
+"declaration" that the architecture has *no* Custom Extensions.
 
 This incredibly simple non-invasive idea has some unique and distinct
 advantages over other proposals: