From: Luke Kenneth Casson Leighton Date: Mon, 30 Apr 2018 06:20:28 +0000 (+0100) Subject: split out mvendor-march-warl to separate page X-Git-Tag: convert-csv-opcode-to-binary~5425 X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=da81bd87af1b54d057a813509c07f108f04bf7c2;p=libreriscv.git split out mvendor-march-warl to separate page --- diff --git a/isa_conflict_resolution.mdwn b/isa_conflict_resolution.mdwn index 5538a7add..17a92df9c 100644 --- a/isa_conflict_resolution.mdwn +++ b/isa_conflict_resolution.mdwn @@ -272,93 +272,24 @@ separate page? review this para?**) (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 diff --git a/isa_conflict_resolution/mvendor_march_warl.mdwn b/isa_conflict_resolution/mvendor_march_warl.mdwn new file mode 100644 index 000000000..9f3ef78a3 --- /dev/null +++ b/isa_conflict_resolution/mvendor_march_warl.mdwn @@ -0,0 +1,97 @@ +# 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. +