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")
+
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.
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
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 fashion.
* 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 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 (legacy) hardware.
+
+-------
# Conversation Exerpts
projects / libreriscv.git / blobdiff