(no commit message)

[libreriscv.git] / isa_conflict_resolution.mdwn

diff --git a/isa_conflict_resolution.mdwn b/isa_conflict_resolution.mdwn
index 4f9662ece8b521033f76ec5fd8887b86b303cefa..5a316988e7bce0bf0042caeb455eab78a792fd13 100644 (file)
--- a/isa_conflict_resolution.mdwn
+++ b/isa_conflict_resolution.mdwn
@@ -314,37 +314,30 @@ advantages over other proposals:
 
 **This is the only one of the proposals that meet the full requirements**
 
-# ioctl-like <a name="ioctl-like"></a>
+# Overloadable opcodes <a name="overloadable opcodes"></a>
 
-(Summary: good solid orthogonal idea.  See [[ioctl]] for full details)
+See [[ioctl]] for [[pluggable extensions]] [[overloadable opcodes]] for full details)
 
 NOTE: under discussion.
 
-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.
+==RB 2018-5-1 updated to reflect much simplified xext proposal== 
 
-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 *or* is used as the basis of an independent
-Custom Extension in its own right.
+The xext proposal defines 8 standardised R-type xcmd0, xcmd1, ...xcmd7 instructions (preferably in the brownfield opcode space)
+that are routed to (sub)devices that implement one or more interfaces with up to 8 (slightly crippled) R type instruction like commands. 
+Each xext interface is identified by a 20 bit UUID (or 52 bit on RV64). Effectively the 8 standard xcmd instructions are designated as overloadable opcodes. 
+The 20 bit provided by the UUID, so there is much more room than in the 2 custom 32 bit or even 4 custom 64/48 bit opcode spaces. Thus it avoids most of the need to put a claim on opcode space thereby risking collisions when combining independent extensions. In this respect it is much like POSIX ioctls, which obviate the need for defining new syscalls to control new and nonstandard hardware..
 
-==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
-within the 32-bit space, and only four total remain in the 48 and 64-bit
-space.
+==RB not sure about this bit==
+The proposal is functionally similar to that of the mvendor/march-id
+==RB==
+except the non standard extension is explicit and restricted to a small set of well defined individual opcodes. 
+Hence several extensions can be mixed and there is no state to be tracked over context switches. 
+As such it could hypothetically be proposed as an independent Standard Extension.
 
 Despite the proposal (which is still undergoing clarification)
 being worthwhile in its own right, and standing on its own merits and
-thus definitely worthwhile pursuing, it is non-trivial and much more
+thus definitely worthwhile pursuing, it is non-trivial and more
 invasive than the mvendor/march-id WARL concept.
 
 # Comments, Discussion and analysis