# 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 hart) 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
+permanently fixes the problem of clashes in Custom Extension opcodes
+on a global basis.
+
+--------
+
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
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.
by comparison).
Also pointed out was that in certain cases pipeline stalls could be introduced
-during the switching phase, if needed.
+during the switching phase, if needed, just as they may be needed for
+correct implementation of (mandatory) support for MISA.
**This is the only one of the proposals that meet the full requirements**
(Summary: good solid orthogonal idea. See [[ioctl]] for full details)
+==RB===
+
+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.
+
+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.
+
+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.
+
+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.
+
+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.
+
+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.
+
+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.
+
+
+====End RB==
+
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 "open handle" opcode takes a GUID (globally-unique identifier)
+and an ioctl number, and stores the UUID in a table indexed by the
+ioctl number:
+
+ handle_global_state[8] # stores UUID or index of same
+
+ def open_handle(uuid, ioctl_num):
+ handle_global_state[ioctl_num] = uuid
+
+ def close_handle(ioctl_num):
+ handle_global_state[ioctl_num] = -1 # clear table entry
+
+
+"Ioctls" (arbitrarily 8 separate R-type opcodes) then perform a redirect
+based on what the global state for that numbered "ioctl" has been set to:
+
+ def ioctl_fn0(*rargs): # star means "take all arguments as a tuple"
+ if handle_global_state[0] == CUSTOMEXT1UUID:
+ CUSTOMEXT1_FN0(*rargs) # apply all arguments to function
+ elif handle_global_state[0] == CUSTOMEXT2UUID:
+ CUSTOMEXT2_FN0(*rargs) # apply all arguments to function
+ else:
+ raise Exception("undefined opcode")
+
+=== RB ==
+
+not quite I think. It is more like
+
+// Hardware, implementing interface with UUID 0xABCD
+
+ def A_shutdown(cookie, data):
+ ...
+
+ def A_init(data)
+
+ def A_do_stuff(cookie, data):
+ ...
+
+ def A_do_more_stuff(cookie, data):
+ ...
+
+ interfaceA = {
+ "shutdown": A_shutdown,
+ "init": A_init,
+ "ctl0": A_do_stuff,
+ "ctl1": A_do_more_stuff
+ }
+
+// hardware implementing interface with UUID = 0x1234
+
+ def B_do_things(cookie, data):
+ ...
+ def B_shutdown(cookie, data)
+ ...
+
+ interfaceB = {
+ "shutdown": B_shutdown,
+ "ctl0": B_do_things
+ }
+
+
+// The CPU being wired to the devices
+
+ cpu_interfaces = {
+ 0xABCD: interfaceA,
+ 0x1234: interfaceB
+ }
+
+// The functionality that the CPU must implement to use the extension interface
+
+ cpu_open_handles = {}
+
+ __handleId = 0
+ def new_unused_handle_id()
+ __handleId = __handleId + 1
+ return __handleId
+
+ def ext_open(uuid, data):
+ interface = cpu_interface[uuid]
+ if interface == NIL:
+ raise Exception("No such interface")
+
+ handleId = new_unused_handle_id()
+ cpu_open_handles[handleId] = (interface, CurrentVirtualMemoryAddressSpace)
+
+ cookie = A_init(data) # Here device takes over
+
+ return (handle_id, cookie)
+
+ def ext_close(handle, data):
+ (handleId, cookie) = handle
+ intf_VMA = cpu_open_handles[handleId]
+ if intf_VMA == NIL:
+ return -1
+
+ (interface, VMA) = intf_VMA
+ if VMA != CurrentVirtualMemoryAddressSpace:
+ return -1
+ assert(interface != NIL)
+ shutdown = interface["shutdown"]
+ if shutdown != NIL:
+
+ err = interface.shutdown(cookie, data) # Here device takes over
+
+ if err != 0:
+ return err
+ cpu_open_handles[handleId] = NIL
+ return 0
+
+ def ext_ctl0(handle, data):
+ (handleId, cookie) = handle
+ intf_VMA = cpu_open_handles[handleId]
+ if intf_VMA == NIL:
+ raise Exception("No such interface")
+
+ (interface, VMA) = intf_VMA
+ if VMA != CurrentVirtualMemoryAddressSpace:
+ raise Exception("No such interface") #Disclosing that the interface exists in different address is security hole
+
+ assert(interface != NIL)
+ ctl0 = interface["ctl0"]
+ if ctl0 == NIL:
+ raise Exception("No such Instruction")
+
+ return ctl0(cookie, data) # Here device takes over
+
+
+The other ext_ctl's are similar.
+
+==End RB==
+
+
+
+
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.
+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
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
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.
+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 change to the specification:
- mvendor/march-id changes from read-only to WARL)
+ (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)
+ (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 declaration of having no Custom Extensions" fall-back category)
+ 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 negligeable
- (changes to words in the specification)
+ 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)
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), in order
- support legacy customers and provide same customers with a way to avoid
- "impossible-to-make" decisions that throw out ultra-expensive multi-decade
- proprietary legacy software at the same as the hardware.
+ 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
> 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,
> 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.
* <https://groups.google.com/a/groups.riscv.org/forum/#!topic/isa-dev/7bbwSIW5aqM>
* <https://groups.google.com/a/groups.riscv.org/forum/#!topic/isa-dev/InzQ1wr_3Ak%5B1-25%5D>
-
projects / libreriscv.git / blobdiff