clarify

diff --git a/isa_conflict_resolution.mdwn b/isa_conflict_resolution.mdwn
index eb91163f063f10f6154be5fa0c354efd8977c432..d96c5eeaf8870bfbfe098c731c1af61d30f12882 100644 (file)
--- a/isa_conflict_resolution.mdwn
+++ b/isa_conflict_resolution.mdwn
@@ -316,8 +316,8 @@ On this latter point, 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
-*redirects* encoding, to *different* engines, fortunately in a deliberately
-mutually-exclusive fashion.
+*redirects* encoding, effectively to *different* simultaneous engines,
+fortunately in a deliberately mutually-exclusive fashion.
 
 Implementations would therefore, in each Extension (assuming one separate
 "decode" engine per Extension), simply have an extra (mutually-exclusively
@@ -325,8 +325,8 @@ enabled) wire in the AND gate for any given binary encoding, and in this
 way there would actually be very little impact on the latency.  The assumption
 here is that there are not dozens of Extensions vying for the same binary
 encoding (at which point the Fabless Semi Company has other much more
-pressing issues to deal with that make resolving encoding conflicts trivial
-by comparison).
+pressing issues to deal with that make resolving binary encoding conflicts
+trivial by comparison).
 
 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