X-Git-Url: https://git.libre-soc.org/?a=blobdiff_plain;f=isa_conflict_resolution.mdwn;h=3223e2d262eed9ea1af04c5f0dfcd4c64fb8442c;hb=ffc571413d31e5157b1924aac9114c72fae9ad97;hp=b2b3b212458f5b661e286270f5aeaef5619b628a;hpb=4caf4f013467080ac1b168f65203cec75bd81bee;p=libreriscv.git diff --git a/isa_conflict_resolution.mdwn b/isa_conflict_resolution.mdwn index b2b3b2124..3223e2d26 100644 --- a/isa_conflict_resolution.mdwn +++ b/isa_conflict_resolution.mdwn @@ -1,5 +1,37 @@ # Resolving ISA conflicts and providing a pain-free RISC-V Standards Upgrade Path +## Executive Summary + +A non-invasive backwards-compatible change to make mvendorid and marchid +being read-only to be a formal declaration of an architecture having no +Custom Extensions, and being permitted to be WARL in order to support +multiple simultaneous architectures on the same processor (or per hart +or harts) permits not only backwards and forwards compatibility with +existing implementations of the RISC-V Standard, not only permits seamless +transitions to future versions of the RISC-V Standard (something that is +not possible at the moment), but fixes the problem of clashes in Custom +Extension opcodes on a global worldwide permanent and ongoing basis. + +Summary of impact and benefits: + +* Implementation impact for existing implementations (even though + the Standard is not finalised) is zero. +* Impact for future implementations compliant with (only one) version of the + RISC-V Standard is zero. +* Benefits for implementations complying with (one or more) versions + of the RISC-V Standard is: increased customer acceptance due to + a smooth upgrade path at the customer's pace and initiative vis-a-vis + legacy proprietary software. +* Benefits for implementations deploying multiple Custom Extensions + are a massive reduction in NREs and the hugely reduced ongoing software + toolchain maintenance costs plus the benefit of having security updates + from upstream software sources due to + *globally unique identifying information* resulting in zero binary + encoding conflicts in the toolchains and resultant binaries + *even for Custom Extensions*. + +## Introduction + In a lengthy thread that ironically was full of conflict indicative of the future direction in which RISC-V will go if left unresolved, multiple Custom Extensions were noted to be permitted free rein to @@ -89,7 +121,7 @@ Each of these will be discussed below in their own sections. # Do nothing (no problem exists) -TBD (basically not an option). +(Summary: not an option) There were several solutions offered that fell into this category. A few of them are listed in the introduction; more are listed below, @@ -138,7 +170,7 @@ field. # Do nothing (out of scope) -TBD (basically, may not be RV Foundation's "scope", still results in +(Summary: may not be RV Foundation's "scope", still results in problem, so not an option) This was one of the first arguments presented: The RISC-V Foundation @@ -148,16 +180,26 @@ problem, therefore there isn't a problem". The logical errors in this argument were quickly enumerated: namely that the RISC-V Foundation is not in control of the uses to which RISC-V is put, such that public global conflicts in binary-encoding are a hundred -percent guaranteed to occur, and a hundred percent guaranteed to occur in +percent guaranteed to occur (*outside* of the control and remit of the +RISC-V Foundation), and a hundred percent guaranteed to occur in *commodity* hardware where Debian, Fedora, SUSE and other distros will be hardest hit by the resultant chaos, and that will just be the more "visible" aspect of the underlying problem. # Do nothing (Compliance too complex, therefore out of scope) -TBD (basically, may not be RV Foundation's "scope", still results in +(Summary: may not be RV Foundation's "scope", still results in problem, so not an option) +The summary here was that Compliance testing of Custom Extensions is +not just out-of-scope, but even if it was taken into account that +binary-encoding meanings could change, it would still be out-of-scope. + +However at the time that this argument was made, it had not yet been +appreciated fully the impact that revisions to the Standard would have, +when billions of dollars worth of (older, legacy) RISC-V hardware had +already been deployed. + Two interestingly diametrically-opposed equally valid arguments exist here: * Whilst Compliance testing of Custom Extensions is definitely legitimately @@ -173,7 +215,7 @@ solution be very, very simple. # MISA -TBD, basically MISA not suitable +(Summary: MISA not suitable, leads to better idea) MISA permits extensions to be disabled by masking out the relevant bit. Hypothetically it could be used to disable one extension, then enable @@ -188,75 +230,228 @@ another that happens to use the same binary encoding. * MISA was only designed to cover Standard Extensions. * There is nothing to prevent multiple Extensions being enabled that wish to simultaneously interpret the same binary encoding. - +* There is nothing in the MISA specification which permits + *future* versions (bug-fixes) of the RISC-V ISA to be "switched in". + Overall, whilst the MISA concept is a step in the right direction it's a hundred percent unsuitable for solving the problem. # MISA-like -TBD, basically same as mvend/march WARL except needs an extra CSR where -mv/ma doesn't. +(Summary: basically same as mvend/march WARL except needs an extra CSR where +mv/ma doesn't. Along right lines, doesn't meet full requirements) + +Out of the MISA discussion came a "MISA-like" proposal, which would +take into account the flaws pointed out by trying to use "MISA": + +* The MISA-like CSR's meaning would be identified by compilers using the + mvendor-id/march-id tuple as a compiler target +* Each custom-defined bit of the MISA-like CSR would (mutually-exclusively) + redirect binary encoding(s) to specific encodings +* No Extension would *actually* be disabled: its internal state would + be left on (permanently) so that switching of ISA decoding + could be done inside inner loops without adverse impact on + performance. + +Whilst it was the first "workable" solution it was also noted that the +scheme is invasive: it requires an entirely new CSR to be added +to the privileged spec (thus making existing implementations redundant). +This does not fulfil the "minimum impact" requirement. + +Also interesting around the same time an additional discussion was +raised that covered the *compiler* side of the same equation. This +revolved around using mvendorid-marchid tuples at the compiler level, +to be put into assembly output (by gcc), preserving the required +*globally* unique identifying information for binutils to successfully +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 -TBD paraphrase and clarify - -> In an earlier part of the thread someone kindly pointed out that MISA -> already switches out entire sets of instructions [which interacts at the -> "decode" phase]. However it was noted after a few days of investigating -> that particular lead that: -> -> * MISA Extension disabling is permitted (optionally) to DESTROY the state -> information (which means that it *has* to be re-initialised just to be -> safe... mistake in the standard, there), and * MISA was only designed -> to cover Standard Extensions. -> -> So the practice of switching extensions in and out - and the resultant -> "disablement" and "enablement" at the *instruction decode phase* is -> *already* a hard requirement as part of conforming with the present -> RISC-V Specification. -> -> Around the same MISA discussion, someone else also kindly pointed out -> that one solution to the heavyweight nature of the switching would -> be to deliberately introduce a pipeline stall whilst the switching is -> occurring: I can see the sense in that approach, even if I don't know the -> full details of what each implementor might choose to do. They may even -> choose two, or three, or N pipeline stalls: it really doesn't matter, -> as it's an implementors' choice (and problem to solve). -> -> So yes it's pretty heavy-duty... and also already required. -> -> For the case where "legacy" variants of the RISC-V Standard are -> backwards-forwards-compatibly supported over a 10-20 year period -> in Industrial and Military/Goverment-procurement scenarios (so that -> the impossible-to-achieve pressure is off to get the spec ABSOLUTELY -> correct, RIGHT now), nobody would expect a seriously heavy-duty amount -> of instruction-by-instruction switching: it'd be used pretty much once -> and only once at boot-up (or once in a Hypervisor Virtual Machine client) -> and that's it. -> -> I can however foresee instances where implementors would actually -> genuinely want a bank of operations to be carried out using one extension, -> followed immediately by another bank from a (conflicting binary-encoding) -> extension, in an inner loop: Software-defined MPEG / MP4 decode to call -> DCT block decode Custom Extension followed immediately by Custom Video -> Processing Extension followed immediately by Custom DSP Processing -> Extension to do YUV-to-RGB conversion for example is something that -> is clearly desirable. Solving that one would be entiiirely their -> problem... and the RISC-V Specification really really should give them -> the space to do that in a clear-cut unambiguous way. +(Summary: the only idea that meets the full requirements. Needs + toolchain backup, but only when the first chip is released) + +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. + +**This is the only one of the proposals that meet the full requirements** # ioctl-like -TBD - [[ioctl]] for full details, summary kept here - -# Discussion and analysis - -TBD - -# Conclusion - -TBD +(Summary: good solid orthogonal idea. See [[ioctl]] for full details) + +NOTE: under discussion. + +This proposal basically mirrors the concept of POSIX ioctls, providing +(arbitrarily) 8 functions (opcodes) whose meaning may be over-ridden +in an object-orientated fashion by calling an "open handle" (and close) +function (instruction) that switches (redirects) the 8 functions over to +different opcodes. + +The proposal is functionally near-identical to that of the mvendor/march-id +except extended down to individual opcodes. As such it could hypothetically +be proposed as an independent Standard Extension in its own right that extends +the Custom Opcode space *or* fits into the brownfield spaces within the +existing ISA opcode space *or* is used as the basis of an independent +Custom Extension in its own right. + +==RB== +I really think it should be in browncode +==RB== + +One of the reasons for seeking an extension of the Custom opcode space is +that the Custom opcode space is severely limited: only 2 opcodes are free +within the 32-bit space, and only four total remain in the 48 and 64-bit +space. + +Despite the proposal (which is still undergoing clarification) +being worthwhile in its own right, and standing on its own merits and +thus definitely worthwhile pursuing, it is non-trivial and much more +invasive than the mvendor/march-id WARL concept. + +# Comments, Discussion and analysis + +TBD: placeholder as of 26apr2018 + +# Summary and Conclusion + +In the early sections (those in the category "no action") it was established +in each case that the problem is not solved. Avoidance of responsibility, +or conflation of "not our problem" with "no problem" does not make "problem" +go away. Even "making it the Fabless Semiconductor's design problem" resulted +in a chip being *more costly to engineer as hardware **and** more costly +from a software-support perspective to maintain*... without actually +fixing the problem. + +The first idea considered which could fix the problem was to just use +the pre-existing MISA CSR, however this was determined not to have +the right coverage (Standard Extensions only), and also crucially it +destroyed state. Whilst unworkable it did lead to the first "workable" +solution, "MISA-like". + +The "MISA-like" proposal, whilst meeting most of the requirements, led to +a better idea: "mvendor/march-id WARL", which, in combination with an offshoot +idea related to gcc and binutils, is the only proposal that fully meets the +requirements. + +The "ioctl-like" idea *also* solves the problem, but, unlike the WARL idea +does not meet the full requirements to be "non-invasive" and "backwards +compatible" with pre-existing (pre-Standards-finalised) implementations. +It does however stand on its own merit as a way to extend the extremely +small Custom Extension opcode space, even if it itself implemented *as* +a Custom Extension into which *other* Custom Extensions are subsequently +shoe-horned. This approach has the advantage that it requires no "approval" +from the RISC-V Foundation... but without the RISC-V Standard "approval" +guaranteeing no binary-encoding conflicts, still does not actually solve the +problem (if deployed as a Custom Extension for extending Custom Extensions). + +Overall the mvendor/march-id WARL idea meets the three requirements, +and is the only idea that meets the three requirements: + +* **Any proposal must be a minimal change with minimal (or zero) impact** + (met through being purely a single backwards-compatible change to the + wording of the specification: mvendor/march-id changes from read-only + to WARL) +* **Any proposal should place no restriction on existing or future + ISA encoding space** + (met because it is just a change to one pre-existing CSR, as opposed + to requiring additional CSRs or requiring extra opcodes or changes + to existing opcodes) +* **Any proposal should take into account that there are existing implementors + of the (yet to be finalised but still "partly frozen") Standard who may + resist, for financial investment reasons, efforts to make any change + (at all) that could cost them immediate short-term profits.** + (met because existing implementations, with the exception of those + that have Custom Extensions, come under the "vendor/arch-id read only + is a formal declaration of an implementation having no Custom Extensions" + fall-back category) + +So to summarise: + +* The consequences of not tackling this are severe: the RISC-V Foundation + cannot take a back seat. If it does, clear historical precedent shows + 100% what the outcome will be (1). +* Making the mvendorid and marchid CSRs WARL solves the problem in a + minimal to zero-disruptive backwards-compatible fashion that provides + indefinite transparent *forwards*-compatibility. +* The retro-fitting cost onto existing implementations (even though the + specification has not been finalised) is zero to negligeable + (only changes to words in the specification required at this time: + no vendor need discard existing designs, either being designed, + taped out, or actually in production). +* The benefits are clear (pain-free transition path for vendors to safely + upgrade over time; no fights over Custom opcode space; no hassle for + software toolchain; no hassle for GNU/Linux Distros) +* The implementation details are clear (and problem-free except for + vendors who insist on deploying dozens of conflicting Custom Extensions: + an extreme unlikely outlier). +* Compliance Testing is straightforward and allows vendors to seek and + obtain *multiple* Compliance Certificates with past, present and future + variants of the RISC-V Standard (in the exact same processor, + simultaneously), in order to support end-customer legacy scenarios and + provide the same with a way to avoid "impossible-to-make" decisions that + throw out ultra-costly multi-decade-investment in proprietary legacy + software at the same as the (legacy) hardware. + +------- # Conversation Exerpts @@ -266,19 +461,20 @@ The following conversation exerpts are taken from the ISA-dev discussion > Yes. Well, it should be blocked via legal means. Incompatibility is > a disaster for an architecture. -> +> > The viability of PowerPC was badly damaged when SPE was > introduced. This was a vector instruction set that was incompatible > with the AltiVec instruction set. Software vendors had to choose, > and typically the choice was "neither". Nobody wants to put in the > effort when there is uncertainty and a market fragmented into > small bits. +> > Note how Intel did not screw up. When SSE was added, MMX remained. > Software vendors could trust that instructions would be supported. > Both MMX and SSE remain today, in all shipping processors. With very > few exceptions, Intel does not ship chips with missing functionality. > There is a unified software ecosystem. -> +> > This goes beyond the instruction set. MMU functionality also matters. > You can add stuff, but then it must be implemented in every future CPU. > You can not take stuff away without harming the architecture. @@ -303,3 +499,7 @@ 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. +# References + +* +*