X-Git-Url: https://git.libre-soc.org/?a=blobdiff_plain;f=isa_conflict_resolution.mdwn;h=dd6c780288cecf7c6dc3019fa16751837e35730e;hb=fe27dc9873614e3c2f55e497404a9164246c7c0b;hp=3223e2d262eed9ea1af04c5f0dfcd4c64fb8442c;hpb=ffc571413d31e5157b1924aac9114c72fae9ad97;p=libreriscv.git diff --git a/isa_conflict_resolution.mdwn b/isa_conflict_resolution.mdwn index 3223e2d26..dd6c78028 100644 --- a/isa_conflict_resolution.mdwn +++ b/isa_conflict_resolution.mdwn @@ -267,20 +267,27 @@ turn the custom instruction into an actual binary-encoding (plus binary-encoding of the context-switching information). (**TBD, Jacob, separate page? review this para?**) -# mvendorid/marchid WARL +# 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 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). +CSRs have WARL (writeable) characteristics. Read-only is taken to +mean a declaration of "Having no Custom Extensions" (a zero-impact +change). + +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. This incredibly simple non-invasive idea has some unique and distinct advantages over other proposals: @@ -302,39 +309,9 @@ advantages over other proposals: 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. - **This is the only one of the proposals that meet the full requirements** -# ioctl-like +# ioctl-like (Summary: good solid orthogonal idea. See [[ioctl]] for full details) @@ -371,6 +348,55 @@ invasive than the mvendor/march-id WARL concept. TBD: placeholder as of 26apr2018 +## new (old) m-a-i tuple idea + +> actually that's a good point: where the user decides that they want +> to boot one and only one tuple (for the entire OS), forcing a HARDWARE +> level default m-a-i tuple at them actually prevents and prohibits them +> from doing that, Jacob. +> +> so we have apps on one RV-Base ISA and apps on an INCOMPATIBLE (future) +> variant of RV-Base ISA.  with the approach that i was advocating (S-mode +> does NOT switch automatically), there are totally separate mtvec / +> stvec / bstvec traps. +> +> would it be reasonable to assume the following: +> +> (a) RV-Base ISA, particularly code-execution in the critical S-mode +> trap-handling, is *EXTREMELY* unlikely to ever be changed, even thinking +> 30 years into the future ? +> +> (b) if the current M-mode (user app level) context is "RV Base ISA 1" +> then i would hazard a guess that S-mode is prettty much going to drop +> down into *exactly* the same mode / context, the majority of the time +> +> thus the hypothesis is that not only is it the common code-path to *not* +> switch the ISA in the S-mode trap but that the instructions used are +> extremely unlikely to be changed between "RV Base Revisions". +> +> foreign isa hardware-level execution +> ------------------------ +> +> this is the one i've not really thought through so much, other than it +> would clearly be disadvantageous for S-mode to be arbitrarily restricted +> to running RV-Base code (of any variant).  a case could be made that by the +> time the m-a-i tuple is switched to the foreign isa it's "all bets off", +> foreign arch is "on its own", including having to devise a means and +> method to switch back (equivalent in its ISA of m-a-i switching). +> +> conclusion / idea +> -------------------- +> +> the multi-base "user wants to run one and only one tuple" is the key +> case, here, that is a show-stopper to the idea of hard-wiring the default +> S-mode m-a-i. +> +> now, if instead we were to say, "ok so there should be a default S-mode +> m-a-i tuple" and it was permitted to SET (choose) that tuple, *that* +> would solve that problem.  it could even be set to the foreign isa.  +> which would be hilarious. + + # Summary and Conclusion In the early sections (those in the category "no action") it was established @@ -499,6 +525,13 @@ The following conversation exerpts are taken from the ISA-dev discussion > it is implementing. It will test nothing in the custom extension space, > and doesn't monitor or care what is in that space. +## (4) Jacob Bachmeyer on explaining disambiguation of opcode space + +> ...have different harts with different sets of encodings.)  Adding a "select" +> CSR as has been proposed does not escape this fundamental truth that +> instruction decode must be unambiguous, it merely expands every opcode with +> extra bits from a "select" CSR. + # References *