clarify

[libreriscv.git] / isa_conflict_resolution / mvendor_march_warl.mdwn

diff --git a/isa_conflict_resolution/mvendor_march_warl.mdwn b/isa_conflict_resolution/mvendor_march_warl.mdwn
index 5bee2f71120da19c11f20a5431943084af74b612..156f72ff0e016a8b1f1eee79889e21d1bd6be8d7 100644 (file)
--- a/isa_conflict_resolution/mvendor_march_warl.mdwn
+++ b/isa_conflict_resolution/mvendor_march_warl.mdwn
@@ -9,7 +9,7 @@ to a completely separate and distinct binary-encoding such that:
   supported within the same processor
 * The fight over the extremely limited custom opcode space ends (permanently)
 * Entirely foreign ISA may be supported within the same processor
-  (not the same as JIT Extension).
+  (actually executed: i.e. not the same thing at all as the JIT Extension).
 
 For instances where mvendorid and marchid are readable, that would be
 taken to be a Standards-mandatory "declaration" that the architecture
@@ -26,6 +26,16 @@ main considerations are:
 * Backwards compatibility.  Is the change zero-impact (for existing systems)
 * Forwards compatibility.  Does the change affect (limit) future hardware?
 
+Note that unlike with MISA, state information is **not permitted to be
+destroyed** during or by a switch-over.  Switch-over to a different
+mvendorid-marchid tuple shall have the effect of *purely* disabling certain
+instruction encodings and enabling others.
+
+Note also that during context-switching *all* state of *all* custom
+extensions (and variants of the Base Standards) are saved onto the stack,
+given that a hart may, at any time, switch between any available
+mvendorid-marchid tuples.
+
 ## Compliance
 
 It was pointed out early in the discussions that Compliance Testing may
@@ -43,7 +53,7 @@ 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
+a 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)