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
+**All and any of the issues that were discussed, and all of those that
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.
+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
made efforts to point out that the consequences of not taking action
are clearly extreme and irreversible (which, unfortunately, given the
severity, some of the first group were unable to believe, despite there
-being clear historical precedent for the same mistake being made in
-other architectures).
+being clear historical precedent for the exact same mistake being made in
+other architectures, and the consequences on the same being absolutely
+clear).
However after a significant amount of time, certain clear requirements came
out of the discussion:
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)
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
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
projects / libreriscv.git / blobdiff