# mvendorid/marchid WARL (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.