Updates to HINT sections.

2 files changed, 26 insertions, 18 deletions

diff --git a/src/c.tex b/src/c.tex
index dcb22c3..ed95669 100644
--- a/src/c.tex
+++ b/src/c.tex
@@ -1144,7 +1144,7 @@ valid C instructions will eventually complete.
 A portion of the RVC encoding space is reserved for microarchitectural HINTs.
 Like the HINTs in the RV32I base ISA (see Section~\ref{sec:rv32i-hints}),
 these instructions do not modify any architectural state, except for advancing
-the {\tt pc} and the instructions-retired counter {\tt instret}.  HINTs are
+the {\tt pc} and any applicable performance counters.  HINTs are
 executed as no-ops on implementations that ignore them.
 
 RVC HINTs are encoded as computational instructions that do not modify the
@@ -1163,9 +1163,12 @@ example, \mbox{C.ADD {\em x0}, {\em t0}} might not encode the same HINT
 as \mbox{ADD {\em x0}, {\em x0}, {\em t0}}.
 
 \begin{commentary}
-We expect the static and dynamic frequency of HINT code points will vary
-dramatically.  Decoupling the RVC and RVI HINT mappings allows the scarce RVC
-HINT space to be allocated to the most popular HINTs.
+The primary reason to not require an RVC HINT to expand to an RVI HINT
+is that HINTs are unlikely to be compressible in the same manner as
+the underlying computational instruction.  Also, decoupling the RVC
+and RVI HINT mappings allows the scarce RVC HINT space to be allocated
+to the most popular HINTs, and in particular, to HINTs that are
+amenable to macro-op fusion.
 \end{commentary}
 
 Table~\ref{tab:rvc-hints} lists all RVC HINT code points.  For RV32C, 78\% of
diff --git a/src/rv32.tex b/src/rv32.tex
index 8944e2d..63dad74 100644
--- a/src/rv32.tex
+++ b/src/rv32.tex
@@ -626,17 +626,18 @@ held in the lower 5 bits of register {\em rs2}.
 \end{tabular}
 \end{center}
 
-The NOP instruction does not change any user-visible state, except for
-advancing the {\tt pc} and incrementing the instructions-retired
-counter {\tt instret}.  NOP is encoded
-as ADDI {\em x0, x0, 0}.
+The NOP instruction does not change any architecturally visible state, except for
+advancing the {\tt pc} and incrementing any applicable performance
+counters.  NOP is encoded as ADDI {\em x0, x0, 0}.
 
 \begin{commentary}
 NOPs can be used to align code segments to microarchitecturally
 significant address boundaries, or to leave space for inline code
 modifications.  Although there are many possible ways to encode a NOP,
 we define a canonical NOP encoding to allow microarchitectural
-optimizations as well as for more readable disassembly output.
+optimizations as well as for more readable disassembly output.  The
+other NOP encodings are made available for HINT instructions
+(Section~\ref{sec:rv32i-hints}).
 \end{commentary}
 
 \section{Control Transfer Instructions}
@@ -1525,12 +1526,13 @@ I-cache.
 \section{HINT Instructions}
 \label{sec:rv32i-hints}
 
-RV32I reserves a large encoding space for HINT instructions.  HINT instructions
-are used to communicate performance hints to the microarchitecture.  HINTs are
-encoded as integer computational instructions with {\em rd}={\tt x0}.  Hence,
-like the NOP instruction, HINTs do not change any user-visible state, except
-for advancing the {\tt pc} and the instructions-retired counter {\tt instret}.
-Implementations are always allowed to ignore HINTs.
+RV32I reserves a large encoding space for HINT instructions, which are
+usually used to communicate performance hints to the
+microarchitecture.  HINTs are encoded as integer computational
+instructions with {\em rd}={\tt x0}.  Hence, like the NOP instruction,
+HINTs do not change any architecturally visible state, except for
+advancing the {\tt pc} and any applicable performance counters.
+Implementations are always allowed to ignore the encoded hints.
 
 \begin{commentary}
 This HINT encoding has been chosen so that simple implementations can ignore
@@ -1548,9 +1550,12 @@ remainder of the HINT space is reserved for custom HINTs: no standard HINTs
 will ever be defined in this subspace.
 
 \begin{commentary}
-Although no standard hints are presently defined, we anticipate that
-memory-system spatial and temporal locality hints will be among the first to be
-standardized.
+No standard hints are presently defined (except the privileged WFI
+instruction which uses a separately reserved encoding).  We anticipate
+standard hints to eventually include memory-system spatial and
+temporal locality hints, branch prediction hints, thread-scheduling
+hints, security tags, and instrumentation flags for
+simulation/emulation.
 \end{commentary}
 
 \begin{table}[hbt]