From 7d481681149b2e40955d1c6362f97465d439d426 Mon Sep 17 00:00:00 2001 From: Tim Hutt Date: Tue, 6 Aug 2024 12:31:56 +0100 Subject: [PATCH] Specify the interaction between CSRRS/C and "reads as" bits `pmpaddr` uniquely contains writable bits that "read as" some value, but have an underlying value that can be different. The behaviour when you modify *different* bits in the CSR using `csrr{sc}[i]` was not clear. This is the behaviour that the Sail model, SPIKE and the open-source Rocket core all implement. --- src/zicsr.adoc | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/src/zicsr.adoc b/src/zicsr.adoc index 8d3db68a7..2e5378feb 100644 --- a/src/zicsr.adoc +++ b/src/zicsr.adoc @@ -47,6 +47,16 @@ treated as a bit mask that specifies bit positions to be cleared in the CSR. Any bit that is high in _rs1_ will cause the corresponding bit to be cleared in the CSR, if that CSR bit is writable. +[NOTE] +==== +Since CSRRS and CSRRC perform a read-modify-write, any bits that read as +a different value to their underlying value may be modified by these +instructions even if the corresponding bit is not set in _rs1_. For example +pmpaddr[G-1] may have an underlying value of 1 but read as 0. Executing +CSRRC or CSRRS to modify a different bit will cause 0 to be read from +pmpaddr[G-1] and then written back, updating the underlying value to 0. +==== + For both CSRRS and CSRRC, if _rs1_=`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, nor raise illegal-instruction