start filling in

[libreriscv.git] / isa_conflict_resolution.mdwn

diff --git a/isa_conflict_resolution.mdwn b/isa_conflict_resolution.mdwn
index 3623a89c7c9767c9de85c166b5d105e1e7ee8d24..d72c0a54e1e3dee92d795640b90bcb7bc3836a8d 100644 (file)
--- a/isa_conflict_resolution.mdwn
+++ b/isa_conflict_resolution.mdwn
@@ -125,9 +125,16 @@ space (48-bit, 64-bit) *greater* than that which the chosen core could
 cope with (32-bit, 48-bit).
 
 Overall, none of the options presented were feasible, and, in addition,
-even if they were followed through, still would result in the failure
-of the RISC-V ecosystem due to global conflicting ISA binary-encoding
-meanings (POWERPC's Altivec / SPE nightmare).
+with no clear leadership from the RISC-V Foundation on how to avoid
+global world-wide encoding conflict, even if they were followed through,
+still would result in the failure of the RISC-V ecosystem due to
+irreversible global conflicting ISA binary-encoding meanings (POWERPC's
+Altivec / SPE nightmare).
+
+This in addition to the case where the RISC-V Foundation wishes to
+fix a critical show-stopping update to the Standard, post-release,
+where billions of dollars have been spent on deploying RISC-V in the
+field.
 
 # Do nothing (out of scope)
 
@@ -138,19 +145,28 @@ This was one of the first arguments presented: The RISC-V Foundation
 considers Custom Extensions to be "out of scope"; that "it's not their
 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 use-cases, such
-that binary-encoding is a hundred percent guaranteed to occur, 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.
+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
+*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.
 
 # Do nothing (Compliance too complex, therefore out of scope)
 
 TBD (basically, may not be RV Foundation's "scope", still results in
 problem, so not an option)
 
+The summary here was that Compliance testing of Custom Extensions is
+not just out-of-scope, but even if it was taken into account that
+binary-encoding meanings could change, it would still be out-of-scope.
+
+However at the time that this argument was made, it had not yet been
+appreciated fully the impact that revisions to the Standard would have,
+when billions of dollars worth of (older, legacy) RISC-V hardware had
+already been deployed.
+
 Two interestingly diametrically-opposed equally valid arguments exist here:
 
 * Whilst Compliance testing of Custom Extensions is definitely legitimately
@@ -190,6 +206,31 @@ a hundred percent unsuitable for solving the problem.
 TBD, basically same as mvend/march WARL except needs an extra CSR where
 mv/ma doesn't.
 
+Out of the MISA discussion came a "MISA-like" proposal, which would
+take into account the flaws pointed out by trying to use "MISA":
+
+* The MISA-like CSR's meaning would be identified by compilers using the
+  mvendor-id/march-id tuple as a compiler target
+* 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.
+
+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.
+
+Also interesting around the same time an additional discussion was
+raised that covered the *compiler* side of the same equation.  This
+revolved around using mvendorid-marchid tuples at the compiler level,
+to be put into assembly output (by gcc), preserving the required
+*globally* unique identifying information for binutils to successfully
+turn the custom instruction into an actual binary-encoding (plus
+binary-encoding of the context-switching information).  (**TBD, Jacob,
+separate page?  review this para?**)
+
 # mvendorid/marchid WARL
 
 TBD paraphrase and clarify