# 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.**
+
## Executive Summary
A non-invasive backwards-compatible change to make mvendorid and marchid
**This is the only one of the proposals that meet the full requirements**
-# ioctl-like <a name="ioctl-like"></a>
+# Overloadable opcodes <a name="overloadable opcodes"></a>
-(Summary: good solid orthogonal idea. See [[ioctl]] for full details)
+See [[ioctl]] for [[pluggable extensions]] [[overloadable opcodes]] for full details)
NOTE: under discussion.
-This proposal basically mirrors the concept of POSIX ioctls, providing
-(arbitrarily) 8 functions (opcodes) whose meaning may be over-ridden
-in an object-orientated fashion by calling an "open handle" (and close)
-function (instruction) that switches (redirects) the 8 functions over to
-different opcodes.
+==RB 2018-5-1 updated to reflect much simplified xext proposal==
-The proposal is functionally near-identical to that of the mvendor/march-id
-except extended down to individual opcodes. As such it could hypothetically
-be proposed as an independent Standard Extension in its own right that extends
-the Custom Opcode space *or* fits into the brownfield spaces within the
-existing ISA opcode space *or* is used as the basis of an independent
-Custom Extension in its own right.
+The xext proposal defines 8 standardised R-type xcmd0, xcmd1, ...xcmd7 instructions (preferably in the brownfield opcode space)
+that are routed to (sub)devices that implement one or more interfaces with up to 8 (slightly crippled) R type instruction like commands.
+Each xext interface is identified by a 20 bit UUID (or 52 bit on RV64). Effectively the 8 standard xcmd instructions are designated as overloadable opcodes.
+The 20 bit provided by the UUID, so there is much more room than in the 2 custom 32 bit or even 4 custom 64/48 bit opcode spaces. Thus it avoids most of the need to put a claim on opcode space thereby risking collisions when combining independent extensions. In this respect it is much like POSIX ioctls, which obviate the need for defining new syscalls to control new and nonstandard hardware..
-==RB==
-I really think it should be in browncode
-==RB==
-One of the reasons for seeking an extension of the Custom opcode space is
-that the Custom opcode space is severely limited: only 2 opcodes are free
-within the 32-bit space, and only four total remain in the 48 and 64-bit
-space.
+==RB not sure about this bit==
+The proposal is functionally similar to that of the mvendor/march-id
+==RB==
+except the non standard extension is explicit and restricted to a small set of well defined individual opcodes.
+Hence several extensions can be mixed and there is no state to be tracked over context switches.
+As such it could hypothetically be proposed as an independent Standard Extension.
Despite the proposal (which is still undergoing clarification)
being worthwhile in its own right, and standing on its own merits and
-thus definitely worthwhile pursuing, it is non-trivial and much more
+thus definitely worthwhile pursuing, it is non-trivial and more
invasive than the mvendor/march-id WARL concept.
# Comments, Discussion and analysis
TBD: placeholder as of 26apr2018
+## new (old) m-a-i tuple idea
+
+> actually that's a good point: where the user decides that they want
+> to boot one and only one tuple (for the entire OS), forcing a HARDWARE
+> level default m-a-i tuple at them actually prevents and prohibits them
+> from doing that, Jacob.
+>
+> so we have apps on one RV-Base ISA and apps on an INCOMPATIBLE (future)
+> variant of RV-Base ISA. with the approach that i was advocating (S-mode
+> does NOT switch automatically), there are totally separate mtvec /
+> stvec / bstvec traps.
+>
+> would it be reasonable to assume the following:
+>
+> (a) RV-Base ISA, particularly code-execution in the critical S-mode
+> trap-handling, is *EXTREMELY* unlikely to ever be changed, even thinking
+> 30 years into the future ?
+>
+> (b) if the current M-mode (user app level) context is "RV Base ISA 1"
+> then i would hazard a guess that S-mode is prettty much going to drop
+> down into *exactly* the same mode / context, the majority of the time
+>
+> thus the hypothesis is that not only is it the common code-path to *not*
+> switch the ISA in the S-mode trap but that the instructions used are
+> extremely unlikely to be changed between "RV Base Revisions".
+>
+> foreign isa hardware-level execution
+> ------------------------
+>
+> this is the one i've not really thought through so much, other than it
+> would clearly be disadvantageous for S-mode to be arbitrarily restricted
+> to running RV-Base code (of any variant). a case could be made that by the
+> time the m-a-i tuple is switched to the foreign isa it's "all bets off",
+> foreign arch is "on its own", including having to devise a means and
+> method to switch back (equivalent in its ISA of m-a-i switching).
+>
+> conclusion / idea
+> --------------------
+>
+> the multi-base "user wants to run one and only one tuple" is the key
+> case, here, that is a show-stopper to the idea of hard-wiring the default
+> S-mode m-a-i.
+>
+> now, if instead we were to say, "ok so there should be a default S-mode
+> m-a-i tuple" and it was permitted to SET (choose) that tuple, *that*
+> would solve that problem. it could even be set to the foreign isa.
+> which would be hilarious.
+
+
# Summary and Conclusion
In the early sections (those in the category "no action") it was established
> it is implementing. It will test nothing in the custom extension space,
> and doesn't monitor or care what is in that space.
+## (4) Jacob Bachmeyer on explaining disambiguation of opcode space
+
+> ...have different harts with different sets of encodings.) Adding a "select"
+> CSR as has been proposed does not escape this fundamental truth that
+> instruction decode must be unambiguous, it merely expands every opcode with
+> extra bits from a "select" CSR.
+
# References
* <https://groups.google.com/a/groups.riscv.org/forum/#!topic/isa-dev/7bbwSIW5aqM>
* <https://groups.google.com/a/groups.riscv.org/forum/#!topic/isa-dev/InzQ1wr_3Ak%5B1-25%5D>
+* Review mvendorid-marchid WARL <https://groups.google.com/a/groups.riscv.org/forum/#!topic/isa-dev/Uvy9paXN1xA>
projects / libreriscv.git / blobdiff