(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]]
+
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:
-
-* Existing designs - even though the specification is not finalised
- (but has "frozen" aspects) - would be completely unaffected: the
- change is to the "wording" of the specification to "retrospectively"
- fit reality.
-* Unlike with the MISA idea this is *purely* at the "decode" phase:
- no internal Extension state information is permitted to be disabled,
- altered or destroyed as a direct result of writing to the
- mvendor/march-id CSRs.
-* Compliance Testing may be carried out with a different vendorid/marchid
- tuple set prior to a test, allowing a vendor to claim *Certified*
- compatibility with *both* one (or more) legacy variants of the RISC-V
- Specification *and* with a present one.
-* With sufficient care taken in the implementation an implementor
- may have multiple interpretations of the same binary encoding within
- 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, 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.
+CSRs have WARL (writeable) characteristics. Read-only is taken to
+mean a declaration of "Having no Custom Extensions" (a zero-impact
+change).
-**This is the only one of the proposals that meet the full requirements**
+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.
-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.
+**This is the only one of the proposals that meet the full requirements**
# ioctl-like <a name="ioctl-like"></a>
--- /dev/null
+# 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 is make the mvendorid and marchid CSRs have WARL (writeable)
+characteristics. Each unique tuple identifies (including on a per-hart
+basis within the same processor) and switches over to a completely
+separate and distinct binary-encoding support such that:
+
+* Different versions (legacy and new) of the RISC-V Standard may be
+ supported within the same processor
+* The fight over the extremely limited custom opcode space ends
+* Entirely foreign ISA may be supported within the same processor
+ (not the same as JIT Extension).
+
+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:
+
+* Existing designs - even though the specification is not finalised
+ (but has "frozen" aspects) - would be completely unaffected: the
+ change is to the "wording" of the specification to "retrospectively"
+ fit reality.
+* Unlike with the MISA idea this is *purely* at the "decode" phase:
+ no internal Extension state information is permitted to be disabled,
+ altered or destroyed as a direct result of writing to the
+ mvendor/march-id CSRs.
+* Compliance Testing may be carried out with a different vendorid/marchid
+ tuple set prior to a test, allowing a vendor to claim *Certified*
+ compatibility with *both* one (or more) legacy variants of the RISC-V
+ Specification *and* with a present one.
+* With sufficient care taken in the implementation an implementor
+ may have multiple interpretations of the same binary encoding within
+ 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, 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.
+
+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.
+
projects / libreriscv.git / commitdiff