reword redraft mvendorid-marchid idea

diff --git a/isa_conflict_resolution.mdwn b/isa_conflict_resolution.mdwn
index 17a92df9c7bf3eaa6faa445fa4465886ca753d2e..2499cc87da82744ce23efd5280bfe30154c2e43f 100644 (file)
--- a/isa_conflict_resolution.mdwn
+++ b/isa_conflict_resolution.mdwn
@@ -289,6 +289,26 @@ a controlled means and method of supporting multiple (future, past and
 present) versions of the **Base** ISA, Custom Extensions and even
 completely foreign ISAs in the same processor.
 
+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.
+
 **This is the only one of the proposals that meet the full requirements**
 
 # ioctl-like <a name="ioctl-like"></a>

diff --git a/isa_conflict_resolution/mvendor_march_warl.mdwn b/isa_conflict_resolution/mvendor_march_warl.mdwn
index 9f3ef78a30b6a16d4fde5cc53227c214d30ef93c..d7daff7cc5ce46680ff8840767fbf868685bcbb0 100644 (file)
--- a/isa_conflict_resolution/mvendor_march_warl.mdwn
+++ b/isa_conflict_resolution/mvendor_march_warl.mdwn
@@ -1,12 +1,9 @@
 # mvendorid/marchid WARL <a name="mvendor_marchid_warl"></a>
 
-(Summary: the only idea that meets the full requirements.  Needs
- toolchain backup, but only when the first chip is released)
-
-This proposal is make the mvendorid and marchid CSRs have WARL (writeable)
-characteristics.  Each unique tuple identifies (including on a per-hart
-basis within the same processor) and switches over to a completely
-separate and distinct binary-encoding support such that:
+This proposal is to make the mvendorid and marchid CSRs have WARL (writeable)
+characteristics.  Each unique tuple (including on a per-hart
+basis within the same processor) uniquely identifies and permits switch- over
+to a completely separate and distinct binary-encoding such that:
 
 * Different versions (legacy and new) of the RISC-V Standard may be
   supported within the same processor
@@ -19,37 +16,49 @@ taken to be a Standards-mandatory "declaration" that the architecture
 has *no* Custom Extensions (and that it conforms precisely to one and
 only one specific variant of the RISC-V Specification).
 
-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
+Beyond that, the change is so simple and straightforward that there is not
+much to discuss aside from its feasibility and its implications.  The
+main considerations are:
+
+* Compliance.  What impact does the change have on Compliance (and testing)?
+* Implementation.  Is it feasible and practical?
+* Exception-handlling.  What happens during a trap?
+* Backwards compatibility.  Is the change zero-impact (for existing systems)
+* Forwards compatibility.  Does the change affect (limit) future hardware?
+
+## Compliance
+
+It was pointed out early in the discussions that Compliance Testing may
+**fail** any system that has mvendorid/marchid as WARL.  This however is a
+clear case of "Compliance Tail Wagging Standard Dog".  However it *was*
+recognised that overly complex Compliance Testing would result
+in rejection of the entire RISC-V Standard.
+
+A simple solution is to modify the Compliance Test Suite to specify the
+required mvendorid/marchid to be tested, as a parameter to the test
+applications.  The test can be run multiple times, providing the
+implementor with multiple Compliance Certificates for the same processor,
+against *different variants* of past, present and future RISC-V Standards.
+
+*This is clearly a desirable characteristic*
+
+It's been noted that there may be certain legitimate cases where
+an mvendorid-marchid should *specifically* not be tested for RISC-V
+Certification Compliance: native support for foreign architectures (not
+related to the JIT Extension: *actual* full entire non-RISC-V foreign
+instruction encoding).  Exactly how this would work (vis-a-vis Compliance)
+needs discussion, as it would be unfortunate and undesirable for a hybrid
+processor capable of executing more than one hardware-level ISA support
+to not be permitted to receive RISC-V Certification Compliance.
+
+## Implementation
+
+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.
+
+However, 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
@@ -69,29 +78,59 @@ Also pointed out was that in certain cases pipeline stalls could be introduced
 during the switching phase, if needed, just as they may be needed for
 correct implementation of (mandatory) support for MISA.
 
