X-Git-Url: https://git.libre-soc.org/?p=libreriscv.git;a=blobdiff_plain;f=isa_conflict_resolution.mdwn;h=8125aa392c63c24b80d0768376037d794ade3966;hp=2499cc87da82744ce23efd5280bfe30154c2e43f;hb=HEAD;hpb=e96db5608a3f24f89ddee0bd7d18df3ada420678 diff --git a/isa_conflict_resolution.mdwn b/isa_conflict_resolution.mdwn deleted file mode 100644 index 2499cc87d..000000000 --- a/isa_conflict_resolution.mdwn +++ /dev/null @@ -1,482 +0,0 @@ -# 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 -introduce global binary-encoding conflict with no means of resolution -described or endorsed by the RISC-V Standard: a practice that has known -disastrous and irreversible consequences for any architecture that -permits such practices (1). - -Much later on in the discussion it was realised that there is also no way -within the current RISC-V Specification to transition to improved versions -of the standard, regardless of whether the fixes are absolutely critical -show-stoppers or whether they are just keeping the standard up-to-date (2). - -With no transition path there is guaranteed to be tension and conflict -within the RISC-V Community over whether revisions should be made: -should existing legacy designs be prioritised, mutually-exclusively over -future designs (and what happens during the transition period is absolute -chaos, with the compiler toolchain, software ecosystem and ultimately -the end-users bearing the full brunt of the impact). If several -overlapping revisions are required that have not yet transitioned out -of use (which could take well over two decades to occur) the situation -becomes disastrous for the credibility of the entire RISC-V ecosystem. - -It was also pointed out that Compliance is an extremely important factor -to take into consideration, and that Custom Extensions (as being optional) -effectively and quite reasonably fall entirely outside of the scope of -Compliance Testing. At this point in the discussion however it was not -yet noted the stark problem that the *mandatory* RISC-V Specification -also faces, by virtue of there being no transitional way to bring in -show-stopping critical alterations. - -To put this into perspective, just taking into account hardware costs -alone: with production mask charges for 28nm being around USD $1.5m, -engineering development costs and licensing of RTLs for peripherals -being of a similar magnitude, no manufacturer is going to back away -from selling a "flawed" or "legacy" product (whether it complies with -the RISC-V Specification or not) without a bitter fight. - -It was also pointed out that there will be significant software tool -maintenance costs for manufacturers, meaning that the probability will -be extremely high that they will refuse to shoulder such costs, and -will publish and continue to publish (and use) hopelessly out-of-date -unpatched tools. This practice is well-known to result in security -flaws going unpatched, with one of many immediate undesirable consequences -being that product in extremely large volume gets discarded into landfill. - -**All and any of the issues that were discussed, and all of those that -were not, can be avoided by providing a hardware-level runtime-enabled -forwards and backwards compatible transition path between *all* parts -(mandatory or not) of current and future revisions of the RISC-V ISA -Standard.** - -The rest of the discussion - indicative as it was of the stark mutually -exclusive gap being faced by the RISC-V ISA Standard given that it does -not cope with the problem - was an effort by two groups in two clear -camps: one that wanted things to remain as they are, and another that -made efforts to point out that the consequences of not taking action -are clearly extreme and irreversible (which, unfortunately, given the -severity, some of the first group were unable to believe, despite there -being clear historical precedent for the exact same mistake being made in -other architectures, and the consequences on the same being absolutely -clear). - -However after a significant amount of time, certain clear requirements came -out of the discussion: - -* Any proposal must be a minimal change with minimal (or zero) impact -* Any proposal should place no restriction on existing or future - ISA encoding space -* 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. - -Several proposals were put forward (and some are still under discussion) - -* "Do nothing": problem is not severe: no action needed. -* "Do nothing": problem is out-of-scope for RISC-V Foundation. -* "Do nothing": problem complicates Compliance Testing (and is out of scope) -* "MISA": the MISA CSR enables and disables extensions already: use that -* "MISA-like": a new CSR which switches in and out new encodings - (without destroying state) -* "mvendorid/marchid WARL": switching the entire "identity" of a machine -* "ioctl-like": a OO proposal based around the linux kernel "ioctl" system. - -Each of these will be discussed below in their own sections. - -# Do nothing (no problem exists) - -(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, -and it was exhaustively (and exhaustingly) established that none of -them are workable. - -Initially it was pointed out that Fabless Semiconductor companies could -simply license multiple Custom Extensions and a suitable RISC-V core, and -modify them accordingly. The Fabless Semi Company would be responsible -for paying the NREs on re-developing the test vectors (as the extension -licensers would be extremely unlikely to do that without payment), and -given that said Companies have an "integration" job to do, it would -be reasonable to expect them to have such additional costs as well. - -The costs of this approach were outlined and discussed as being -disproportionate and extreme compared to the actual likely cost of -licensing the Custom Extensions in the first place. Additionally it -was pointed out that not only hardware NREs would be involved but -custom software tools (compilers and more) would also be required -(and maintained separately, on the basis that upstream would not -accept them except under extreme pressure, and then only with -prejudice). - -All similar schemes involving customisation of the custom extensions -were likewise rejected, but not before the customisation process was -mistakenly conflated with tne *normal* integration process of developing -a custom processor (Bus Architectures, Cache layouts, peripheral layouts). - -The most compelling hardware-related reason (excluding the severe impact on -the software ecosystem) for rejecting the customisation-of-customisation -approach was the case where Extensions were using an instruction encoding -space (48-bit, 64-bit) *greater* than that which the chosen core could -cope with (32-bit, 48-bit). - -Overall, none of the options presented were feasible, and, in addition, -with no clear leadership from the RISC-V Foundation on how to avoid -global world-wide encoding conflict, even if they were followed through, -still would result in the failure of the RISC-V ecosystem due to -irreversible global conflicting ISA binary-encoding meanings (POWERPC's -Altivec / SPE nightmare). - -This in addition to the case where the RISC-V Foundation wishes to -fix a critical show-stopping update to the Standard, post-release, -where billions of dollars have been spent on deploying RISC-V in the -field. - -# Do nothing (out of scope) - -(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 -considers Custom Extensions to be "out of scope"; that "it's not their -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 (*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) - -(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 - out of scope, Compliance testing of simultaneous legacy (old revisions of - ISA Standards) and current (new revisions of ISA Standard) definitely - is not. Efforts to reduce *Compliance Testing* complexity is therefore - "Compliance Tail Wagging Standard Dog". -* Beyond a certain threshold, complexity of Compliance Testing is so - burdensome that it risks outright rejection of the entire Standard. - -Meeting these two diametrically-opposed perspectives requires that the -solution be very, very simple. - -# MISA - -(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 -another that happens to use the same binary encoding. - -*However*: - -* MISA Extension disabling is permitted (optionally) to **destroy** - the state information. Thus it is totally unsuitable for cases - where instructions from different Custom extensions are needed in - quick succession. -* 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 - -(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 - -(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. 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: - -* 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. - -**This is the only one of the proposals that meet the full requirements** - -# ioctl-like - -(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 - -The following conversation exerpts are taken from the ISA-dev discussion - -## (1) Albert Calahan on SPE / Altiven conflict in POWERPC - -> 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. - -## (2) Luke Kenneth Casson Leighton on Standards backwards-compatibility - -> 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. - -## (3) Allen Baum on Standards Compliance - -> Putting my compliance chair hat on: One point that was made quite -> clear to me is that compliance will only test that an implementation -> correctly implements the portions of the spec that are mandatory, and -> the portions of the spec that are optional and the implementor claims -> it is implementing. It will test nothing in the custom extension space, -> and doesn't monitor or care what is in that space. - -# References - -* -*