Explicitly allow side effects for a failed SC

Since PTE updates are specified to occur as a result of "memory
accesses" it is possible to interpret the old wording as requiring no
PTE update for a failed SC, since there is no memory access.  However,
the PTE update is part of the translation process, which on natural
implementations will occur before the reservation validity check can
occur.

This is consistent with the wording in "Addressing and Memory
Protection" which allows traps to prevent the memory access without
preventing the PTE update.

1 files changed, 5 insertions, 4 deletions

diff --git a/src/a-st-ext.adoc b/src/a-st-ext.adoc
index 396d135..9fae7ab 100644
--- a/src/a-st-ext.adoc
+++ b/src/a-st-ext.adoc
@@ -62,10 +62,11 @@ if the reservation is still valid and the reservation set contains the
 bytes being written. If the SC.W succeeds, the instruction writes the
 word in _rs2_ to memory, and it writes zero to _rd_. If the SC.W fails,
 the instruction does not write to memory, and it writes a nonzero value
-to _rd_. Regardless of success or failure, executing an SC.W instruction
-invalidates any reservation held by this hart. LR.D and SC.D act
-analogously on doublewords and are only available on RV64. For RV64,
-LR.W and SC.W sign-extend the value placed in _rd_.
+to _rd_.  For the purposes of memory protection, a failed SC.W may be
+treated like a store.  Regardless of success or failure, executing an
+SC.W instruction invalidates any reservation held by this hart. LR.D and
+SC.D act analogously on doublewords and are only available on RV64. For
+RV64, LR.W and SC.W sign-extend the value placed in _rd_.
 
 [NOTE]
 ====