-Update 29apr2018:
-
-* In cases where mvendorid and marchid are WARL, the mvendorid-marchid becomes
-  part of the execution context that must be saved (and switched as necessary)
-  just like any other state / CSR.
-* When any trap exception is raised the context / state *must not* be altered
-  (so that it can be properly saved, if needed, by the exception handler)
-  and that includes the current mvendorid-marchid tuple.  This leads to some
-  interesting situations where a hart could conceivably be directed
-  to a set of trap handler binary instructions that the current
-  mvendorid-marchid setting is incapable of correctly interpreting.
-  To fix this it will be necessary for implementations (hardware /
-  software) to set up separate per-mvendorid-marchid trap handlers and
-  for the hardware (or software) to switch to the appropriate trap "set"
-  when the mvendorid-marchid is written to.  The switch to a different
-  "set" will almost undoubtedly require (transparent) hardware assistance.
-* It's been noted that there may be certain legitimate cases where an
-  mvendorid-marchid should *specifically* not be tested for RISC-V
-  Certification Compliance: native support for foreign architectures
-  (not related to the JIT Extension: *actual* full entire non-RISC-V
-  foreign instruction encoding).  Exactly how this would work (vis-a-vis
-  Compliance) needs discussion, as it would be unfortunate and
-  undesirable for a hybrid processor capable of executing more than one
-  hardware-level ISA support to not be permitted to receive RISC-V
-  Certification Compliance.
+## Exception Handling (traps) and context-switching
+
+In cases where mvendorid and marchid are WARL, the mvendorid-marchid
+becomes part of the execution context that must be saved (and switched
+as necessary) just like any other state / CSR.
+
+When any trap exception is raised the context / state *must not* be
+altered (so that it can be properly saved, if needed, by the exception
+handler) and that includes the current mvendorid-marchid tuple.  This
+leads to some interesting situations where a hart could conceivably be
+directed to a set of trap handler binary instructions that the current
+mvendorid-marchid setting is incapable of correctly interpreting.
+
+To fix this it will be necessary for implementations (hardware /
+software) to set up separate per-mvendorid-marchid trap handlers and
+for the hardware (or software) to switch to the appropriate trap "set"
+when the mvendorid-marchid is written to.  The switch to a different
+"set" will almost undoubtedly require (transparent) **hardware** assistance.
+
+The reason for requiring hardware-assist for switching exception
+handling tables is because it has to be done atomically: there cannot
+be a situation where just as a hart is switching to a different
+mvendorid-marchid tuple an exception occurs, resulting in execution of
+effectively foreign instructions.
+
+In essence this means that mtvec needs to be a multi-entry table, one
+per (mvendorid-marchid) tuple.  Likewise stvec, and bstvec.
+
+## Backwards-compatibility
+
+Backwards compatibility is vital for Standards.  There are two aspects
+to this:
+
+* The actual change to the Standard should be minimally-disruptive
+* There should be no interference between two different encodings
+  (any two separate tuples).
+
+Given that mvendorid and marchid are presently read-only; given that
+the change is to the *wording* and does not add any new CSRs; the change
+can clearly be seen to be zero-impact, with the exception being to
+implementors that have Custom Extensions in silicon at the moment.
+
+On the second point: the *entire purpose* of the change is to provide
+globally world-wide irrevocable permanent distinction and separation
+between instruction encodings!
+
+## Forwards-compatibility
+
+Forwards compatibility is again vital for Standards.  Standards are required
+to adapt, yet at the same time provide a means and method of identifying
+and separating older (and legacy) systems from present and future versions.
+
+The clear separation which mutually-exclusively redirects encodings based
+on which mvendorid-marchid tuple is currently active clearly meets that
+requirement.