add link to recent isamux discussino

[libreriscv.git] / isa_conflict_resolution.mdwn

diff --git a/isa_conflict_resolution.mdwn b/isa_conflict_resolution.mdwn
index b0a14fcde5f96ffda158311f6f03de728af9f622..93c3081efb993ad8ca21f5b037d8bac2088b72f4 100644 (file)
--- a/isa_conflict_resolution.mdwn
+++ b/isa_conflict_resolution.mdwn
@@ -1,7 +1,8 @@
 # Resolving ISA conflicts and providing a pain-free RISC-V Standards Upgrade Path
 
 **Note: out-of-date as of review 31apr2018, requires updating to reflect
-"mvendorid-marchid-isamux" concept.**
+"mvendorid-marchid-isamux" concept.**  Recent discussion 10jun2019
+<https://groups.google.com/a/groups.riscv.org/d/msg/isa-dev/x-uFZDXiOxY/_ISBs1enCgAJ>
 
 ## Executive Summary
 
@@ -564,6 +565,21 @@ The following conversation exerpts are taken from the ISA-dev discussion
 > non-standard extensions provided it does not claim to implement that
 > standard extension.
 
+## (6) Clarification of difference between assembler and encodings
+
+> > The extensible assembler database I proposed assumes that each processor
+> > will have *one* and *only* one set of recognized instructions.  (The "hidden
+> > prefix" is the immutable vendor/arch/impl tuple in my proposals.) 
+>
+>  ah this is an extremely important thing to clarify, the difference
+> between the recognised instruction assembly mnemonic (which must be
+> globally world-wide accepted as canonical) and the binary-level encodings
+> of that mnemonic used different vendor implementations which will most
+> definitely *not* be unique but require "registration" in the form of
+> atomic acceptance as a patch by the FSF to gcc and binutils [and other
+> compiler tools].
+
+
 # References
 
 * <https://groups.google.com/a/groups.riscv.org/forum/#!topic/isa-dev/7bbwSIW5aqM>