clarify

[libreriscv.git] / isa_conflict_resolution.mdwn

diff --git a/isa_conflict_resolution.mdwn b/isa_conflict_resolution.mdwn
index 094f07e846d22daf05adb6486c902bcf6e7a1ab0..cad45abe07fe4d7892030474ad391f0e92ad4055 100644 (file)
--- a/isa_conflict_resolution.mdwn
+++ b/isa_conflict_resolution.mdwn
@@ -312,11 +312,35 @@ 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")
+
 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
@@ -358,7 +382,11 @@ does not meet the full requirements to be "non-invasive" and "backwards
 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: