Purge some references to offsetting throughout (#86)

Prefer "DDC-constrained" to "DDC-relative" throughout
to minimise confusion

app-isaquick-riscv.tex

@@ -192,13 +192,13 @@ \chapter{CHERI-RISC-V ISA Quick Reference}
 \optype{Memory Loads with Explicit Address Type}
 
 These memory load instructions explicitly expect either capability addresses
-or integer offsets to \DDC{}, with bounds coming either from cs1 or \DDC{}
+or integer addresses, with bounds coming either from cs1 or \DDC{}
 respectively. For non-reserved loads, the encoding of bits 24 to 20 tries to
 follow the standard RISC-V mapping for the width and signedness of the memory
 access:
 \begin{description}
 \item [bit 24] 0 to indicate non-reserved load.
-\item [bit 23] When 0, the load is DDC relative. Explicit capability is provided otherwise.
+\item [bit 23] When 0, the load is DDC constrained. Explicit capability is provided otherwise.
 \item [bit 22] When 0, the result of the load is sign-extended, and zero-extended otherwise.
 \item [bit 21-20] 00 loads a byte, 01 loads a half-word, 10 loads a word, 11 loads a double-word.
 \end{description}
@@ -208,7 +208,7 @@ \chapter{CHERI-RISC-V ISA Quick Reference}
 access:
 \begin{description}
 \item [bit 24] 1 to indicate LR version of the load.
-\item [bit 23] When 0, the load is DDC relative. Explicit capability is provided otherwise.
+\item [bit 23] When 0, the load is DDC constrained. Explicit capability is provided otherwise.
 \item [bit 22-20] 000 loads a byte, 001 loads a half-word, 010 loads a word, 011 loads a double-word, 100 loads a quad-word/capability.
 \end{description}
 
@@ -297,12 +297,12 @@ \chapter{CHERI-RISC-V ISA Quick Reference}
 \optype{Memory Stores with Explicit Address Type}
 
 These memory store instructions explicitly expect either capability addresses
-or integer offsets to \DDC{}, with bounds coming either from cs1 or \DDC{}
+or integer addresses, with bounds coming either from cs1 or \DDC{}
 respectively. The encoding of bits 11 to 7 tries to follow the standard RISC-V
 mapping for the width of the memory access:
 \begin{description}
 \item [bit 11] When 1 with the A extension, SC version of the store.
-\item [bit 10] When 0, the store is DDC relative. Explicit capability is provided otherwise.
+\item [bit 10] When 0, the store is DDC constrained. Explicit capability is provided otherwise.
 \item [bit 9-7] 000 stores a byte, 001 stores a half-word, 010 stores a word, 011 stores a double-word, 100 stores a quad-word/capability.
 \end{description}
 

chap-architecture.tex

@@ -769,7 +769,7 @@ \subsection{General-Purpose Capability Registers}
 input register does not contain a valid tag.
 If an integer dereference is to be performed, only the integer portion of the
 capability register will be used (per above, the virtual address of the
-capability), and it will be indirected through an appropriate implied
+capability), and it will be checked using an appropriate implied
 capability such as the Program-Counter Capability (\PCC{}) or Default Data
 Capability (\DDC{}).
 
@@ -834,7 +834,7 @@ \subsection{Special Capability Registers}
   Counter (\PC{}) to be a full capability, imposing validity, permission,
   bounds, and other checks on instruction fetch.
 
-\item[Default Data Capability (\DDC{})] indirects legacy non-capability loads
+\item[Default Data Capability (\DDC{})] constrains legacy non-capability loads
   and stores, controlling data accesses to memory.
 \end{description}
 
@@ -1726,7 +1726,7 @@ \section{Capability-Aware Instructions}
 \insnref{CTestSubset}.
 
 \item[Load or store via a capability]
-These instructions access memory indirected via an explicitly named capability
+These instructions access memory via an explicitly named capability
 register, and will ideally correspond to a full range of contemporary
 indexing modes present in the baseline ISA -- for example, allowing aligned or
 unaligned access to zero-extended and sign-extended integers of varying

chap-cheri-riscv.tex

@@ -117,8 +117,8 @@ \subsection{Common Architectural Features}
 \begin{itemize}
 \item Tagged memory with capability-width tag granularity and alignment.
 \item Registers able to hold capabilities are tagged.
-\item \PCC{} controls program-counter-relative fetches.
-\item \DDC{} controls legacy RISC-V load-store instructions.
+\item \PCC{} constrains program-counter-relative fetches.
+\item \DDC{} constrains legacy RISC-V load-store instructions.
 \item Floating point is fully supported, including capability-relative
   floating-point load and store instructions.
 \item General-purpose registers are extended to hold capabilities.
