diff options
-rw-r--r-- | src/c.tex | 11 | ||||
-rw-r--r-- | src/rv32.tex | 33 |
2 files changed, 26 insertions, 18 deletions
@@ -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] |