start filling in
[libreriscv.git] / isa_conflict_resolution.mdwn
index b8291c32cd88f369d9b11ec43ae7ef35e30c389a..d743e9c30a6e667685c610623ce0583cb2ff67e2 100644 (file)
@@ -13,12 +13,23 @@ within the current RISC-V Specification to transition to improved versions
 of the standard, regardless of whether the fixes are absolutely critical
 show-stoppers or whether they are just keeping the standard up-to-date (2).
 
+With no transition path there is guaranteed to be tension and conflict
+within the RISC-V Community over whether revisions should be made:
+should existing legacy designs be prioritised, mutually-exclusively over
+future designs (and what happens during the transition period is absolute
+chaos, with the compiler toolchain, software ecosystem and ultimately
+the end-users bearing the full brunt of the impact).  If several
+overlapping revisions are required that have not yet transitioned out
+of use (which could take well over two decades to occur) the situation
+becomes disastrous for the credibility of the entire RISC-V ecosystem.
+
 It was also pointed out that Compliance is an extremely important factor
 to take into consideration, and that Custom Extensions (as being optional)
-effectively fall entirely outside of the Compliance Testing.  At this
-point in the discussion however it was not yet noted the stark problem
-that the *mandatory* RISC-V Specification also faces, by virtue of there
-being no transitional way to bring in show-stopping critical alterations.
+effectively and quite reasonably fall entirely outside of the scope of
+Compliance Testing.  At this point in the discussion however it was not
+yet noted the stark problem that the *mandatory* RISC-V Specification
+also faces, by virtue of there being no transitional way to bring in
+show-stopping critical alterations.
 
 To put this into perspective, just taking into account hardware costs
 alone: with production mask charges for 28nm being around USD $1.5m,
@@ -30,15 +41,16 @@ the RISC-V Specification or not) without a bitter fight.
 It was also pointed out that there will be significant software tool
 maintenance costs for manufacturers, meaning that the probability will
 be extremely high that they will refuse to shoulder such costs, and
-publish hopelessly out-of-date unpatched tools.  This practice is
-well-known to result in security flaws going unpatched, with one
-of many immediate consequences being that product gets discarded into
-landfill.
+will publish and continue to publish (and use) hopelessly out-of-date
+unpatched tools.  This practice is well-known to result in security
+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
-were not, can be avoided by providing a forwards and backwards
-compatible transition path between the current and future *mandatory*
-parts of revisions of the RISC-V ISA Standard.
+**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.**
 
 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
@@ -47,8 +59,9 @@ camps: one that wanted things to remain as they are, and another that
 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:
@@ -65,6 +78,7 @@ Several proposals were put forward (and some are still under discussion)
 
 * "Do nothing": problem is not severe: no action needed.
 * "Do nothing": problem is out-of-scope for RISC-V Foundation.
+* "Do nothing": problem complicates Compliance Testing (and is out of scope)
 * "MISA": the MISA CSR enables and disables extensions already: use that
 * "MISA-like": a new CSR which switches in and out new encodings
   (without destroying state)
@@ -75,32 +89,197 @@ Each of these will be discussed below in their own sections.
 
 # Do nothing (no problem exists)
 
-TBD
+TBD (basically not an option).
+
+There were several solutions offered that fell into this category.
+A few of them are listed in the introduction; more are listed below,
+and it was exhaustively (and exhaustingly) established that none of
+them are workable.
+
+Initially it was pointed out that Fabless Semiconductor companies could
+simply license multiple Custom Extensions and a suitable RISC-V core, and
+modify them accordingly.  The Fabless Semi Company would be responsible
+for paying the NREs on re-developing the test vectors (as the extension
+licensers would be extremely unlikely to do that without payment), and
+given that said Companies have an "integration" job to do, it would
+be reasonable to expect them to have such additional costs as well.
+
+The costs of this approach were outlined and discussed as being
+disproportionate and extreme compared to the actual likely cost of
+licensing the Custom Extensions in the first place.  Additionally it
+was pointed out that not only hardware NREs would be involved but
+custom software tools (compilers and more) would also be required
+(and maintained separately, on the basis that upstream would not
+accept them except under extreme pressure, and then only with
+prejudice).
+
+All similar schemes involving customisation of the custom extensions
+were likewise rejected, but not before the customisation process was
+mistakenly conflated with tne *normal* integration process of developing
+a custom processor (Bus Architectures, Cache layouts, peripheral layouts).
+
+The most compelling hardware-related reason (excluding the severe impact on
+the software ecosystem) for rejecting the customisation-of-customisation
+approach was the case where Extensions were using an instruction encoding
+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,
+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)
 