@@ -557,7 +557,7 @@ \subsection{Capability Encoding Mode}
 (e.g.\ loads, stores, jumps, \insnnoref{AUIPC}) can either act on integer pointers
 or on explicit capabilities.
 For example, capability-relative load and store instructions accept (and expect) capability
-operands that relocate and constrain data accesses, performing tag, bounds,
+operands that constrain data accesses, performing tag, bounds,
 permission, and other checks as required.
 However, load and store instructions occupy large amounts of instruction
 encoding space due to having multiple register operands and large immediate

chap-intro.tex

@@ -260,7 +260,7 @@ \section{CHERI Design Goals}
 integers in the instruction-level descriptions of loads and stores, once
 checks are performed capabilities are largely reduced to integer addresses
 for processing by the MMU and memory subsystem.
-Compilers must use capability-relative loads and stores for capability-aware
+Compilers must use capability-constrained loads and stores for capability-aware
 code, but the structure (and often format) of those instructions remain the
 same, and although code is generated to use capabilities rather than integers
 for pointers, the vast majority of source code remains the same.
@@ -377,7 +377,7 @@ \subsection{The Architecture-Neutral CHERI Protection Model}
 through valid capability transformations.
 
 In order to continue to support non-CHERI-aware code, dereference of integer
-virtual addresses via legacy instruction is transparently indirected via a
+virtual addresses via legacy instruction is transparently checked via a
 \textit{default data capability} (\DDC{}) for loads and stores, or a
 \textit{program-counter capability} (\PCC{}) for instruction fetch.
 

chap-model.tex

@@ -935,19 +935,17 @@ \subsection{Hybridization with Integer Pointers}
 pointers, using two special capability registers:
 
 \begin{description}
-\item[Default Data Capability (DDC)] DDC indirects and controls legacy
-  instructions that load and store relative to integer addresses rather than
-  capabilities.
+\item[Default Data Capability (DDC)] DDC constrains legacy instructions that
+  load and store relative to integer addresses rather than capabilities.
 
 \item[Program Counter Capability (PCC)] PCC extends the conventional program
-  counter with capability metadata, indirecting and controlling instruction
-  fetches.
+  counter with capability metadata, constraining instruction fetches.
 \end{description}
 
 Programs compiled to use capabilities to represent pointers (whether
 implicitly or via explicit program annotations) will not use the default data
 capability, instead employing capability registers and capability-based
-instructions for pointer operations and indirection.
+instructions for pointer operations.
 The program-counter capability will be used regardless of the code model
 employed, although capability-aware code generation will employ constrained
 program-counter bounds and permissions to implement control-flow robustness

chap-rationale.tex

@@ -1122,7 +1122,7 @@ \section{Capability Encoding Mode}
 space to provide capability-relative variations on load and store
 instructions.
 This approach ensures intentionality: the architecture is always able to
-perform a \DDC{}-relative access with legacy integer-relative load and store
+perform a \DDC{}-constrained access with legacy integer-relative load and store
 instructions, and is always able to assert that the tag bit is set for
 capability-relative load and store instructions.
 However, this makes heavy use of remaining unused opcode space in many
@@ -1135,7 +1135,7 @@ \section{Capability Encoding Mode}
 capability-relative loads and stores are added.
 To get access to the full range of load and store variations, the encoding
 mode can be switched to one in which existing load and store opcodes are
-instead interpreted as requiring capability operands, and \DDC{}-relative
+instead interpreted as requiring capability operands, and \DDC{}-constrained
 integer-based access is disabled.
 
 There are a variety of mechanisms that could be used to switch between

glossary.tex

@@ -832,18 +832,14 @@
   description={An integer \gls{address} translated by the Memory Management
     Unit (MMU) into a \gls{physical address} for the purposes of load, store,
     and instruction fetch.
-    \Glspl{capability} embed an address, represented in the instruction
-    set as the sum of the \gls{capability base} and \gls{capability offset},
-    as well as \gls{capability bounds} relative to the address.
+    \Glspl{capability} embed an address, as well as \gls{capability bounds}
+    relative to the address.
     The integer addresses passed to \glslink{legacy instructions}{legacy load
-    and store instructions} that would previously have been interpreted as
-    virtual addresses are, with CHERI, transformed (and checked) using the
-    \gls{default data capability}.
+    and store instructions} are checked with CHERI using the
+    \gls{default data capability}. The interpretation -- physical or virtual
+    addresses -- is not changed by CHERI.
     Similarly, the integer addresses passed to legacy branch and jump
-    instructions are transformed (and checked) using the \gls{program-counter
-    capability}.
-    This in effect introduces a further relocation of legacy addresses prior
-    to virtual address translation}
+    instructions are checked using the \gls{program-counter capability}}
 }
 
 \newglossaryentry{vulnerability mitigation}