-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.