clarify

[libreriscv.git] / isa_conflict_resolution.mdwn

diff --git a/isa_conflict_resolution.mdwn b/isa_conflict_resolution.mdwn
index baa2f8371a18f6a0983197e01be99eaf63604b83..5538a7add9af251063c15808234636ec3a0cc313 100644 (file)
--- a/isa_conflict_resolution.mdwn
+++ b/isa_conflict_resolution.mdwn
@@ -267,7 +267,7 @@ turn the custom instruction into an actual binary-encoding (plus
 binary-encoding of the context-switching information).  (**TBD, Jacob,
 separate page?  review this para?**)
 
-# mvendorid/marchid WARL <a name="#mvendor_marchid_warl" />
+# mvendorid/marchid WARL <a name="mvendor_marchid_warl"></a>
 
 (Summary: the only idea that meets the full requirements.  Needs
  toolchain backup, but only when the first chip is released)
@@ -347,7 +347,9 @@ Update 29apr2018:
   mvendorid-marchid setting is incapable of correctly interpreting.
   To fix this it will be necessary for implementations (hardware /
   software) to set up separate per-mvendorid-marchid trap handlers and
-  for the hardware (or software) to switch to the appropriate trap "set".
+  for the hardware (or software) to switch to the appropriate trap "set"
+  when the mvendorid-marchid is written to.  The switch to a different
+  "set" will almost undoubtedly require (transparent) hardware assistance.
 * It's been noted that there may be certain legitimate cases where an
   mvendorid-marchid should *specifically* not be tested for RISC-V
   Certification Compliance: native support for foreign architectures
@@ -358,7 +360,7 @@ Update 29apr2018:
   hardware-level ISA support to not be permitted to receive RISC-V
   Certification Compliance.
 
-# ioctl-like <a name="#ioctl-like" />
+# ioctl-like <a name="ioctl-like"></a>
 
 (Summary: good solid orthogonal idea.  See [[ioctl]] for full details)