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..f19179818f9a753ca497ad07c97884253a1e66ee 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
@@ -20,12 +20,27 @@ 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:
 
+* State information.  How is state to be handled?
 * 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?
 
+## State information
+
+Unlike with MISA (which can be used to completely switch off - i.e. power
+down) certain Extensions, state information is **not permitted to be
+altered or 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 (for example) standard OS context-switching *all*
+state of *all* extensions (and variants of the Base Standards) related
+to *all* mvendorid-marchid tuples will need to be 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 +58,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)
@@ -51,6 +66,11 @@ 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.
 
+How such foreign architectures would switch back to RISC-V when the foreign
+architecture does not support the concept of mvendorid-marchid is out of
+scope and left to implementors to define and implement equivalent
+functionality.
+
 ## Implementation
 
 The redirection of meaning of certain binary encodings to multiple
@@ -134,3 +154,8 @@ The clear separation which mutually-exclusively redirects encodings based
 on which mvendorid-marchid tuple is currently active clearly meets that
 requirement.
 
+# Questions to be resolved
+
+* Can the declaration (meaning) of read-only be expanded to cover
+  any number of (non-conflicting) Custom Extensions?  What are the
+  implications of doing so?