# Resolving ISA conflicts and providing a pain-free RISC-V Standards Upgrade Path
+## 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
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)
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
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
**This is the only one of the proposals that meet the full requirements**
-# ioctl-like
+Update 29apr2018:
+
+* In cases where mvendorid and marchid are WARL, the mvendorid-marchid becomes
+ part of the execution context that must be saved (and switched as necessary)
+ just like any other state / CSR.
+* When any trap exception is raised the context / state *must not* be altered
+ (so that it can be properly saved, if needed, by the exception handler)
+ and that includes the current mvendorid-marchid tuple. This leads to some
+ interesting situations where a hart could conceivably be directed
+ to a set of trap handler binary instructions that the current
+ mvendorid-marchid setting is incapable of correctly interpreting.
+ To fix this it will be necessary for implementations (hardware /
+ software) to set up separate per-mvendorid-marchid trap handlers and
+ for the hardware (or software) to switch to the appropriate trap "set"
+ when the mvendorid-marchid is written to. The switch to a different
+ "set" will almost undoubtedly require (transparent) hardware assistance.
+* It's been noted that there may be certain legitimate cases where an
+ mvendorid-marchid should *specifically* not be tested for RISC-V
+ Certification Compliance: native support for foreign architectures
+ (not related to the JIT Extension: *actual* full entire non-RISC-V
+ foreign instruction encoding). Exactly how this would work (vis-a-vis
+ Compliance) needs discussion, as it would be unfortunate and
+ undesirable for a hybrid processor capable of executing more than one
+ hardware-level ISA support to not be permitted to receive RISC-V
+ Certification Compliance.
+
+# ioctl-like <a name="ioctl-like"></a>
(Summary: good solid orthogonal idea. See [[ioctl]] 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)
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.
+existing ISA opcode space *or* is used as the basis of an independent
+Custom Extension in its own right.
+
+==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
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
* <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>
-
projects / libreriscv.git / blobdiff