[Vendorized spec] Add ASCIIdoc inline anchors matching impl-def@1853796c. (#2002)

vendor/riscv/riscv-isa-manual/src/priv-csrs.adoc

@@ -9,10 +9,10 @@ instructions. The privileged architecture requires the Zicsr extension;
 which other privileged instructions are required depends on the
 privileged-architecture feature set.
 
-In addition to the unprivileged state described in Volume I of this
+[#spec_vol2_0210]#In addition to the unprivileged state described in Volume I of this
 manual, an implementation may contain additional CSRs, accessible by
 some subset of the privilege levels using the CSR instructions described
-in Volume I. In this chapter, we map out the CSR address space. The
+in Volume I.# In this chapter, we map out the CSR address space. The
 following chapters describe the function of each of the CSRs according
 to privilege level, as well as the other privileged instructions which
 are generally closely associated with a particular privilege level. Note
@@ -36,9 +36,9 @@ encode default access privileges. This simplifies error checking in the
 hardware and provides a larger CSR space, but does constrain the mapping
 of CSRs into the address space.
 
-Implementations might allow a more-privileged level to trap otherwise
+[#spec_vol2_0220]#Implementations might allow a more-privileged level to trap otherwise
 permitted CSR accesses by a less-privileged level to allow these
-accesses to be intercepted. This change should be transparent to the
+accesses to be intercepted.# This change should be transparent to the
 less-privileged software.
 ====
 
@@ -56,8 +56,8 @@ standard extensions.
 Machine-mode standard read-write CSRs `0x7A0`-`0x7BF` are reserved for
 use by the debug system. Of these CSRs, `0x7A0`-`0x7AF` are accessible
 to machine mode, whereas `0x7B0`-`0x7BF` are only visible to debug mode.
-Implementations should raise illegal-instruction exceptions on
-machine-mode access to the latter set of registers.
+[#spec_vol2_0230]#Implementations should raise illegal-instruction exceptions on
+machine-mode access to the latter set of registers.#
 
 [NOTE]
 ====
@@ -76,7 +76,7 @@ illegal accesses. Currently, the counters are the only shadowed CSRs.
 have currently been allocated CSR addresses. The timers, counters, and
 floating-point CSRs are standard unprivileged CSRs. The other registers
 are used by privileged code, as described in the following chapters.
-Note that not all registers are required on all implementations.
+[#spec_vol2_0240]#Note that not all registers are required on all implementations.#
 
 [[csrrwpriv]]
 .Allocation of RISC-V CSR address ranges.
@@ -577,8 +577,8 @@ MRO
 `mconfigptr`
 |Vendor ID. +
 Architecture ID. +
-Implementation ID. +
-Hardware thread ID. +
+[#spec_vol2_0250]#Implementation ID. +
+#Hardware thread ID. +
 Pointer to configuration data structure.
 
 4+^|Machine Trap Setup
@@ -869,8 +869,8 @@ behavior of fields within the CSRs.
 Some whole read/write fields are reserved for future use. Software
 should ignore the values read from these fields, and should preserve the
 values held in these fields when writing values to other fields of the
-same register. For forward compatibility, implementations that do not
-furnish these fields must make them read-only zero. These fields are
+same register. [#spec_vol2_0260]#For forward compatibility, implementations that do not
+furnish these fields must make them read-only zero.# These fields are
 labeled *WPRI* in the register descriptions.
 
 [NOTE]
@@ -896,17 +896,17 @@ are labeled *WLRL* in the register descriptions.
 
 [NOTE]
 ====
-Hardware implementations need only implement enough state bits to
+[#spec_vol2_0270]#Hardware implementations need only implement enough state bits to
 differentiate between the supported values, but must always return the
-complete specified bit-encoding of any supported value when read.
+complete specified bit-encoding of any supported value when read.#
 ====
 
-Implementations are permitted but not required to raise an
+[#spec_vol2_0280]#Implementations are permitted but not required to raise an
 illegal-instruction exception if an instruction attempts to write a
-non-supported value to a *WLRL* field. Implementations can return arbitrary
+non-supported value to a *WLRL* field.# [#spec_vol2_0290]#Implementations can return arbitrary
 bit patterns on the read of a *WLRL* field when the last write was of an
 illegal value, but the value returned should deterministically depend on
-the illegal written value and the value of the field prior to the write.
+the illegal written value and the value of the field prior to the write.#
 
 ==== Write Any Values, Reads Legal Values (WARL)
 
@@ -917,11 +917,11 @@ other side effects, the range of supported values can be determined by
 attempting to write a desired setting then reading to see if the value
 was retained. These fields are labeled *WARL* in the register descriptions.
 
-Implementations will not raise an exception on writes of unsupported
-values to a *WARL* field. Implementations can return any legal value on the
+[#spec_vol2_0300]#Implementations will not raise an exception on writes of unsupported
+values to a *WARL* field.# [#spec_vol2_0310]#Implementations can return any legal value on the
 read of a *WARL* field when the last write was of an illegal value, but the
 legal value returned should deterministically depend on the illegal
-written value and the architectural state of the hart.
+written value and the architectural state of the hart.#
 
 === CSR Field Modulation
 
@@ -951,7 +951,7 @@ that CSR.
 
 === Implicit Reads of CSRs
 
-Implementations sometimes perform _implicit_ reads of CSRs. (For
+[#spec_vol2_0320]#Implementations sometimes perform _implicit_ reads of CSRs.# (For
 example, all S-mode instruction fetches implicitly read the `satp` CSR.)
 Unless otherwise specified, the value returned by an implicit read of a
 CSR is the same value that would have been returned by an explicit read

vendor/riscv/riscv-isa-manual/src/priv-intro.adoc

@@ -36,20 +36,20 @@ shows a simple system that supports only a single application running on
 an application execution environment (AEE). The application is coded to
 run with a particular application binary interface (ABI). The ABI
 includes the supported user-level ISA plus a set of ABI calls to
-interact with the AEE. The ABI hides details of the AEE from the
-application to allow greater flexibility in implementing the AEE. The
+interact with the AEE. [#spec_vol2_0070]#The ABI hides details of the AEE from the
+application to allow greater flexibility in implementing the AEE.# [#spec_vol2_0080]#The
 same ABI could be implemented natively on multiple different host OSs,
 or could be supported by a user-mode emulation environment running on a
-machine with a different native ISA.
+machine with a different native ISA.#
 
 [NOTE]
 ====
-Our graphical convention represents abstract interfaces using black
+[#spec_vol2_0090]#Our graphical convention represents abstract interfaces using black
 boxes with white text, to separate them from concrete instances of
-components implementing the interfaces.
+components implementing the interfaces.#
 ====
 [[privimps]]
-.Different implementation stacks supporting various forms of privileged execution.
+[#spec_vol2_0100]#.Different implementation stacks supporting various forms of privileged execution.#
 image::png/privimps.png[]
 
 The middle configuration shows a conventional operating system (OS) that
@@ -59,8 +59,8 @@ AEE. Just as applications interface with an AEE via an ABI, RISC-V
 operating systems interface with a supervisor execution environment
 (SEE) via a supervisor binary interface (SBI). An SBI comprises the
 user-level and supervisor-level ISA together with a set of SBI function
-calls. Using a single SBI across all SEE implementations allows a single
-OS binary image to run on any SEE. The SEE can be a simple boot loader
+calls. [#spec_vol2_0110]#Using a single SBI across all SEE implementations allows a single
+OS binary image to run on any SEE.# The SEE can be a simple boot loader
 and BIOS-style IO system in a low-end hardware platform, or a
 hypervisor-provided virtual machine in a high-end server, or a thin
 translation layer over a host operating system in an architecture
@@ -86,9 +86,9 @@ prioritizing support for Type-2 hypervisors where the SBI is provided
 recursively by an S-mode OS.
 ====
 
-Hardware implementations of the RISC-V ISA will generally require
+[#spec_vol2_0120]#Hardware implementations of the RISC-V ISA will generally require
 additional features beyond the privileged ISA to support the various
-execution environments (AEE, SEE, or HEE).
+execution environments (AEE, SEE, or HEE).#
 
 === Privilege Levels
 
@@ -141,9 +141,9 @@ OS in user mode, all supervisor-level actions will be trapped and
 emulated by the SEE running in the higher-privilege level.
 ====
 The machine level has the highest privileges and is the only mandatory
-privilege level for a RISC-V hardware platform. Code run in machine-mode
+privilege level for a RISC-V hardware platform. [#spec_vol2_0130]#Code run in machine-mode
 (M-mode) is usually inherently trusted, as it has low-level access to
-the machine implementation. M-mode can be used to manage secure
+the machine implementation.# M-mode can be used to manage secure
 execution environments on RISC-V. User-mode (U-mode) and supervisor-mode
 (S-mode) are intended for conventional application and operating system
 usage respectively.
@@ -154,9 +154,9 @@ optional standard extension for memory protection. Also, supervisor mode
 can be extended to support Type-2 hypervisor execution as described in
 <<hypervisor>>.
 
-Implementations might provide anywhere from 1 to 3 privilege modes
+[#spec_vol2_0140]#Implementations might provide anywhere from 1 to 3 privilege modes
 trading off reduced isolation for lower implementation cost, as shown in
-<<privcombs>>.
+<<privcombs>>#.
 
 [[privcombs]]
 .Supported combination of privilege modes.
@@ -174,18 +174,18 @@ Secure embedded systems +
 Systems running Unix-like operating systems
 |===
 
-All hardware implementations must provide M-mode, as this is the only
-mode that has unfettered access to the whole machine. The simplest
+[#spec_vol2_0150]#All hardware implementations must provide M-mode, as this is the only
+mode that has unfettered access to the whole machine.# [#spec_vol2_0160]#The simplest
 RISC-V implementations may provide only M-mode, though this will provide
-no protection against incorrect or malicious application code.
+no protection against incorrect or malicious application code.#
 
 [NOTE]
 ====
-The lock feature of the optional PMP facility can provide some limited
-protection even with only M-mode implemented.
+[#spec_vol2_0170]#The lock feature of the optional PMP facility can provide some limited
+protection even with only M-mode implemented.#
 ====
-Many RISC-V implementations will also support at least user mode
-(U-mode) to protect the rest of the system from application code.
+[#spec_vol2_0180]#Many RISC-V implementations will also support at least user mode
+(U-mode) to protect the rest of the system from application code.#
 Supervisor mode (S-mode) can be added to provide isolation between a
 supervisor-level operating system and the SEE.
 
@@ -201,14 +201,14 @@ layers.
 
 [NOTE]
 ====
-Horizontal traps can be implemented as vertical traps that return
-control to a horizontal trap handler in the less-privileged mode.
+[#spec_vol2_0190]#Horizontal traps can be implemented as vertical traps that return
+control to a horizontal trap handler in the less-privileged mode.#
 ====
 
 === Debug Mode
 
-Implementations may also include a debug mode to support off-chip
-debugging and/or manufacturing test. Debug mode (D-mode) can be
+[#spec_vol2_0200]#Implementations may also include a debug mode to support off-chip
+debugging and/or manufacturing test.# Debug mode (D-mode) can be
 considered an additional privilege mode, with even more access than
 M-mode. The separate debug specification proposal describes operation of
 a RISC-V hart in debug mode. Debug mode reserves a few CSR addresses

vendor/riscv/riscv-isa-manual/src/priv-preface.adoc

@@ -34,8 +34,8 @@ _Draft_ +
 The following compatible changes have been made to the Machine ISA since
 version 1.12:
 
-* Defined the `misa`.V field to reflect that the V extension has been
-implemented.
+[#spec_vol2_0010]#* Defined the `misa`.V field to reflect that the V extension has been
+implemented.#
 * Clarified semantics of explicit accesses to CSRs wider than XLEN bits.
 * Clarified that MXLEN≥SXLEN, and added the constraint that
 SXLEN≥UXLEN.
@@ -77,15 +77,15 @@ portability problems in practice:
 
 * Changed MRET and SRET to clear `mstatus`.MPRV when leaving M-mode.
 * Reserved additional `satp` patterns for future use.
-* Stated that the `scause` Exception Code field must implement bits 4–0
-at minimum.
+[#spec_vol2_0020]#* Stated that the `scause` Exception Code field must implement bits 4–0
+at minimum.#
 * Relaxed I/O regions have been specified to follow RVWMO. The previous
 specification implied that PPO rules other than fences and
 acquire/release annotations did not apply.
 * Constrained the LR/SC reservation set size and shape when using
 page-based virtual memory.
-* PMP changes require an SFENCE.VMA on any hart that implements
-page-based virtual memory, even if VM is not currently enabled.
+[#spec_vol2_0030]#* PMP changes require an SFENCE.VMA on any hart that implements
+page-based virtual memory, even if VM is not currently enabled.#
 * Allowed for speculative updates of page table entry A bits.
 * Clarify that if the address-translation algorithm non-speculatively
 reaches a PTE in which a bit reserved for future standard use is set, a
@@ -107,13 +107,13 @@ of the execution environment.
 * Designated part of SYSTEM major opcode for custom use.
 * Permitted the unconditional delegation of less-privileged interrupts.
 * Added optional big-endian and bi-endian support.
-* Made priority of load/store/AMO address-misaligned exceptions
+[#spec_vol2_0040]#* Made priority of load/store/AMO address-misaligned exceptions
 implementation-defined relative to load/store/AMO page-fault and
-access-fault exceptions.
+access-fault exceptions.#
 * PMP reset values are now platform-defined.
 * An additional 48 optional PMP registers have been defined.
-* Slightly relaxed the atomicity requirement for A and D bit updates
-performed by the implementation.
+[#spec_vol2_0050]#* Slightly relaxed the atomicity requirement for A and D bit updates
+performed by the implementation.#
 * Clarify the architectural behavior of address-translation caches
 * Added Sv57 and Sv57x4 address translation modes.
 * Software breakpoint exceptions are permitted to write either 0 or the
@@ -234,9 +234,9 @@ SFENCE.VMA instruction.
 * The `mstatus` bit MXR has been exposed to S-mode via `sstatus`.
 * The polarity of the PUM bit in `sstatus` has been inverted to shorten
 code sequences involving MXR. The bit has been renamed to SUM.
-* Hardware management of page-table entry Accessed and Dirty bits has
+[#spec_vol2_0060]#* Hardware management of page-table entry Accessed and Dirty bits has
 been made optional; simpler implementations may trap to software to set
-them.
+them.#
 * The counter-enable scheme has changed, so that S-mode can control
 availability of counters to U-mode.
 * H-mode has been removed, as we are focusing on recursive