# 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
# 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
* MISA was only designed to cover Standard Extensions.
* There is nothing to prevent multiple Extensions being enabled
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>
-TBD paraphrase and clarify
+(Summary: the only idea that meets the full requirements. Needs
+ toolchain backup, but only when the first chip is released)
-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.
+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. 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 (and that
+it conforms precisely to one and only one specific variant of the
+RISC-V Specification).
This incredibly simple non-invasive idea has some unique and distinct
advantages over other proposals:
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.
-
-> that particular lead that:
->
-> * MISA Extension disabling is permitted (optionally) to DESTROY the state
-> information (which means that it *has* to be re-initialised just to be
-> safe... mistake in the standard, there), and * MISA was only designed
-> to cover Standard Extensions.
->
-> So the practice of switching extensions in and out - and the resultant
-> "disablement" and "enablement" at the *instruction decode phase* is
-> *already* a hard requirement as part of conforming with the present
-> RISC-V Specification.
->
-> Around the same MISA discussion, someone else also kindly pointed out
-> that one solution to the heavyweight nature of the switching would
-> be to deliberately introduce a pipeline stall whilst the switching is
-> occurring: I can see the sense in that approach, even if I don't know the
-> full details of what each implementor might choose to do. They may even
-> choose two, or three, or N pipeline stalls: it really doesn't matter,
-> as it's an implementors' choice (and problem to solve).
->
-> So yes it's pretty heavy-duty... and also already required.
->
-> For the case where "legacy" variants of the RISC-V Standard are
-> backwards-forwards-compatibly supported over a 10-20 year period
-> in Industrial and Military/Goverment-procurement scenarios (so that
-> the impossible-to-achieve pressure is off to get the spec ABSOLUTELY
-> correct, RIGHT now), nobody would expect a seriously heavy-duty amount
-> of instruction-by-instruction switching: it'd be used pretty much once
-> and only once at boot-up (or once in a Hypervisor Virtual Machine client)
-> and that's it.
->
-> I can however foresee instances where implementors would actually
-> genuinely want a bank of operations to be carried out using one extension,
-> followed immediately by another bank from a (conflicting binary-encoding)
-> extension, in an inner loop: Software-defined MPEG / MP4 decode to call
-> DCT block decode Custom Extension followed immediately by Custom Video
-> Processing Extension followed immediately by Custom DSP Processing
-> Extension to do YUV-to-RGB conversion for example is something that
-> is clearly desirable. Solving that one would be entiiirely their
-> problem... and the RISC-V Specification really really should give them
-> the space to do that in a clear-cut unambiguous way.
-
-# ioctl-like
-
-TBD - [[ioctl]] for full details, summary kept here
-
-# Discussion and analysis
-
-TBD
-
-# Conclusion
-
-TBD
+*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
+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 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
+correct implementation of (mandatory) support for MISA.
+
+**This is the only one of the proposals that meet the full requirements**
+
+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)
+function (instruction) that switches (redirects) the 8 functions over to
+different opcodes.
+
+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.
+
+==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.
+
+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
+invasive than the mvendor/march-id WARL concept.
+
+# Comments, Discussion and analysis
+
+TBD: placeholder as of 26apr2018
+
+# 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. 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
+the right coverage (Standard Extensions only), and also crucially it
+destroyed state. Whilst unworkable it did lead to the first "workable"
+solution, "MISA-like".
+
+The "MISA-like" proposal, whilst meeting most of the requirements, led to
+a better idea: "mvendor/march-id WARL", which, in combination with an offshoot
+idea related to gcc and binutils, is the only proposal that fully meets the
+requirements.
+
+The "ioctl-like" idea *also* solves the problem, but, unlike the WARL idea
+does not meet the full requirements to be "non-invasive" and "backwards
+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 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 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, 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 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 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)
+* The implementation details are clear (and problem-free except for
+ vendors who insist on deploying dozens of conflicting Custom Extensions:
+ 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,
+ 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,
> and typically the choice was "neither". Nobody wants to put in the
> effort when there is uncertainty and a market fragmented into
> small bits.
+>
> Note how Intel did not screw up. When SSE was added, MMX remained.
> Software vendors could trust that instructions would be supported.
> 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.
+# 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>
projects / libreriscv.git / blobdiff