Converging British English spellings to American English spellings

src/cap-description.adoc

@@ -128,8 +128,8 @@ CLEN-bits is cleared.
 
 [#c_perm,reftext="C-permission"]
 Capability Permission \(C):: Allow reading capability data from memory if the
-authorising capability also grants <<r_perm>>. Allow writing capability data to
-memory if the authorising capability also grants <<w_perm>>.
+authorizing capability also grants <<r_perm>>. Allow writing capability data to
+memory if the authorizing capability also grants <<w_perm>>.
 
 [#x_perm,reftext="X-permission"]
 Execute Permission (X):: Allow instruction execution.
@@ -140,15 +140,15 @@ If a capability grants <<r_perm>> and <<c_perm>>, but no <<lm_perm>>, then a cap
 The rules specified by <<ACPERM>> are followed when <<w_perm>> and <<lm_perm>> are removed, so additional permissions may also be removed.
 Clearing a capability's <<lm_perm>> and <<w_perm>> allows sharing a read-only version of a data structure (e.g. a tree or linked list) without making a copy.
 
-NOTE: Implementations are allowed to retain invalid capability permissions loaded from memory instead of following the <<ACPERM>> behaviour of reducing them to _no permissions_.
+NOTE: Implementations are allowed to retain invalid capability permissions loaded from memory instead of following the <<ACPERM>> behavior of reducing them to _no permissions_.
 
 [#asr_perm,reftext="ASR-permission"]
 Access System Registers Permission (ASR):: Allow read and write access to all
 privileged (M-mode and S-mode) CSRs.
-If {tid_ext_name} is supported the <<utid>>, <<utidc>>, <<stid>>, <<stidc>>, <<mtid>>,
-<<mtidc>> registers are all considered privileged for the purposes of writing
-and unprivileged for reading, and thus require ASR-permission for writes but not reads.
-In all cases a suitable privilege mode is required for access.
+If {tid_ext_name} is supported the <<utid>>, <<utidc>>, <<vstid>>, <<vstidc>>, <<stid>>,
+<<stidc>>, <<mtid>>, <<mtidc>> registers are all considered privileged for the purposes
+of writing and unprivileged for reading, and thus require ASR-permission for writes but
+not reads. In all cases a suitable privilege mode is required for access.
 
 [#cap_permissions_encoding]
 ===== Permission Encoding
@@ -295,7 +295,7 @@ references if that SDP bit is set because it "owns" that object.
 
 ifdef::cheri_v9_annotations[]
 WARNING: *CHERI v9:* There is now a 1-bit otype (sentry or unsealed) and the old CHERI v9 otype no longer exists.
-The base CHERI-RISC-V standard does not have support for CHERI v9 CSEAL for sealed capabilities with object types and only has CSEALENTRY for sealed entry (sentry) capabilities.
+The base CHERI-RISC-V standard does not have support for CHERI v9 CSEAL for sealed capabilities with object types and only has <<SENTRY>> for sealed entry (sentry) capabilities.
 endif::[]
 
 This bit indicates the type of the capability: it is a sealed capability if the bit is 1 or unsealed if it is 0.
@@ -507,7 +507,7 @@ disambiguate the location of the bounds with respect to an out-of-bounds address
 R is calculated
 relative to the base by subtracting 2^MW-2^ from B.
 If B, T or _a_[E + MW - 1:E] is less than R, it is inferred that they lie in the
-2^E+MW^ aligned region above R labelled space~U~ in
+2^E+MW^ aligned region above R labeled space~U~ in
 xref:cap_bounds_map[xrefstyle=short] and the corrections _c~t~_ and _c~b~_ are
 computed accordingly. The overall effect is that the address can roam
 2^E+MW^/4 bytes below

src/introduction.adoc

@@ -120,7 +120,7 @@ and {cheri_pte_ext_name} are optional extensions in addition to
 We refer to software as _purecap_ if it utilizes CHERI capabilities for all
 memory accesses -- including loads, stores and instruction fetches -- rather
 than integer addresses. Purecap software requires the CHERI RISC-V hart to
-support {cheri_base_ext_name}. We refer to software as _Hybrid_ if it uses
+support {cheri_base_ext_name}. We refer to software as _hybrid_ if it uses
 integer addresses *or* CHERI capabilities for memory accesses. Hybrid software
 requires the CHERI RISC-V hart to support {cheri_base_ext_name} and
 {cheri_default_ext_name}.

src/summary.adoc

@@ -1,13 +1,13 @@
 == Quick Start
 
 This document describes the RISC-V extensions for supporting CHERI capabilities in hardware.
-Capabilities can be used to provide memory safety, mitigating up to 70% of memory safety issues cite:[msrc-cheri-eval], as well as to provide efficient compartmentalisation.
+Capabilities can be used to provide memory safety, mitigating up to 70% of memory safety issues cite:[msrc-cheri-eval], as well as to provide efficient compartmentalization.
 The extensions are split into the core features required for a working capability system ({cheri_base_ext_name}), and features required to support a mix-and-match of binaries compiled for CHERI and unchanged binaries ({cheri_default_ext_name}).
 Some other smaller extensions are described that provide additional functionality relevant to CHERI.
 
 === Capability Properties
 
-Capabilities are 2*XLEN (which we call CLEN) bit structures, containing all the information required to identify and authorise access to a region of memory.
+Capabilities are 2*XLEN (which we call CLEN) bit structures, containing all the information required to identify and authorize access to a region of memory.
 This includes:
 
  * An XLEN bit address, describing where the capability currently points.
@@ -38,27 +38,27 @@ This means the following state is added:
 * Tags in registers, caches, and memory:
 
 ** Every register has a one-bit tag, indicating whether the capability in the register is valid to be dereferenced.
-  This tag is cleared if the register is written as an integer.
+   Among other reasons, this tag is cleared if the register is written as an integer.
 
 ** The tags are also tracked through the memory subsystem: every aligned CLEN-bits wide region has a non-addressable one-bit tag, which the hardware manages atomically with the data.
    The tag is cleared if the memory region is ever written other than using a capability store from a tagged capability register.
    Any caches must preserve this abstraction.
 
 === Checking Memory
 
-Every memory access performed by a CHERI core must be authorised by a capability.
+Every memory access performed by a CHERI core must be authorized by a capability.
 It is explicitly defined for every instruction where to find the capability to check against.
 In _purecap_ code, where all pointers are individual capabilities, the capability and address are used together, so e.g. `lw t0, 16(csp)` loads a word from memory, getting the address and bounds from the `csp` register.
-For code that has not yet been fully adapted to CHERI (_hybrid_ code), the processor can run in a pointer mode (not to be confused with a privilege mode) where the authorising capability is instead taken from a special CSR: the default data capability (<<ddc>>).
+For code that has not yet been fully adapted to CHERI (_hybrid_ code), the processor can run in a pointer mode (not to be confused with a privilege mode) where the authorizing capability is instead taken from a special CSR: the default data capability (<<ddc>>).
 
-Instruction fetch is also authorised by a capability: the program counter capability (<<pcc>>) which extends PC.
+Instruction fetch is also authorized by a capability: the program counter capability (<<pcc>>) which extends PC.
 This allows code fetch to be bounded, preventing a wide range of attacks that subvert control flow with integer data.
 Where {cheri_default_ext_name} is supported, the <<pcc>> also contains the <<m_bit,mode bit>> indicating whether the processor is running in integer or capability pointer mode.
 Changing the bounds used for instruction fetch or the pointer mode can be as easy as performing a capability-based jump (<<JALR>> in capability pointer mode).
 <<MODESW_CAP>> and <<MODESW_INT>> instructions are also added to allow cheap mode switching.
 
 Exception codes are added for CHERI-specific exceptions on fetch, jumps, and memory access.
-No other exception paths are added: in particular, capability manipulations do not trap, but may clear the tag on the result capability if the operation is not permitted.
+No other exception paths are added: In particular, capability manipulations do not trap, but may clear the tag on the result capability if the operation is not permitted.
 
 === Added Instructions
 
@@ -76,7 +76,7 @@ The added instructions can be split into the following categories:
 
 === Existing Instructions
 
-Existing RISC-V instructions are largely unmodified: in {cheri_int_mode_name}, there is binary compatibility.
+Existing RISC-V instructions are largely unmodified: In {cheri_int_mode_name}, there is binary compatibility.
 Instructions that access memory, as well as branches and jumps, are automatically checked against <<ddc>> and <<pcc>>, raising an exception if the checks fail.
 However, <<ddc>> and <<pcc>> are reset to <<infinite-cap>> capabilities, meaning the checks will always pass on systems that have not written to CHERI system registers.