start filling in

diff --git a/isa_conflict_resolution.mdwn b/isa_conflict_resolution.mdwn
index 9389c116ba5f9f56f5034c4d5675274f3d1f97a0..d2cc4d13d919c1f3c0474758dbd29057c4996513 100644 (file)
--- a/isa_conflict_resolution.mdwn
+++ b/isa_conflict_resolution.mdwn
@@ -290,7 +290,7 @@ pressing issues to deal with that make resolving encoding conflicts trivial
 by comparison).
 
 Also pointed out was that in certain cases pipeline stalls could be introduced
 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.

 
 **This is the only one of the proposals that meet the full requirements**
 
 
 **This is the only one of the proposals that meet the full requirements**
 


@@ -298,6 +298,28 @@ during the switching phase, if needed.
 
 TBD - [[ioctl]] for full details, summary kept here
 
 
 TBD - [[ioctl]] for full details, summary kept here
 

+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 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.
+
+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.
+
+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
+invasive than the mvendor/march-id WARL concept.
+

 # Discussion and analysis
 
 TBD
 # Discussion and analysis
 
 TBD