X-Git-Url: https://git.libre-soc.org/?p=libreriscv.git;a=blobdiff_plain;f=isa_conflict_resolution.mdwn;h=8125aa392c63c24b80d0768376037d794ade3966;hp=b8291c32cd88f369d9b11ec43ae7ef35e30c389a;hb=HEAD;hpb=3d0c40b2b0949b1850327e60a5deb6318c023015 diff --git a/isa_conflict_resolution.mdwn b/isa_conflict_resolution.mdwn deleted file mode 100644 index b8291c32c..000000000 --- a/isa_conflict_resolution.mdwn +++ /dev/null @@ -1,202 +0,0 @@ -# Resolving ISA conflicts and providing a pain-free RISC-V Standards Upgrade Path - -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). - -It was also pointed out that Compliance is an extremely important factor -to take into consideration, and that Custom Extensions (as being optional) -effectively fall entirely outside of the 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 -publish hopelessly out-of-date unpatched tools. This practice is -well-known to result in security flaws going unpatched, with one -of many immediate consequences being that product 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 forwards and backwards -compatible transition path between the current and future *mandatory* -parts of 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 same mistake being made in -other architectures). - -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. -* "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) - -TBD - -# Do nothing (out of scope) - -TBD - -# MISA - -TBD - -> * 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. - -# MISA-like - -TBD - -# mvendorid/marchid WARL - -TBD - -> 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. - -# ioctl-like - -TBD - -# Discussion and analysis - -TBD - -# Conclusion - -TBD - -# 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. -