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**
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:
> 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.
projects / libreriscv.git / blobdiff