# 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:
+This proposal is to make the mvendorid and marchid CSRs have WARL (writeable)
+characteristics as a means and method of providing RISC-V implementations
+with a way to support multiple binary instruction encodings simultaneously
+within the same processor. Each unique tuple (including on a per-hart
+basis) uniquely identifies and permits switch-over
+to a completely separate and distinct binary-encoding 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
+* The fight over the extremely limited custom opcode space ends (permanently)
* Entirely foreign ISA may be supported within the same processor
- (not the same as JIT Extension).
+ (actually executed: i.e. not the same thing at all as the 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
+Beyond that, the change is so simple and straightforward that there is not
+much to discuss aside from its feasibility and its implications. The
+main considerations are:
+
+* State information. How is state to be handled?
+* Compliance. What impact does the change have on Compliance (and testing)?
+* Implementation. Is it feasible and practical?
+* Exception-handlling. What happens during a trap?
+* Backwards compatibility. Is the change zero-impact (for existing systems)
+* Forwards compatibility. Does the change affect (limit) future hardware?
+
+## State information
+
+Unlike with MISA (which can be used to completely switch off - i.e. power
+down) certain Extensions, state information is **not permitted to be
+altered or destroyed** during or by a switch-over. Switch-over to a different
+mvendorid-marchid tuple shall have the effect of *purely* disabling certain
+instruction encodings and enabling others.
+
+Note also that during (for example) standard OS context-switching *all*
+state of *all* enabled extensions (and variants of the Base Standards) related
+to *all* mvendorid-marchid tuples will need to be saved onto the stack,
+given that a hart may, at any time, switch between any available
+mvendorid-marchid tuples.
+
+In other words there is absolutely zero connection *of any kind whatsoever*
+between the "encoding switching" and the state or status of the Extensions
+that the binary encodings are being directed *at* (on any upcoming
+conflicting instruction encodings). If a program requires the enablement
+or disablement of an Extension it **uses MISA and other official methods
+to do so** that have **absolutely nothing to do with what mvendorid-marchid
+is presently enabled**.
+
+## Compliance
+
+It was pointed out early in the discussions that Compliance Testing may
+**fail** any system that has mvendorid/marchid as WARL. This however is a
+clear case of "Compliance Tail Wagging Standard Dog". However it *was*
+recognised that overly complex Compliance Testing would result
+in rejection of the entire RISC-V Standard.
+
+A simple solution is to modify the Compliance Test Suite to specify the
+required mvendorid/marchid to be tested, as a parameter to the test
+applications. The test can be run multiple times, providing the
+implementor with multiple Compliance Certificates for the same processor,
+against *different variants* of past, present and future RISC-V Standards.
+
+*This is clearly a desirable characteristic*
+
+It's been noted that there may be certain legitimate cases where
+a 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.
+
+How such foreign architectures would switch back to RISC-V when the foreign
+architecture does not support the concept of mvendorid-marchid is out of
+scope and left to implementors to define and implement equivalent
+functionality.
+
+## Implementation
+
+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.
+
+However, 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
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.
+## Exception Handling (traps) and context-switching
+
+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.
+
+The reason for requiring hardware-assist for switching exception
+handling tables is because it has to be done atomically: there cannot
+be a situation where just as a hart is switching to a different
+mvendorid-marchid tuple an exception occurs, resulting in execution of
+effectively foreign instructions.
+
+In essence this means that mtvec needs to be a multi-entry table, one
+per (mvendorid-marchid) tuple. Likewise stvec, and bstvec.
+
+## Backwards-compatibility
+
+Backwards compatibility is vital for Standards. There are two aspects
+to this:
+
+* The actual change to the Standard should be minimally-disruptive
+* There should be no interference between two different encodings
+ (any two separate tuples).
+
+Given that mvendorid and marchid are presently read-only; given that
+the change is to the *wording* and does not add any new CSRs; the change
+can clearly be seen to be zero-impact, with the exception being to
+implementors that have Custom Extensions in silicon at the moment.
+
+On the second point: the *entire purpose* of the change is to provide
+globally world-wide irrevocable permanent distinction and separation
+between instruction encodings!
+
+## Forwards-compatibility
+
+Forwards compatibility is again vital for Standards. Standards are required
+to adapt, yet at the same time provide a means and method of identifying
+and separating older (and legacy) systems from present and future versions.
+
+The clear separation which mutually-exclusively redirects encodings based
+on which mvendorid-marchid tuple is currently active clearly meets that
+requirement.
+
+# How the "custom extension conflict" is solved
+
+* Vendor 1 produces a Custom Extension
+* Vendor 2 produces a Custom Extension
+* Both Custom Extensions have conflicting binary encodings.
+* Fabless Semi Company 1 licenses both Vendor 1 and 2 Custom Extensions
+* Fabless Semi Company 1 sets marchid=0xeee1 WARL to represent
+ enabling Vendor 1's conflicting encoding
+* Fabless Semi Company 1 sets marchid=0xeee2 WARL to represent
+ enabling Vendor 2's conflicting encoding
+* Fabless Semi Company 1 contacts the FSF, submitting patches to gcc
+ (and likewise with binutils) to register
+ (mvendorid=fabless1,marchid=0xeee1) to be added to the global
+ (FSF-curated?) database for Vendor 1's instruction encoding.
+* Likewise for Vendor 2's instruction encoding.
+
+Note that the RISC-V Foundation is **not** involved (or consulted) in
+this process. The **FSF** (as the Copyright holder of gcc and binutils)
+inherently and implicitly becomes the de-facto atomic arbiter in control
+of the registration of Custom Extension instruction encodings.
+
+The FSF's "job" is however quite straightforward: ensure that all
+registrations are in fact unique. It would be absolutely no good if a
+Vendor decided to re-use two mvendorid-marchid tuples to mean two
+totally different sets of instructions needed to be enabled! Any
+Vendor attempting to do so should be red-flagged immediately.
+
+Situations in which the FSF receives requests for patches with
+*another fabless semiconductor company's* mvendorid should also be treated
+with suspicion, at the very least being queried as to why one fabless semi
+company is trying to encroach on another company's JEDEC-registered
+encoding space.
+
+The special case of the above is when a fabless semiconductor company
+implements a new version of the RISC-V Standard. Here, again, the
+fabless semi company will provide patches to gcc and binutils, requesting
+that their specific mvendorid-marchid tuple be added to the (inherently
+de-facto atomic arbitrated) global database for that particular RISC-V
+Standard "Variant".
+
+# Questions to be resolved
+* Can the declaration (meaning) of read-only be expanded to cover
+ any number of (non-conflicting) Custom Extensions? What are the
+ implications of doing so?
projects / libreriscv.git / blobdiff