-TBD
+TBD (basically, may not be RV Foundation's "scope", still results in
+problem, so not an option)
+
+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 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
+  out of scope, Compliance testing of simultaneous legacy (old revisions of
+  ISA Standards) and current (new revisions of ISA Standard) definitely
+  is not.  Efforts to reduce *Compliance Testing* complexity is therefore
+  "Compliance Tail Wagging Standard Dog".
+* Beyond a certain threshold, complexity of Compliance Testing is so
+  burdensome that it risks outright rejection of the entire Standard.
+
+Meeting these two diametrically-opposed perspectives requires that the
+solution be very, very simple.
 
 # MISA
 
-TBD
+TBD, basically MISA not suitable
 
-> * MISA Extension disabling is permitted (optionally) to DESTROY the state
-> information (which means that it *has* to be re-initialised just to be
-> safe... mistake in the standard, there), and
-> * MISA was only designed to cover Standard Extensions.
+MISA permits extensions to be disabled by masking out the relevant bit.
+Hypothetically it could be used to disable one extension, then enable
+another that happens to use the same binary encoding.
+
+*However*:
+
+* MISA Extension disabling is permitted (optionally) to **destroy**
+  the state information.  Thus it is totally unsuitable for cases
+  where instructions from different Custom extensions are needed in
+  quick succession.
+* MISA was only designed to cover Standard Extensions.
+* There is nothing to prevent multiple Extensions being enabled
+  that wish to simultaneously interpret the same binary encoding.
  
+Overall, whilst the MISA concept is a step in the right direction it's
+a hundred percent unsuitable for solving the problem.
+
 # MISA-like
 
-TBD
+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
+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.
+
+This incredibly simple non-invasive idea has some unique and distinct
+advantages over other proposals:
+
+* Existing designs - even though the specification is not finalised
+  (but has "frozen" aspects) - would be completely unaffected: the
+  change is to the "wording" of the specification to "retrospectively"
+  fit reality.
+* Unlike with the MISA idea this is *purely* at the "decode" phase:
+  no internal Extension state information is permitted to be disabled,
+  altered or destroyed as a direct result of writing to the
+  mvendor/march-id CSRs.
+* Compliance Testing may be carried out with a different vendorid/marchid
+  tuple set prior to a test, allowing a vendor to claim *Certified*
+  compatibility with *both* one (or more) legacy variants of the RISC-V
+  Specification *and* with a present one.
+* With sufficient care taken in the implementation an implementor
+  may have multiple interpretations of the same binary encoding within
+  an inner loop, with a single instruction (to the WARL register)
+  changing the meaning.
+
+A couple of points were made:
+
+* Compliance Testing may **fail** any system that has mvendorid/marchid
+  as WARL.  This however is a clear case of "Compliance Tail Wagging Standard
+  Dog".
+* The redirection of meaning of certain binary encodings to multiple
+  engines was considered extreme, eyebrow-raising, and also (importantly)
+  potentially expensive, introducing significant latency at the decode
+  phase.
+
+On this latter point, it was observed that MISA already switches out entire
+sets of instructions (interacts at the "decode" phase).  The difference
+between what MISA does and the mvendor/march-id WARL idea is that whilst
+MISA only switches instruction decoding on (or off), the WARL idea
+*redirects* encoding, to *different* engines, fortunately in a deliberately
+mutually-exclusive fashion.
 
->  In an earlier part of the thread someone kindly pointed out that MISA
-> already switches out entire sets of instructions [which interacts at the
-> "decode" phase].  However it was noted after a few days of investigating
 > that particular lead that:
 > 
 > * MISA Extension disabling is permitted (optionally) to DESTROY the state
@@ -145,7 +324,7 @@ TBD
 
 # ioctl-like
 
-TBD
+TBD - [[ioctl]] for full details, summary kept here
 
 # Discussion and analysis