isa_conflict_resolution.mdwn

   1 # Resolving ISA conflicts and providing a pain-free RISC-V Standards Upgrade Path
   2
   3 In a lengthy thread that ironically was full of conflict indicative
   4 of the future direction in which RISC-V will go if left unresolved,
   5 multiple Custom Extensions were noted to be permitted free rein to
   6 introduce global binary-encoding conflict with no means of resolution
   7 described or endorsed by the RISC-V Standard: a practice that has known
   8 disastrous and irreversible consequences for any architecture that
   9 permits such practices (1).
  10
  11 Much later on in the discussion it was realised that there is also no way
  12 within the current RISC-V Specification to transition to improved versions
  13 of the standard, regardless of whether the fixes are absolutely critical
  14 show-stoppers or whether they are just keeping the standard up-to-date (2).
  15
  16 It was also pointed out that Compliance is an extremely important factor
  17 to take into consideration, and that Custom Extensions (as being optional)
  18 effectively fall entirely outside of the Compliance Testing.  At this
  19 point in the discussion however it was not yet noted the stark problem
  20 that the *mandatory* RISC-V Specification also faces, by virtue of there
  21 being no transitional way to bring in show-stopping critical alterations.
  22
  23 To put this into perspective, just taking into account hardware costs
  24 alone: with production mask charges for 28nm being around USD $1.5m,
  25 engineering development costs and licensing of RTLs for peripherals
  26 being of a similar magnitude, no manufacturer is going to back away
  27 from selling a "flawed" or "legacy" product (whether it complies with
  28 the RISC-V Specification or not) without a bitter fight.
  29
  30 It was also pointed out that there will be significant software tool
  31 maintenance costs for manufacturers, meaning that the probability will
  32 be extremely high that they will refuse to shoulder such costs, and
  33 publish hopelessly out-of-date unpatched tools.  This practice is
  34 well-known to result in security flaws going unpatched, with one
  35 of many immediate consequences being that product gets discarded into
  36 landfill.
  37
  38 All and any of the issues that were discussed, and all of those that
  39 were not, can be avoided by providing a forwards and backwards
  40 compatible transition path between the current and future *mandatory*
  41 parts of revisions of the RISC-V ISA Standard.
  42
  43 The rest of the discussion - indicative as it was of the stark mutually
  44 exclusive gap being faced by the RISC-V ISA Standard given that it does
  45 not cope with the problem - was an effort by two groups in two clear
  46 camps: one that wanted things to remain as they are, and another that
  47 made efforts to point out that the consequences of not taking action
  48 are clearly extreme and irreversible (which, unfortunately, given the
  49 severity, some of the first group were unable to believe, despite there
  50 being clear historical precedent for the same mistake being made in
  51 other architectures).
  52
  53 However after a significant amount of time, certain clear requirements came
  54 out of the discussion:
  55
  56 * Any proposal must be a minimal change with minimal (or zero) impact
  57 * Any proposal should place no restriction on existing or future
  58   ISA encoding space
  59 * Any proposal should take into account that there are existing implementors
  60   of the (yet to be finalised but still "partly frozen") Standard who may
  61   resist, for financial investment reasons, efforts to make any change
  62   (at all) that could cost them immediate short-term profits.
  63
  64 Several proposals were put forward (and some are still under discussion)
  65
  66 * "Do nothing": problem is not severe: no action needed.
  67 * "Do nothing": problem is out-of-scope for RISC-V Foundation.
  68 * "MISA": the MISA CSR enables and disables extensions already: use that
  69 * "MISA-like": a new CSR which switches in and out new encodings
  70   (without destroying state)
  71 * "mvendorid/marchid WARL": switching the entire "identity" of a machine
  72 * "ioctl-like": a OO proposal based around the linux kernel "ioctl" system.
  73
  74 Each of these will be discussed below in their own sections.
  75
  76 # Do nothing (no problem exists)
  77
  78 TBD
  79
  80 # Do nothing (out of scope)
  81
  82 TBD
  83
  84 # MISA
  85
  86 TBD
  87
  88 # MISA-like
  89
  90 TBD
  91
  92 # mvendorid/marchid WARL
  93
  94 TBD
  95
  96 # ioctl-like
  97
  98 TBD
  99
 100 # Discussion and analysis
 101
 102 TBD
 103
 104 # Conclusion
 105
 106 TBD
 107
 108 # Conversation Exerpts
 109
 110 The following conversation exerpts are taken from the ISA-dev discussion
 111
 112 ## (1) Albert Calahan on SPE / Altiven conflict in POWERPC
 113
 114 > Yes. Well, it should be blocked via legal means. Incompatibility is
 115 > a disaster for an architecture.
 116 >
 117 > The viability of PowerPC was badly damaged when SPE was
 118 > introduced. This was a vector instruction set that was incompatible
 119 > with the AltiVec instruction set. Software vendors had to choose,
 120 > and typically the choice was "neither". Nobody wants to put in the
 121 > effort when there is uncertainty and a market fragmented into
 122 > small bits.
 123 > Note how Intel did not screw up. When SSE was added, MMX remained.
 124 > Software vendors could trust that instructions would be supported.
 125 > Both MMX and SSE remain today, in all shipping processors. With very
 126 > few exceptions, Intel does not ship chips with missing functionality.
 127 > There is a unified software ecosystem.
 128 >
 129 > This goes beyond the instruction set. MMU functionality also matters.
 130 > You can add stuff, but then it must be implemented in every future CPU.
 131 > You can not take stuff away without harming the architecture.
 132
 133 ## (2) Luke Kenneth Casson Leighton on Standards backwards-compatibility
 134
 135 > For the case where "legacy" variants of the RISC-V Standard are
 136 > backwards-forwards-compatibly supported over a 10-20 year period in
 137 > Industrial and Military/Goverment-procurement scenarios (so that the
 138 > impossible-to-achieve pressure is off to get the spec ABSOLUTELY
 139 > correct, RIGHT now), nobody would expect a seriously heavy-duty amount
 140 > of instruction-by-instruction switching: it'd be used pretty much once
 141 > and only once at boot-up (or once in a Hypervisor Virtual Machine
 142 > client) and that's it.
 143
 144 ## (3) Allen Baum on Standards Compliance
 145
 146 > Putting my compliance chair hat on: One point that was made quite
 147 > clear to me is that compliance will only test that an implementation
 148 > correctly implements the portions of the spec that are mandatory, and
 149 > the portions of the spec that are optional and the implementor claims
 150 > it is implementing. It will test nothing in the custom extension space,
 151 > and doesn't monitor or care what is in that space.
 152