+++ /dev/null
-# 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.
-
projects / libreriscv.git / blobdiff