1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
|
\chapter{``Zicsr'', Control and Status Register (CSR) Instructions, Version 2.0}
\label{csrinsts}
RISC-V defines a separate address space of 4096 Control and Status
registers associated with each hart. This chapter defines the full
set of CSR instructions that operate on these CSRs.
\begin{commentary}
While CSRs are primarily used by the privileged architecture, there
are several uses in unprivileged code including for counters and
timers, and for floating-point status.
The counters and timers are no longer considered mandatory parts of
the standard base ISAs, and so the CSR instructions required to
access them have been moved out of the base ISA chapter into this
separate chapter.
\end{commentary}
\section{CSR Instructions}
All CSR instructions atomically read-modify-write a single CSR, whose
CSR specifier is encoded in the 12-bit {\em csr} field of the
instruction held in bits 31--20. The immediate forms use a 5-bit
zero-extended immediate encoded in the {\em rs1} field.
\vspace{-0.2in}
\begin{center}
\begin{tabular}{M@{}R@{}F@{}R@{}S}
\\
\instbitrange{31}{20} &
\instbitrange{19}{15} &
\instbitrange{14}{12} &
\instbitrange{11}{7} &
\instbitrange{6}{0} \\
\hline
\multicolumn{1}{|c|}{csr} &
\multicolumn{1}{c|}{rs1} &
\multicolumn{1}{c|}{funct3} &
\multicolumn{1}{c|}{rd} &
\multicolumn{1}{c|}{opcode} \\
\hline
12 & 5 & 3 & 5 & 7 \\
source/dest & source & CSRRW & dest & SYSTEM \\
source/dest & source & CSRRS & dest & SYSTEM \\
source/dest & source & CSRRC & dest & SYSTEM \\
source/dest & uimm[4:0] & CSRRWI & dest & SYSTEM \\
source/dest & uimm[4:0] & CSRRSI & dest & SYSTEM \\
source/dest & uimm[4:0] & CSRRCI & dest & SYSTEM \\
\end{tabular}
\end{center}
The CSRRW (Atomic Read/Write CSR) instruction atomically swaps values
in the CSRs and integer registers. CSRRW reads the old value of the
CSR, zero-extends the value to XLEN bits, then writes it to integer
register {\em rd}. The initial value in {\em rs1} is written to the
CSR. If {\em rd}={\tt x0}, then the instruction shall not read the CSR
and shall not cause any of the side effects that might occur on a CSR
read.
The CSRRS (Atomic Read and Set Bits in CSR) instruction reads the
value of the CSR, zero-extends the value to XLEN bits, and writes it
to integer register {\em rd}. The initial value in integer register
{\em rs1} is treated as a bit mask that specifies bit positions to be
set in the CSR. Any bit that is high in {\em rs1} will cause the
corresponding bit to be set in the CSR, if that CSR bit is writable.
Other bits in the CSR are unaffected (though CSRs might have side
effects when written).
The CSRRC (Atomic Read and Clear Bits in CSR) instruction reads the
value of the CSR, zero-extends the value to XLEN bits, and writes it
to integer register {\em rd}. The initial value in integer register
{\em rs1} is treated as a bit mask that specifies bit positions to be
cleared in the CSR. Any bit that is high in {\em rs1} will cause the
corresponding bit to be cleared in the CSR, if that CSR bit is
writable. Other bits in the CSR are unaffected.
For both CSRRS and CSRRC, if {\em rs1}={\tt x0}, then the instruction
will not write to the CSR at all, and so shall not cause any of the
side effects that might otherwise occur on a CSR write, such as
raising illegal instruction exceptions on accesses to read-only CSRs.
Both CSRRS and CSRRC always read the addressed CSR and cause any read
side effects regardless of {\em rs1} and {\em rd} fields. Note that
if {\em rs1} specifies a register holding a zero value other than {\tt
x0}, the instruction will still attempt to write the unmodified
value back to the CSR and will cause any attendant side effects. A
CSRRW with {\em rs1}={\tt x0} will attempt to write zero to the
destination CSR.
The CSRRWI, CSRRSI, and CSRRCI variants are similar to CSRRW, CSRRS,
and CSRRC respectively, except they update the CSR using an XLEN-bit
value obtained by zero-extending a 5-bit unsigned immediate (uimm[4:0]) field
encoded in the {\em rs1} field instead of a value from an integer
register. For CSRRSI and CSRRCI, if the uimm[4:0] field is zero, then
these instructions will not write to the CSR, and shall not cause any
of the side effects that might otherwise occur on a CSR write. For
CSRRWI, if {\em rd}={\tt x0}, then the instruction shall not read the
CSR and shall not cause any of the side effects that might occur on a
CSR read. Both CSRRSI and CSRRCI will always read the CSR and cause
any read side effects regardless of {\em rd} and {\em rs1} fields.
\begin{table}
\centering
\begin{tabular}{|l|r|r|c|c|}
\hline
\multicolumn{5}{|c|}{Register operand} \\
\hline
Instruction & rd & rs1 & read CSR? & write CSR? \\
\hline
CSRRW & {\tt x0} & - & no & yes \\
CSRRW & !{\tt x0} & - & yes & yes \\
CSRR{S/C} & - & {\tt x0} & yes & no \\
CSRR{S/C} & - & !{\tt x0} & yes & yes \\
\hline
\multicolumn{5}{|c|}{Immediate operand} \\
\hline
Instruction & rd & uimm & read CSR? & write CSR? \\
\hline
CSRRWI & {\tt x0} & - & no & yes \\
CSRRWI & !{\tt x0} & - & yes & yes \\
CSRR{S/C}I & - & 0 & yes & no \\
CSRR{S/C}I & - & !0 & yes & yes \\
\hline
\end{tabular}
\caption{Table showing whether a CSR instruction reads or writes a
given CSR. The CSRRS and CSRRC instructions have same behavior so
are shown as CSRR{S/C} in Table.}
\label{tab:csrsideeffects}
\end{table}
Table~\ref{tab:csrsideeffects} summarizes the behavior of the CSR
instructions with respect to whether they read and/or write the CSR.
\begin{commentary}
The CSRs defined so far do not have any architectural side effects on reads
beyond raising illegal instruction exceptions on disallowed accesses.
Custom extensions might add CSRs with side effects on reads.
\end{commentary}
Some CSRs, such as the instructions-retired counter, {\tt instret},
may be modified as side effects of instruction execution. In these
cases, if a CSR access instruction reads a CSR, it reads the value
prior to the execution of the instruction. If a CSR access
instruction writes such a CSR, the write is done instead of the
increment. In particular, a value written to {\tt instret} by one
instruction will be the value read by the following instruction.
The assembler pseudoinstruction to read a CSR, CSRR {\em rd, csr}, is
encoded as CSRRS {\em rd, csr, x0}. The assembler pseudoinstruction
to write a CSR, CSRW {\em csr, rs1}, is encoded as CSRRW {\em x0, csr,
rs1}, while CSRWI {\em csr, uimm}, is encoded as CSRRWI {\em x0,
csr, uimm}.
Further assembler pseudoinstructions are defined to set and clear
bits in the CSR when the old value is not required: CSRS/CSRC {\em
csr, rs1}; CSRSI/CSRCI {\em csr, uimm}.
\subsection*{CSR Access Ordering}
Each RISC-V hart observes its own CSR accesses, including its implicit CSR
accesses, as if they were performed in program order. Between harts, RISC-V
has a relaxed CSR ordering model, in that other harts may perceive some CSR
accesses in a different order. CSR accesses are ordered with each other and
with memory accesses by the syntactic dependency rules of the memory model
(see Section~\ref{sec:rvwmo}) and by FENCE instructions. For the purposes of
the FENCE instruction (see Section~\ref{sec:fence}), CSR reads are considered
device input (I), and CSR writes are considered device output (O).
For CSR accesses that cause side effects, these ordering constraints dictate
the ordering of side-effect initiation, not necessarily the ordering of
side-effect completion.
The hardware platform may define some CSRs as belonging to a strongly ordered
I/O space, as defined in the Memory-Ordering PMAs section in Volume II of this
manual, thereby implying stronger ordering constraints with other CSR
accesses, memory-mapped I/O accesses, or both.
\begin{commentary}
A future revision of the memory model will formalize this CSR I/O ordering
scheme.
\end{commentary}
\begin{commentary}
These CSR-ordering constraints are imposed primarily to support ordering
main memory and memory-mapped I/O accesses with respect to reads of the {\tt time}
CSR. With the exception of the {\tt time}, {\tt cycle}, and {\tt mcycle}
CSRs, the CSRs defined thus far in Volumes I and II of this specification are
not directly accessible to other harts or devices and cause no side effects
visible to other harts or devices. Thus, accesses to CSRs other than the
aforementioned three can be freely reordered with respect to FENCE
instructions without violating this specification.
\end{commentary}
|
