diff options
author | Daniel Lustig <dlustig@nvidia.com> | 2021-06-02 09:49:23 -0400 |
---|---|---|
committer | Daniel Lustig <dlustig@nvidia.com> | 2021-06-02 09:49:23 -0400 |
commit | e2f81a1791cf5f0483200c3c37150d0f2eccc485 (patch) | |
tree | 12b9364c66ecf3a7d9c5538f0234a5f02343d0da /src/rv32.tex | |
parent | 883bd183513ccdfed62a31d862d1c843aed3e3d0 (diff) | |
parent | 58b9433f58d5b199a7e470f11cb7474368cb7d11 (diff) | |
download | riscv-isa-manual-e2f81a1791cf5f0483200c3c37150d0f2eccc485.zip riscv-isa-manual-e2f81a1791cf5f0483200c3c37150d0f2eccc485.tar.gz riscv-isa-manual-e2f81a1791cf5f0483200c3c37150d0f2eccc485.tar.bz2 |
Merge branch 'virtual-memory' into Svnapot
Diffstat (limited to 'src/rv32.tex')
-rw-r--r-- | src/rv32.tex | 60 |
1 files changed, 42 insertions, 18 deletions
diff --git a/src/rv32.tex b/src/rv32.tex index 1a1ad06..afc6730 100644 --- a/src/rv32.tex +++ b/src/rv32.tex @@ -1,8 +1,7 @@ \chapter{RV32I Base Integer Instruction Set, Version 2.1} \label{rv32} -This chapter describes version 2.0 of the RV32I base integer -instruction set. +This chapter describes the RV32I base integer instruction set. \begin{commentary} RV32I was designed to be sufficient to form a compiler target and to @@ -131,7 +130,7 @@ high-performance code, where there can be extensive use of loop unrolling, software pipelining, and cache tiling. For these reasons, we chose a conventional size of 32 integer -registers for the base ISA. Dynamic register usage tends to be +registers for RV32I. Dynamic register usage tends to be dominated by a few frequently accessed registers, and regfile implementations can be optimized to reduce access energy for the frequently accessed registers~\cite{jtseng:sbbci}. The optional @@ -1129,7 +1128,7 @@ packed-SIMD extension or handling externally packed data structures. Our rationale for allowing EEIs to choose to support misaligned accesses via the regular load and store instructions is to simplify the addition of misaligned hardware support. One option would have -been to disallow misaligned accesses in the base ISA and then provide +been to disallow misaligned accesses in the base ISAs and then provide some separate ISA support for misaligned accesses, either special instructions to help software handle misaligned accesses or a new hardware addressing mode for misaligned accesses. Special @@ -1352,7 +1351,7 @@ supervisor-level operating system or debugger. Another use of EBREAK is to support ``semihosting'', where the execution environment includes a debugger that can provide services over an alternate system call interface built around the EBREAK - instruction. Because the RISC-V base ISA does not provide more than + instruction. Because the RISC-V base ISAs do not provide more than one EBREAK instruction, RISC-V semihosting uses a special sequence of instructions to distinguish a semihosting EBREAK from a debugger inserted EBREAK. @@ -1366,7 +1365,7 @@ supervisor-level operating system or debugger. described in Chapter~\ref{compressed}. The shift NOP instructions are still considered available for use as - HINTS. + HINTs. Semihosting is a form of service call and would be more naturally encoded as an ECALL using an existing ABI, but this would require @@ -1384,29 +1383,44 @@ supervisor-level operating system or debugger. 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. +microarchitecture. +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. +Most RV32I HINTs are encoded as integer computational instructions with +{\em rd}={\tt x0}. +The other RV32I HINTs are encoded as FENCE instructions with a null +predecessor or successor set and with {\em fm}=0. + \begin{commentary} -This HINT encoding has been chosen so that simple implementations can ignore -HINTs altogether, and instead execute a HINT as a regular computational +These HINT encodings have been chosen so that simple implementations can ignore +HINTs altogether, and instead execute a HINT as a regular instruction that happens not to mutate the architectural state. For example, ADD is a HINT if the destination register is {\tt x0}; the five-bit {\em rs1} and {\em rs2} fields encode arguments to the HINT. However, a simple implementation can simply execute the HINT as an ADD of {\em rs1} and {\em rs2} that writes {\tt x0}, which has no architecturally visible effect. + +As another example, a FENCE instruction with a zero {\em pred} field and +a zero {\em fm} field is a HINT; the {\em succ}, {\em rs1}, and {\em rd} +fields encode the arguments to the HINT. +A simple implementation can simply execute the HINT as a FENCE that orders the +null set of prior memory accesses before whichever subsequent memory accesses +are encoded in the {\em succ} field. +Since the intersection of the predecessor and successor sets is null, the +instruction imposes no memory orderings, and so it has no architecturally +visible effect. \end{commentary} Table~\ref{tab:rv32i-hints} lists all RV32I HINT code points. 91\% of the HINT -space is reserved for standard HINTs, but none are presently defined. The -remainder of the HINT space is designated for custom HINTs; no standard HINTs +space is reserved for standard HINTs. The +remainder of the HINT space is designated for custom HINTs: no standard HINTs will ever be defined in this subspace. \begin{commentary} -No standard hints are presently defined. We anticipate +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 @@ -1418,7 +1432,7 @@ simulation/emulation. \begin{tabular}{|l|l|c|l|} \hline Instruction & Constraints & Code Points & Purpose \\ \hline \hline - LUI & {\em rd}={\tt x0} & $2^{20}$ & \multirow{15}{*}{\em Reserved for future standard use} \\ \cline{1-3} + LUI & {\em rd}={\tt x0} & $2^{20}$ & \multirow{25}{*}{\em Reserved for future standard use} \\ \cline{1-3} AUIPC & {\em rd}={\tt x0} & $2^{20}$ & \\ \cline{1-3} \multirow{2}{*}{ADDI} & {\em rd}={\tt x0}, and either & \multirow{2}{*}{$2^{17}-1$} & \\ & {\em rs1}$\neq${\tt x0} or {\em imm}$\neq$0 & & \\ \cline{1-3} @@ -1433,8 +1447,18 @@ simulation/emulation. SLL & {\em rd}={\tt x0} & $2^{10}$ & \\ \cline{1-3} SRL & {\em rd}={\tt x0} & $2^{10}$ & \\ \cline{1-3} SRA & {\em rd}={\tt x0} & $2^{10}$ & \\ \cline{1-3} - \multirow{2}{*}{FENCE}& {\em fm=0}, and either & \multirow{2}{*}{$2^{5}-1$} & \\ - & {\em pred}=0 or {\em succ}=0 & & \\ \hline \hline + \multirow{3}{*}{FENCE}& {\em rd}={\tt x0}, {\em rs1}$\neq${\tt x0}, & \multirow{3}{*}{$2^{10}-63$}& \\ + & {\em fm}=0, and either & & \\ + & {\em pred}=0 or {\em succ}=0 & & \\ \cline{1-3} + \multirow{3}{*}{FENCE}& {\em rd}$\neq${\tt x0}, {\em rs1}={\tt x0}, & \multirow{3}{*}{$2^{10}-63$}& \\ + & {\em fm}=0, and either & & \\ + & {\em pred}=0 or {\em succ}=0 & & \\ \cline{1-3} + \multirow{2}{*}{FENCE}& {\em rd}={\em rs1}={\tt x0}, {\em fm}=0, & \multirow{2}{*}{15} & \\ + & {\em pred}=0, {\em succ}$\neq$0 & & \\ \cline{1-3} + \multirow{2}{*}{FENCE}& {\em rd}={\em rs1}={\tt x0}, {\em fm}=0, & \multirow{2}{*}{15} & \\ + & {\em pred}$\neq$W, {\em succ}=0 & & \\ \hline + \multirow{2}{*}{FENCE}& {\em rd}={\em rs1}={\tt x0}, {\em fm}=0, & \multirow{2}{*}{1} & \multirow{2}{*}{PAUSE} \\ + & {\em pred}=W, {\em succ}=0 & & \\ \hline \hline SLTI & {\em rd}={\tt x0} & $2^{17}$ & \multirow{7}{*}{\em Designated for custom use} \\ \cline{1-3} SLTIU & {\em rd}={\tt x0} & $2^{17}$ & \\ \cline{1-3} SLLI & {\em rd}={\tt x0} & $2^{10}$ & \\ \cline{1-3} |