# 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>.
+Now updated with its own spec [[isamux_isans]].
-## Executive Summary
+[[!toc ]]
+
+## Executive Summary (old, still relevant for compilers)
A non-invasive backwards-compatible change to make mvendorid and marchid
being read-only to be a formal declaration of an architecture having no
==RB 2018-5-1 dropped IOCTL proposal for the much simpler overloadable opcodes proposal==
+The overloadable opcode (or xext) proposal allows a non standard extension to use a documented 20 + 3 bit (or 52 + 3 bit on RV64) UUID identifier for an instruction for _software_ to use. At runtime, a cpu translates the UUID to a small implementation defined 12 + 3 bit bit identifier for _hardware_ to use. It also defines a fallback mechanism for the UUID's of instructions the cpu does not recognise.
+
The overloadable opcodes proposal defines 8 standardised R-type instructions xcmd0, xcmd1, ...xcmd7 preferably in the brownfield opcode space.
Each xcmd takes in rs1 a 12 bit "logical unit" (lun) identifying a device on the cpu that implements some "extension interface" (xintf) together with some additional data. An xintf is a set of up to 8 commands with 2 input and 1 output port (i.e. like an R-type instruction), together with a description of the semantics of the commands. Calling e.g. xcmd3 routes its two inputs and one output ports to command 3 on the device determined by the lun bits in rs1. Thus, the 8 standard xcmd instructions are standard-designated overloadable opcodes, with the non standard semantics of the opcode determined by the lun.
==RB==
+# Dynamic runtime hardware-adjustable custom opcode encodings <a name="dynamic_opcodes"></a>
+
+Perhaps this is a misunderstanding, that what is being advocated
+below (see link for full context):
+
+> The best that can be done is to allow each custom extension to have
+> its opcodes easily re positioned depending on what other custom extensions
+> the user wants available in the same program (without mode switches).
+
+It was suggested to use markers in the object files as a way to
+identify opcodes that can be "re-encoded". Contrast this with Jacob
+Bachmeyer's original idea where the *assembly code* (only) contains
+such markers (on a global world-wide unique basis, using mvendorid-marchid-isamux
+tuples to do so).
+
+<https://groups.google.com/a/groups.riscv.org/d/msg/isa-dev/Jnon96tVQD0/XuHWvduvDQAJ>
+
+There are two possible interpretations of this:
+
+* (1) the Hardware RTL is reconfigureable (parameterisable) to allow
+ easy selection of *static* moving (adjustment) of which opcodes a
+ particular instruction uses. This runs into the same difficulties
+ as outlined in other areas of this document.
+* (2) the Hardware RTL contains DYNAMIC and RUN-TIME CONFIGUREABLE
+ opcodes (presumably using additional CSRs to move meanings)
+
+This would help any implementation to adjust to whatever future (official)
+uses a particular encoding was selected. It would be particularly useful
+if an implementation used certain brownfield encodings.
+
+The only downsides are:
+
+* (1) Compiler support for dynamic opcode reconfiguration would be...
+ complex.
+* (2) The instruction decode phase is also made more complex, now
+ involving reconfigureable lookup tables. Whilst major opcodes
+ can be easily redirected, brownfield encodings are more involved.
+
+Compared to a stark choice of having to move (exclusively) to 48-bit
+or 64-bit encodings, dynamic runtime opcode reconfiguration is
+comparatively much more palatable.
+
+In effect, it is a much more advanced version of ISAMUX/NS
+(see [[isamux_isans]]).
+
# Comments, Discussion and analysis
TBD: placeholder as of 26apr2018
> instruction decode must be unambiguous, it merely expands every opcode with
> extra bits from a "select" CSR.
+## (5) Krste Asanovic on clarification of use of opcode space
+
+> A CPU is even free to reuse some standard extension encoding space for
+> 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>
projects / libreriscv.git / blobdiff