add isa conflict resolution page

diff --git a/isa_conflict_resolution.mdwn b/isa_conflict_resolution.mdwn
index 10b141b437e182d0d318940dde9d97c542cbffdd..b8291c32cd88f369d9b11ec43ae7ef35e30c389a 100644 (file)
--- a/isa_conflict_resolution.mdwn
+++ b/isa_conflict_resolution.mdwn
@@ -85,6 +85,11 @@ TBD
 
 TBD
 
+> * 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-like
 
 TBD
@@ -93,6 +98,51 @@ TBD
 
 TBD
 
+>  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
+> 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.
+> 
+> So the practice of switching extensions in and out - and the resultant
+> "disablement" and "enablement" at the *instruction decode phase* is
+> *already* a hard requirement as part of conforming with the present
+> RISC-V Specification.
+> 
+> Around the same MISA discussion, someone else also kindly pointed out
+> that one solution to the heavyweight nature of the switching would
+> be to deliberately introduce a pipeline stall whilst the switching is
+> occurring: I can see the sense in that approach, even if I don't know the
+> full details of what each implementor might choose to do.  They may even
+> choose two, or three, or N pipeline stalls: it really doesn't matter,
+> as it's an implementors' choice (and problem to solve).
+> 
+> So yes it's pretty heavy-duty... and also already required.
+> 
+> For the case where "legacy" variants of the RISC-V Standard are
+> backwards-forwards-compatibly supported over a 10-20 year period
+> in Industrial and Military/Goverment-procurement scenarios (so that
+> the impossible-to-achieve pressure is off to get the spec ABSOLUTELY
+> correct, RIGHT now), nobody would expect a seriously heavy-duty amount
+> of instruction-by-instruction switching: it'd be used pretty much once
+> and only once at boot-up (or once in a Hypervisor Virtual Machine client)
+> and that's it.
+> 
+> I can however foresee instances where implementors would actually
+> genuinely want a bank of operations to be carried out using one extension,
+> followed immediately by another bank from a (conflicting binary-encoding)
+> extension, in an inner loop: Software-defined MPEG / MP4 decode to call
+> DCT block decode Custom Extension followed immediately by Custom Video
+> Processing Extension followed immediately by Custom DSP Processing
+> Extension to do YUV-to-RGB conversion for example is something that
+> is clearly desirable.  Solving that one would be entiiirely their
+> problem... and the RISC-V Specification really really should give them
+> the space to do that in a clear-cut unambiguous way.
+
 # ioctl-like
 
 TBD