1 # Resolving ISA conflicts and providing a pain-free RISC-V Standards Upgrade Path
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).
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).
16 With no transition path there is guaranteed to be tension and conflict
17 within the RISC-V Community over whether revisions should be made:
18 should existing legacy designs be prioritised, mutually-exclusively over
19 future designs (and what happens during the transition period is absolute
20 chaos, with the compiler toolchain, software ecosystem and ultimately
21 the end-users bearing the full brunt of the impact). If several
22 overlapping revisions are required that have not yet transitioned out
23 of use (which could take well over two decades to occur) the situation
24 becomes disastrous for the credibility of the entire RISC-V ecosystem.
26 It was also pointed out that Compliance is an extremely important factor
27 to take into consideration, and that Custom Extensions (as being optional)
28 effectively and quite reasonably fall entirely outside of the scope of
29 Compliance Testing. At this point in the discussion however it was not
30 yet noted the stark problem that the *mandatory* RISC-V Specification
31 also faces, by virtue of there being no transitional way to bring in
32 show-stopping critical alterations.
34 To put this into perspective, just taking into account hardware costs
35 alone: with production mask charges for 28nm being around USD $1.5m,
36 engineering development costs and licensing of RTLs for peripherals
37 being of a similar magnitude, no manufacturer is going to back away
38 from selling a "flawed" or "legacy" product (whether it complies with
39 the RISC-V Specification or not) without a bitter fight.
41 It was also pointed out that there will be significant software tool
42 maintenance costs for manufacturers, meaning that the probability will
43 be extremely high that they will refuse to shoulder such costs, and
44 will publish and continue to publish (and use) hopelessly out-of-date
45 unpatched tools. This practice is well-known to result in security
46 flaws going unpatched, with one of many immediate undesirable consequences
47 being that product in extremely large volume gets discarded into landfill.
49 **All and any of the issues that were discussed, and all of those that
50 were not, can be avoided by providing a hardware-level runtime-enabled
51 forwards and backwards compatible transition path between *all* parts
52 (mandatory or not) of current and future revisions of the RISC-V ISA
55 The rest of the discussion - indicative as it was of the stark mutually
56 exclusive gap being faced by the RISC-V ISA Standard given that it does
57 not cope with the problem - was an effort by two groups in two clear
58 camps: one that wanted things to remain as they are, and another that
59 made efforts to point out that the consequences of not taking action
60 are clearly extreme and irreversible (which, unfortunately, given the
61 severity, some of the first group were unable to believe, despite there
62 being clear historical precedent for the exact same mistake being made in
63 other architectures, and the consequences on the same being absolutely
66 However after a significant amount of time, certain clear requirements came
67 out of the discussion:
69 * Any proposal must be a minimal change with minimal (or zero) impact
70 * Any proposal should place no restriction on existing or future
72 * Any proposal should take into account that there are existing implementors
73 of the (yet to be finalised but still "partly frozen") Standard who may
74 resist, for financial investment reasons, efforts to make any change
75 (at all) that could cost them immediate short-term profits.
77 Several proposals were put forward (and some are still under discussion)
79 * "Do nothing": problem is not severe: no action needed.
80 * "Do nothing": problem is out-of-scope for RISC-V Foundation.
81 * "Do nothing": problem complicates Compliance Testing (and is out of scope)
82 * "MISA": the MISA CSR enables and disables extensions already: use that
83 * "MISA-like": a new CSR which switches in and out new encodings
84 (without destroying state)
85 * "mvendorid/marchid WARL": switching the entire "identity" of a machine
86 * "ioctl-like": a OO proposal based around the linux kernel "ioctl" system.
88 Each of these will be discussed below in their own sections.
90 # Do nothing (no problem exists)
92 (Summary: not an option)
94 There were several solutions offered that fell into this category.
95 A few of them are listed in the introduction; more are listed below,
96 and it was exhaustively (and exhaustingly) established that none of
99 Initially it was pointed out that Fabless Semiconductor companies could
100 simply license multiple Custom Extensions and a suitable RISC-V core, and
101 modify them accordingly. The Fabless Semi Company would be responsible
102 for paying the NREs on re-developing the test vectors (as the extension
103 licensers would be extremely unlikely to do that without payment), and
104 given that said Companies have an "integration" job to do, it would
105 be reasonable to expect them to have such additional costs as well.
107 The costs of this approach were outlined and discussed as being
108 disproportionate and extreme compared to the actual likely cost of
109 licensing the Custom Extensions in the first place. Additionally it
110 was pointed out that not only hardware NREs would be involved but
111 custom software tools (compilers and more) would also be required
112 (and maintained separately, on the basis that upstream would not
113 accept them except under extreme pressure, and then only with
116 All similar schemes involving customisation of the custom extensions
117 were likewise rejected, but not before the customisation process was
118 mistakenly conflated with tne *normal* integration process of developing
119 a custom processor (Bus Architectures, Cache layouts, peripheral layouts).
121 The most compelling hardware-related reason (excluding the severe impact on
122 the software ecosystem) for rejecting the customisation-of-customisation
123 approach was the case where Extensions were using an instruction encoding
124 space (48-bit, 64-bit) *greater* than that which the chosen core could
125 cope with (32-bit, 48-bit).
127 Overall, none of the options presented were feasible, and, in addition,
128 with no clear leadership from the RISC-V Foundation on how to avoid
129 global world-wide encoding conflict, even if they were followed through,
130 still would result in the failure of the RISC-V ecosystem due to
131 irreversible global conflicting ISA binary-encoding meanings (POWERPC's
132 Altivec / SPE nightmare).
134 This in addition to the case where the RISC-V Foundation wishes to
135 fix a critical show-stopping update to the Standard, post-release,
136 where billions of dollars have been spent on deploying RISC-V in the
139 # Do nothing (out of scope)
141 (Summary: may not be RV Foundation's "scope", still results in
142 problem, so not an option)
144 This was one of the first arguments presented: The RISC-V Foundation
145 considers Custom Extensions to be "out of scope"; that "it's not their
146 problem, therefore there isn't a problem".
148 The logical errors in this argument were quickly enumerated: namely that
149 the RISC-V Foundation is not in control of the uses to which RISC-V is
150 put, such that public global conflicts in binary-encoding are a hundred
151 percent guaranteed to occur (*outside* of the control and remit of the
152 RISC-V Foundation), and a hundred percent guaranteed to occur in
153 *commodity* hardware where Debian, Fedora, SUSE and other distros will
154 be hardest hit by the resultant chaos, and that will just be the more
155 "visible" aspect of the underlying problem.
157 # Do nothing (Compliance too complex, therefore out of scope)
159 (Summary: may not be RV Foundation's "scope", still results in
160 problem, so not an option)
162 The summary here was that Compliance testing of Custom Extensions is
163 not just out-of-scope, but even if it was taken into account that
164 binary-encoding meanings could change, it would still be out-of-scope.
166 However at the time that this argument was made, it had not yet been
167 appreciated fully the impact that revisions to the Standard would have,
168 when billions of dollars worth of (older, legacy) RISC-V hardware had
169 already been deployed.
171 Two interestingly diametrically-opposed equally valid arguments exist here:
173 * Whilst Compliance testing of Custom Extensions is definitely legitimately
174 out of scope, Compliance testing of simultaneous legacy (old revisions of
175 ISA Standards) and current (new revisions of ISA Standard) definitely
176 is not. Efforts to reduce *Compliance Testing* complexity is therefore
177 "Compliance Tail Wagging Standard Dog".
178 * Beyond a certain threshold, complexity of Compliance Testing is so
179 burdensome that it risks outright rejection of the entire Standard.
181 Meeting these two diametrically-opposed perspectives requires that the
182 solution be very, very simple.
186 (Summary: MISA not suitable, leads to better idea)
188 MISA permits extensions to be disabled by masking out the relevant bit.
189 Hypothetically it could be used to disable one extension, then enable
190 another that happens to use the same binary encoding.
194 * MISA Extension disabling is permitted (optionally) to **destroy**
195 the state information. Thus it is totally unsuitable for cases
196 where instructions from different Custom extensions are needed in
198 * MISA was only designed to cover Standard Extensions.
199 * There is nothing to prevent multiple Extensions being enabled
200 that wish to simultaneously interpret the same binary encoding.
201 * There is nothing in the MISA specification which permits
202 *future* versions (bug-fixes) of the RISC-V ISA to be "switched in".
204 Overall, whilst the MISA concept is a step in the right direction it's
205 a hundred percent unsuitable for solving the problem.
209 (Summary: basically same as mvend/march WARL except needs an extra CSR where
210 mv/ma doesn't. Along right lines, doesn't meet full requirements)
212 Out of the MISA discussion came a "MISA-like" proposal, which would
213 take into account the flaws pointed out by trying to use "MISA":
215 * The MISA-like CSR's meaning would be identified by compilers using the
216 mvendor-id/march-id tuple as a compiler target
217 * Each custom-defined bit of the MISA-like CSR would (mutually-exclusively)
218 redirect binary encoding(s) to specific encodings
219 * No Extension would *actually* be disabled: its internal state would
220 be left on (permanently) so that switching of ISA decoding
221 could be done inside inner loops without adverse impact on
224 Whilst it was the first "workable" solution it was also noted that the
225 scheme is invasive: it requires an entirely new CSR to be added
226 to the privileged spec (thus making existing implementations redundant).
227 This does not fulfil the "minimum impact" requirement.
229 Also interesting around the same time an additional discussion was
230 raised that covered the *compiler* side of the same equation. This
231 revolved around using mvendorid-marchid tuples at the compiler level,
232 to be put into assembly output (by gcc), preserving the required
233 *globally* unique identifying information for binutils to successfully
234 turn the custom instruction into an actual binary-encoding (plus
235 binary-encoding of the context-switching information). (**TBD, Jacob,
236 separate page? review this para?**)
238 # mvendorid/marchid WARL
240 (Summary: the only idea that meets the full requirements. Needs
241 toolchain backup, but only when the first chip is released)
243 Coming out of the software-related proposal by Jacob Bachmeyer, which
244 hinged on the idea of a globally-maintained gcc / binutils database
245 that kept and coordinated architectural encodings (curated by the Free
246 Software Foundation), was to quite simply make the mvendorid and marchid
247 CSRs have WARL (writeable) characteristics. For instances where mvendorid
248 and marchid are readable, that would be taken to be a Standards-mandatory
249 "declaration" that the architecture has *no* Custom Extensions (and that
250 it conforms precisely to one and only one specific variant of the
251 RISC-V Specification).
253 This incredibly simple non-invasive idea has some unique and distinct
254 advantages over other proposals:
256 * Existing designs - even though the specification is not finalised
257 (but has "frozen" aspects) - would be completely unaffected: the
258 change is to the "wording" of the specification to "retrospectively"
260 * Unlike with the MISA idea this is *purely* at the "decode" phase:
261 no internal Extension state information is permitted to be disabled,
262 altered or destroyed as a direct result of writing to the
263 mvendor/march-id CSRs.
264 * Compliance Testing may be carried out with a different vendorid/marchid
265 tuple set prior to a test, allowing a vendor to claim *Certified*
266 compatibility with *both* one (or more) legacy variants of the RISC-V
267 Specification *and* with a present one.
268 * With sufficient care taken in the implementation an implementor
269 may have multiple interpretations of the same binary encoding within
270 an inner loop, with a single instruction (to the WARL register)
271 changing the meaning.
273 A couple of points were made:
275 * Compliance Testing may **fail** any system that has mvendorid/marchid
276 as WARL. This however is a clear case of "Compliance Tail Wagging Standard
278 * The redirection of meaning of certain binary encodings to multiple
279 engines was considered extreme, eyebrow-raising, and also (importantly)
280 potentially expensive, introducing significant latency at the decode
283 On this latter point, it was observed that MISA already switches out entire
284 sets of instructions (interacts at the "decode" phase). The difference
285 between what MISA does and the mvendor/march-id WARL idea is that whilst
286 MISA only switches instruction decoding on (or off), the WARL idea
287 *redirects* encoding, to *different* engines, fortunately in a deliberately
288 mutually-exclusive fashion.
290 Implementations would therefore, in each Extension (assuming one separate
291 "decode" engine per Extension), simply have an extra (mutually-exclusively
292 enabled) wire in the AND gate for any given binary encoding, and in this
293 way there would actually be very little impact on the latency. The assumption
294 here is that there are not dozens of Extensions vying for the same binary
295 encoding (at which point the Fabless Semi Company has other much more
296 pressing issues to deal with that make resolving encoding conflicts trivial
299 Also pointed out was that in certain cases pipeline stalls could be introduced
300 during the switching phase, if needed, just as they may be needed for
301 correct implementation of (mandatory) support for MISA.
303 **This is the only one of the proposals that meet the full requirements**
307 (Summary: good solid orthogonal idea. See [[ioctl]] for full details)
311 This proposal adds a standardised extension interface to the RV instruction set by introducing a fixed small number (e.g. 8) of "overloadable" R-type opcodes ext_ctl0, .. ext_ctl7. Each takes a process local interface cookie in rs1. Based on the cookie, the CPU routes the "overloaded" instructions to a "device" on or off the CPU that implements the actual semantics.
313 The cookie is "opened" with an additional r-type instruction ext_open that takes a 20 bit identifier and "closed" with an ext_close instruction. The implementing hardware device can use the cookie to reference internal state. Thus, interfaces may be statefull.
315 CPU's and devices may implement several interfaces, indeed, are expected to. E.g. a single hardware device might expose a functional interface with 6 overloaded instructions, expose configuration with two highly device specific management interfaces with 8 resp. 4 overloaded instructions, and respond to a standardised save state interface with 4 overloaded instructions.
317 Having a standardised overloadable interface simply avoids much of the need for isa extensions for hardware with non standard interfaces and semantics. This is analogous to the way that the standardised overloadable ioctl interface of the kernel almost completely avoids the need for extending the kernel with syscalls for the myriad of hardware devices with their specific interfaces and semantics.
319 Since the rs1 input of the overloaded ext_ctl instruction's are taken by the interface cookie, they are restricted in use compared to a normal R-type instruction (it is possible to pass 12 bits of additional info by or ing it with the cookie). Delegation is also expected to come at a small additional performance price compared to a "native" instruction. This should be an acceptable tradeoff in most cases.
321 The expanded flexibility comes at the cost: the standard can specify the semantics of the delegation mechanism and the interfacing with the rest of the cpu, but the actual semantics of the overloaded instructions can only be defined by the designer of the interface. Likewise, a device can be conforming as far as delegation and interaction with the CPU is concerned, but whether the hardware is conforming to the semantics of the interface is outside the scope of spec. Being able to specify that semantics using the methods used for RV itself is clearly very valuable. One impetus for doing that is using it for purposes of its own, effectively freeing opcode space for other purposes. Also, some interfaces may become de facto or de jure standards themselves, necessitating hardware to implement competing interfaces. I.e., facilitating a free for all, may lead to standards proliferation. C'est la vie.
323 The only "ISA-collisions" that can still occur are in the 20 bit (~10^6) interface identifier space, with 12 more bits to identify a device on a hart that implements the interface. One suggestion is setting aside 2^19 id's that are handed out for a small fee by a central (automated) registration (making sure the space is not just claimed), while the remaining 2^19 are used as a good hash on a long, plausibly globally unique human readable interface name. This gives implementors the choice between a guaranteed private identifier paying a fee, or relying on low probabilities. The interface identifier could also easily be extended to 42 bits on RV64.
328 This proposal basically mirrors the concept of POSIX ioctls, providing
329 (arbitrarily) 8 functions (opcodes) whose meaning may be over-ridden
330 in an object-orientated fashion by calling an "open handle" (and close)
331 function (instruction) that switches (redirects) the 8 functions over to
335 The "open handle" opcode takes a GUID (globally-unique identifier)
336 and an ioctl number, and stores the UUID in a table indexed by the
339 handle_global_state[8] # stores UUID or index of same
341 def open_handle(uuid, ioctl_num):
342 handle_global_state[ioctl_num] = uuid
344 def close_handle(ioctl_num):
345 handle_global_state[ioctl_num] = -1 # clear table entry
348 "Ioctls" (arbitrarily 8 separate R-type opcodes) then perform a redirect
349 based on what the global state for that numbered "ioctl" has been set to:
351 def ioctl_fn0(*rargs): # star means "take all arguments as a tuple"
352 if handle_global_state[0] == CUSTOMEXT1UUID:
353 CUSTOMEXT1_FN0(*rargs) # apply all arguments to function
354 elif handle_global_state[0] == CUSTOMEXT2UUID:
355 CUSTOMEXT2_FN0(*rargs) # apply all arguments to function
357 raise Exception("undefined opcode")
361 not quite I think. It is more like
363 // Hardware, implementing interface with UUID 0xABCD
365 def A_shutdown(cookie, data):
370 def A_do_stuff(cookie, data):
373 def A_do_more_stuff(cookie, data):
377 "shutdown": A_shutdown,
380 "ctl1": A_do_more_stuff
383 // hardware implementing interface with UUID = 0x1234
385 def B_do_things(cookie, data):
387 def B_shutdown(cookie, data)
391 "shutdown": B_shutdown,
396 // The CPU being wired to the devices
403 // The functionality that the CPU must implement to use the extension interface
405 cpu_open_handles = {}
408 def new_unused_handle_id()
409 __handleId = __handleId + 1
412 def ext_open(uuid, data):
413 interface = cpu_interface[uuid]
415 raise Exception("No such interface")
417 handleId = new_unused_handle_id()
418 cpu_open_handles[handleId] = (interface, CurrentVirtualMemoryAddressSpace)
420 cookie = A_init(data) # Here device takes over
422 return (handle_id, cookie)
424 def ext_close(handle, data):
425 (handleId, cookie) = handle
426 intf_VMA = cpu_open_handles[handleId]
430 (interface, VMA) = intf_VMA
431 if VMA != CurrentVirtualMemoryAddressSpace:
433 assert(interface != NIL)
434 shutdown = interface["shutdown"]
437 err = interface.shutdown(cookie, data) # Here device takes over
441 cpu_open_handles[handleId] = NIL
444 def ext_ctl0(handle, data):
445 (handleId, cookie) = handle
446 intf_VMA = cpu_open_handles[handleId]
448 raise Exception("No such interface")
450 (interface, VMA) = intf_VMA
451 if VMA != CurrentVirtualMemoryAddressSpace:
452 raise Exception("No such interface") #Disclosing that the interface exists in different address is security hole
454 assert(interface != NIL)
455 ctl0 = interface["ctl0"]
457 raise Exception("No such Instruction")
459 return ctl0(cookie, data) # Here device takes over
462 The other ext_ctl's are similar.
469 The proposal is functionally near-identical to that of the mvendor/march-id
470 except extended down to individual opcodes. As such it could hypothetically
471 be proposed as an independent Standard Extension in its own right that extends
472 the Custom Opcode space *or* fits into the brownfield spaces within the
473 existing ISA opcode space *or* is used as the basis of an independent
474 Custom Extension in its own right.
477 I really think it should be in browncode
480 One of the reasons for seeking an extension of the Custom opcode space is
481 that the Custom opcode space is severely limited: only 2 opcodes are free
482 within the 32-bit space, and only four total remain in the 48 and 64-bit
485 Despite the proposal (which is still undergoing clarification)
486 being worthwhile in its own right, and standing on its own merits and
487 thus definitely worthwhile pursuing, it is non-trivial and much more
488 invasive than the mvendor/march-id WARL concept.
492 # Comments, Discussion and analysis
494 TBD: placeholder as of 26apr2018
496 # Summary and Conclusion
498 In the early sections (those in the category "no action") it was established
499 in each case that the problem is not solved. Avoidance of responsibility,
500 or conflation of "not our problem" with "no problem" does not make "problem"
501 go away. Even "making it the Fabless Semiconductor's design problem" resulted
502 in a chip being *more costly to engineer as hardware **and** more costly
503 from a software-support perspective to maintain*... without actually
506 The first idea considered which could fix the problem was to just use
507 the pre-existing MISA CSR, however this was determined not to have
508 the right coverage (Standard Extensions only), and also crucially it
509 destroyed state. Whilst unworkable it did lead to the first "workable"
510 solution, "MISA-like".
512 The "MISA-like" proposal, whilst meeting most of the requirements, led to
513 a better idea: "mvendor/march-id WARL", which, in combination with an offshoot
514 idea related to gcc and binutils, is the only proposal that fully meets the
517 The "ioctl-like" idea *also* solves the problem, but, unlike the WARL idea
518 does not meet the full requirements to be "non-invasive" and "backwards
519 compatible" with pre-existing (pre-Standards-finalised) implementations.
520 It does however stand on its own merit as a way to extend the extremely
521 small Custom Extension opcode space, even if it itself implemented *as*
522 a Custom Extension into which *other* Custom Extensions are subsequently
523 shoe-horned. This approach has the advantage that it requires no "approval"
524 from the RISC-V Foundation... but without the RISC-V Standard "approval"
525 guaranteeing no binary-encoding conflicts, still does not actually solve the
526 problem (if deployed as a Custom Extension for extending Custom Extensions).
528 Overall the mvendor/march-id WARL idea meets the three requirements,
529 and is the only idea that meets the three requirements:
531 * **Any proposal must be a minimal change with minimal (or zero) impact**
532 (met through being purely a single backwards-compatible change to the
533 wording of the specification: mvendor/march-id changes from read-only
535 * **Any proposal should place no restriction on existing or future
537 (met because it is just a change to one pre-existing CSR, as opposed
538 to requiring additional CSRs or requiring extra opcodes or changes
540 * **Any proposal should take into account that there are existing implementors
541 of the (yet to be finalised but still "partly frozen") Standard who may
542 resist, for financial investment reasons, efforts to make any change
543 (at all) that could cost them immediate short-term profits.**
544 (met because existing implementations, with the exception of those
545 that have Custom Extensions, come under the "vendor/arch-id read only
546 is a formal declaration of an implementation having no Custom Extensions"
551 * The consequences of not tackling this are severe: the RISC-V Foundation
552 cannot take a back seat. If it does, clear historical precedent shows
553 100% what the outcome will be (1).
554 * Making the mvendorid and marchid CSRs WARL solves the problem in a
555 minimal to zero-disruptive backwards-compatible fashion that provides
556 indefinite transparent *forwards*-compatibility.
557 * The retro-fitting cost onto existing implementations (even though the
558 specification has not been finalised) is zero to negligeable
559 (only changes to words in the specification required at this time:
560 no vendor need discard existing designs, either being designed,
561 taped out, or actually in production).
562 * The benefits are clear (pain-free transition path for vendors to safely
563 upgrade over time; no fights over Custom opcode space; no hassle for
564 software toolchain; no hassle for GNU/Linux Distros)
565 * The implementation details are clear (and problem-free except for
566 vendors who insist on deploying dozens of conflicting Custom Extensions:
567 an extreme unlikely outlier).
568 * Compliance Testing is straightforward and allows vendors to seek and
569 obtain *multiple* Compliance Certificates with past, present and future
570 variants of the RISC-V Standard (in the exact same processor,
571 simultaneously), in order to support end-customer legacy scenarios and
572 provide the same with a way to avoid "impossible-to-make" decisions that
573 throw out ultra-costly multi-decade-investment in proprietary legacy
574 software at the same as the (legacy) hardware.
578 # Conversation Exerpts
580 The following conversation exerpts are taken from the ISA-dev discussion
582 ## (1) Albert Calahan on SPE / Altiven conflict in POWERPC
584 > Yes. Well, it should be blocked via legal means. Incompatibility is
585 > a disaster for an architecture.
587 > The viability of PowerPC was badly damaged when SPE was
588 > introduced. This was a vector instruction set that was incompatible
589 > with the AltiVec instruction set. Software vendors had to choose,
590 > and typically the choice was "neither". Nobody wants to put in the
591 > effort when there is uncertainty and a market fragmented into
594 > Note how Intel did not screw up. When SSE was added, MMX remained.
595 > Software vendors could trust that instructions would be supported.
596 > Both MMX and SSE remain today, in all shipping processors. With very
597 > few exceptions, Intel does not ship chips with missing functionality.
598 > There is a unified software ecosystem.
600 > This goes beyond the instruction set. MMU functionality also matters.
601 > You can add stuff, but then it must be implemented in every future CPU.
602 > You can not take stuff away without harming the architecture.
604 ## (2) Luke Kenneth Casson Leighton on Standards backwards-compatibility
606 > For the case where "legacy" variants of the RISC-V Standard are
607 > backwards-forwards-compatibly supported over a 10-20 year period in
608 > Industrial and Military/Goverment-procurement scenarios (so that the
609 > impossible-to-achieve pressure is off to get the spec ABSOLUTELY
610 > correct, RIGHT now), nobody would expect a seriously heavy-duty amount
611 > of instruction-by-instruction switching: it'd be used pretty much once
612 > and only once at boot-up (or once in a Hypervisor Virtual Machine
613 > client) and that's it.
615 ## (3) Allen Baum on Standards Compliance
617 > Putting my compliance chair hat on: One point that was made quite
618 > clear to me is that compliance will only test that an implementation
619 > correctly implements the portions of the spec that are mandatory, and
620 > the portions of the spec that are optional and the implementor claims
621 > it is implementing. It will test nothing in the custom extension space,
622 > and doesn't monitor or care what is in that space.
626 * <https://groups.google.com/a/groups.riscv.org/forum/#!topic/isa-dev/7bbwSIW5aqM>
627 * <https://groups.google.com/a/groups.riscv.org/forum/#!topic/isa-dev/InzQ1wr_3Ak%5B1-25%5D>