# 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
+being read-only to be a formal declaration of an architecture having no
+Custom Extensions, and being permitted to be WARL in order to support
+multiple simultaneous architectures on the same processor (or per hart
+or harts) permits not only backwards and forwards compatibility with
+existing implementations of the RISC-V Standard, not only permits seamless
+transitions to future versions of the RISC-V Standard (something that is
+not possible at the moment), but fixes the problem of clashes in Custom
+Extension opcodes on a global worldwide permanent and ongoing basis.
+
+Summary of impact and benefits:
+
+* Implementation impact for existing implementations (even though
+ the Standard is not finalised) is zero.
+* Impact for future implementations compliant with (only one) version of the
+ RISC-V Standard is zero.
+* Benefits for implementations complying with (one or more) versions
+ of the RISC-V Standard is: increased customer acceptance due to
+ a smooth upgrade path at the customer's pace and initiative vis-a-vis
+ legacy proprietary software.
+* Benefits for implementations deploying multiple Custom Extensions
+ are a massive reduction in NREs and the hugely reduced ongoing software
+ toolchain maintenance costs plus the benefit of having security updates
+ from upstream software sources due to
+ *globally unique identifying information* resulting in zero binary
+ encoding conflicts in the toolchains and resultant binaries
+ *even for Custom Extensions*.
+
+## Introduction
+
In a lengthy thread that ironically was full of conflict indicative
of the future direction in which RISC-V will go if left unresolved,
multiple Custom Extensions were noted to be permitted free rein to
# Do nothing (no problem exists)
-TBD (basically not an option).
+(Summary: not an option)
There were several solutions offered that fell into this category.
A few of them are listed in the introduction; more are listed below,
# Do nothing (out of scope)
-TBD (basically, may not be RV Foundation's "scope", still results in
+(Summary: may not be RV Foundation's "scope", still results in
problem, so not an option)
This was one of the first arguments presented: The RISC-V Foundation
The logical errors in this argument were quickly enumerated: namely that
the RISC-V Foundation is not in control of the uses to which RISC-V is
put, such that public global conflicts in binary-encoding are a hundred
-percent guaranteed to occur, and a hundred percent guaranteed to occur in
+percent guaranteed to occur (*outside* of the control and remit of the
+RISC-V Foundation), and a hundred percent guaranteed to occur in
*commodity* hardware where Debian, Fedora, SUSE and other distros will
be hardest hit by the resultant chaos, and that will just be the more
"visible" aspect of the underlying problem.
# Do nothing (Compliance too complex, therefore out of scope)
-TBD (basically, may not be RV Foundation's "scope", still results in
+(Summary: may not be RV Foundation's "scope", still results in
problem, so not an option)
The summary here was that Compliance testing of Custom Extensions is
# MISA
-TBD, basically MISA not suitable
+(Summary: MISA not suitable, leads to better idea)
MISA permits extensions to be disabled by masking out the relevant bit.
Hypothetically it could be used to disable one extension, then enable
that wish to simultaneously interpret the same binary encoding.
* There is nothing in the MISA specification which permits
*future* versions (bug-fixes) of the RISC-V ISA to be "switched in".
-
+
Overall, whilst the MISA concept is a step in the right direction it's
a hundred percent unsuitable for solving the problem.
# MISA-like
-TBD, basically same as mvend/march WARL except needs an extra CSR where
-mv/ma doesn't.
+(Summary: basically same as mvend/march WARL except needs an extra CSR where
+mv/ma doesn't. Along right lines, doesn't meet full requirements)
Out of the MISA discussion came a "MISA-like" proposal, which would
take into account the flaws pointed out by trying to use "MISA":
* Each custom-defined bit of the MISA-like CSR would (mutually-exclusively)
redirect binary encoding(s) to specific encodings
* No Extension would *actually* be disabled: its internal state would
- be left on (permanently) so that switching could be done inside
- inner loops.
+ be left on (permanently) so that switching of ISA decoding
+ could be done inside inner loops without adverse impact on
+ performance.
Whilst it was the first "workable" solution it was also noted that the
-scheme is quite invasive: it requires an entirely new CSR to be added
-to the privileged spec. This does not completely fulfil the "minimum
-impact" requirement.
+scheme is invasive: it requires an entirely new CSR to be added
+to the privileged spec (thus making existing implementations redundant).
+This does not fulfil the "minimum impact" requirement.
Also interesting around the same time an additional discussion was
raised that covered the *compiler* side of the same equation. This
binary-encoding of the context-switching information). (**TBD, Jacob,
separate page? review this para?**)
-# mvendorid/marchid WARL
+# mvendorid/marchid WARL <a name="mvendor_marchid_warl"></a>
+
+(Summary: the only idea that meets the full requirements. Needs
+ toolchain backup, but only when the first chip is released)
+
+This proposal has full details at the following page:
+[[mvendor_march_warl]]
-TBD paraphrase and clarify
+Coming out of the software-related proposal by Jacob Bachmeyer, which
+hinged on the idea of a globally-maintained gcc / binutils database
+that kept and coordinated architectural encodings (curated by the Free
+Software Foundation), was to quite simply make the mvendorid and marchid
+CSRs have WARL (writeable) characteristics. Read-only is taken to
+mean a declaration of "Having no Custom Extensions" (a zero-impact
+change).
-Coming out of the software-related proposal by Jacob, which hinged on
-the idea of a global gcc / binutils database that kept and coordinated
-architectural encodings, was to quite simply make the mvendorid and
-marchid CSRs have WARL (writeable) characteristics. For instances
-where mvendorid and marchid are readable, that would be taken to be
-a Standards-mandatory "declaration" that the architecture has *no*
-Custom Extensions.
+By making mvendorid-marchid tuples WARL the instruction decode phase
+may re-route mutually-exclusively to different engines, thus providing
+a controlled means and method of supporting multiple (future, past and
+present) versions of the **Base** ISA, Custom Extensions and even
+completely foreign ISAs in the same processor.
This incredibly simple non-invasive idea has some unique and distinct
advantages over other proposals:
an inner loop, with a single instruction (to the WARL register)
changing the meaning.
-A couple of points were made:
-
-* Compliance Testing may **fail** any system that has mvendorid/marchid
- as WARL. This however is a clear case of "Compliance Tail Wagging Standard
- Dog".
-* The redirection of meaning of certain binary encodings to multiple
- engines was considered extreme, eyebrow-raising, and also (importantly)
- potentially expensive, introducing significant latency at the decode
- phase.
-
-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.
-
-Implementations would therefore, in each Extension (assuming one separate
-"decode" engine per Extension), simply have an extra (mutually-exclusively
-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).
-
-Also pointed out was that in certain cases pipeline stalls could be introduced
-during the switching phase, if needed.
-
**This is the only one of the proposals that meet the full requirements**
-# ioctl-like
+# Overloadable opcodes <a name="overloadable opcodes"></a>
+
+See [[ioctl]] for [[pluggable extensions]] [[overloadable opcodes]] for full details)
+
+NOTE: under discussion.
-TBD - [[ioctl]] for full details, summary kept here
+==RB 2018-5-1 updated to reflect much simplified xext proposal==
-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.
+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..
-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.
-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.
-# Discussion and analysis
+# 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.
-TBD
-# Conclusion
+# Summary and Conclusion
In the early sections (those in the category "no action") it was established
in each case that the problem is not solved. Avoidance of responsibility,
or conflation of "not our problem" with "no problem" does not make "problem"
-go away.
+go away. Even "making it the Fabless Semiconductor's design problem" resulted
+in a chip being *more costly to engineer as hardware **and** more costly
+from a software-support perspective to maintain*... without actually
+fixing the problem.
The first idea considered which could fix the problem was to just use
the pre-existing MISA CSR, however this was determined not to have
compatible" with pre-existing (pre-Standards-finalised) implementations.
It does however stand on its own merit as a way to extend the extremely
small Custom Extension opcode space, even if it itself implemented *as*
-a Custom Extension.
+a Custom Extension into which *other* Custom Extensions are subsequently
+shoe-horned. This approach has the advantage that it requires no "approval"
+from the RISC-V Foundation... but without the RISC-V Standard "approval"
+guaranteeing no binary-encoding conflicts, still does not actually solve the
+problem (if deployed as a Custom Extension for extending Custom Extensions).
Overall the mvendor/march-id WARL idea meets the three requirements,
and is the only idea that meets the three requirements:
* **Any proposal must be a minimal change with minimal (or zero) impact**
- (met through being purely a single change to the specification:
- mvendor/march-id changes from read-only to WARL)
+ (met through being purely a single backwards-compatible change to the
+ wording of the specification: mvendor/march-id changes from read-only
+ to WARL)
* **Any proposal should place no restriction on existing or future
ISA encoding space**
- (met because it is just a change to one pre-existing CSR)
+ (met because it is just a change to one pre-existing CSR, as opposed
+ to requiring additional CSRs or requiring extra opcodes or changes
+ to existing opcodes)
* **Any proposal should take into account that there are existing implementors
of the (yet to be finalised but still "partly frozen") Standard who may
resist, for financial investment reasons, efforts to make any change
(at all) that could cost them immediate short-term profits.**
(met because existing implementations, with the exception of those
that have Custom Extensions, come under the "vendor/arch-id read only
- is a declaration of having no Custom Extensions" fall-back category)
+ is a formal declaration of an implementation having no Custom Extensions"
+ fall-back category)
So to summarise:
* The consequences of not tackling this are severe: the RISC-V Foundation
cannot take a back seat. If it does, clear historical precedent shows
100% what the outcome will be (1).
+* Making the mvendorid and marchid CSRs WARL solves the problem in a
+ minimal to zero-disruptive backwards-compatible fashion that provides
+ indefinite transparent *forwards*-compatibility.
* The retro-fitting cost onto existing implementations (even though the
- specification has not been finalised) is negligeable
- (changes to words in the specification)
+ specification has not been finalised) is zero to negligeable
+ (only changes to words in the specification required at this time:
+ no vendor need discard existing designs, either being designed,
+ taped out, or actually in production).
* The benefits are clear (pain-free transition path for vendors to safely
upgrade over time; no fights over Custom opcode space; no hassle for
software toolchain; no hassle for GNU/Linux Distros)
an extreme unlikely outlier).
* Compliance Testing is straightforward and allows vendors to seek and
obtain *multiple* Compliance Certificates with past, present and future
- variants of the RISC-V Standard (in the exact same processor), in order
- support legacy customers and provide same customers with a way to avoid
- "impossible-to-make" decisions that throw out ultra-expensive multi-decade
- proprietary legacy software at the same as the hardware.
+ variants of the RISC-V Standard (in the exact same processor,
+ simultaneously), in order to support end-customer legacy scenarios and
+ provide the same with a way to avoid "impossible-to-make" decisions that
+ throw out ultra-costly multi-decade-investment in proprietary legacy
+ software at the same as the (legacy) hardware.
+
+-------
# Conversation Exerpts
> Yes. Well, it should be blocked via legal means. Incompatibility is
> a disaster for an architecture.
->
+>
> The viability of PowerPC was badly damaged when SPE was
> introduced. This was a vector instruction set that was incompatible
> with the AltiVec instruction set. Software vendors had to choose,
> Both MMX and SSE remain today, in all shipping processors. With very
> few exceptions, Intel does not ship chips with missing functionality.
> There is a unified software ecosystem.
->
+>
> This goes beyond the instruction set. MMU functionality also matters.
> You can add stuff, but then it must be implemented in every future CPU.
> You can not take stuff away without harming the architecture.
> 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