Case Studies --- The Public ISA Manuals

Every concept chapter in Part II has cited an ISA manual. The RISC-V Unprivileged and Privileged specifications [1][2], the ARM Architecture Reference Manual (ARM ARM) [3], the Intel Software Developer’s Manual (SDM) [4], and the AMD Architecture Programmer’s Manual (APM) [5] are the primary sources that define the four ISA families this book covers. These documents are freely available and collectively run to over 20,000 pages.

Reading an ISA manual for the first time is intimidating. The manuals are dense, cross-referential, and written for hardware implementers and compiler writers rather than for students. This chapter is a guided tour. It does not reproduce the manuals’ content but instead teaches the reader how to navigate them: where each manual keeps its instruction encodings, how to read the pseudocode that defines instruction semantics, where the privilege-level and exception-handling chapters are, and how the manuals organize the material that the concept chapters in this book have already introduced. The goal is to make the reader self-sufficient so that when a future chapter references “see the ARM ARM, section D1.6” the reader can find that section, read it, and extract the answer.

01.Why Read the Primary Sources?

Textbooks, including this one, simplify. A textbook presents a curated subset of the ISA, explains it in pedagogical order, and omits details that would distract from the main thread. The ISA manual is the opposite: it is complete, canonical, and exhaustive. When a textbook says “the JALR instruction clears the least-significant bit of the target address,” the manual is where that statement originates and where the exact clearing rule is defined.

Three situations send the reader to the manual. First, a homework or project requires the exact encoding of an instruction (the assembler project in Chapter 23 is a direct example). Second, the reader wants to know the behavior of an instruction or system feature that the textbook does not cover. Third, the reader is debugging a real program and needs to understand the precise semantics of a trap, an exception, or a memory-ordering guarantee.

02.The RISC-V Specifications

The RISC-V ISA is defined in two volumes published by RISC-V International [1][2]. The split mirrors the privilege boundary: the Unprivileged specification describes the instructions and registers visible to user-mode code, and the Privileged specification describes the machine-mode and supervisor-mode features that only the operating system and firmware use.

Volume I: Unprivileged Architecture

The Unprivileged specification is organized by extension. Each extension has its own chapter:

• Chapter 2 (RV32I): the base integer instruction set. This is the starting point for any RISC-V reader. It defines the 32 general-purpose registers, the PC, the six instruction formats (R, I, S, B, U, J), and the base arithmetic, logic, load/store, branch, and jump instructions.

• Chapter 7 (M extension): integer multiply and divide.

• Chapter 12 (C extension): compressed 16-bit instructions.

• Chapter 14 (V extension): the vector extension covered in Chapter 21.

• Chapter 8 (A extension): atomic instructions for multiprocessor synchronization.

• Chapters 11 and 13 (F, D extensions): single-precision and double-precision floating-point.

Each extension chapter follows a consistent structure: a rationale paragraph, the list of instructions with encoding diagrams, and a pseudocode definition of each instruction’s semantics.

How to read an encoding diagram. The RISC-V encoding diagrams are bit-field tables. The top row shows bit positions (31 down to 0 for 32-bit instructions), and the body of the table shows which bits carry the opcode, funct3, funct7, register specifiers (rd, rs1, rs2), and immediates. The six base formats (R, I, S, B, U, J) are summarized in a single figure near the start of Chapter 2. Every subsequent instruction refers back to one of these formats.

How to read the pseudocode. The RISC-V specification uses a Sail-derived notation for instruction semantics. The key conventions are: x[rd] means “the value of register rd,” M[addr] means “the memory word at address addr,” and sext() means sign-extend. The pseudocode for ADD reads roughly as x[rd] = x[rs1] + x[rs2], which is direct enough for this instruction. The pseudocode for branch and jump instructions is longer because it must describe the PC update, the immediate reconstruction, and the alignment check.

Volume II: Privileged Architecture

The Privileged specification [2] defines three privilege levels (Machine, Supervisor, User), the trap and exception mechanism, interrupt delegation, and the address translation schemes (Sv32, Sv39, Sv48, Sv57).

The chapters that matter most for this book are:

• Chapter 3 (Machine-Level ISA): defines the machine-mode CSRs (mstatus, mtvec, mcause, mepc, mie, mip), the trap entry and return mechanism (mret), and the timer and counter CSRs. This chapter is the definitive source for the material in Chapter 20.

• Chapter 4 (Supervisor-Level ISA): defines supervisor-mode CSRs, the virtual memory page table formats, and the sfence.vma instruction.

• Chapter 5 (Hypervisor Extension): defines the two-stage address translation used by hardware-assisted virtualization.

How to find a CSR. The Privileged specification lists every CSR in a master table (Table 2 in the current version) sorted by CSR address. The table gives the CSR name, address, privilege level, and a brief description. The detailed bit-field layout of each CSR appears in the chapter for its privilege level.

03.The ARM Architecture Reference Manual

The ARM Architecture Reference Manual (ARM ARM) [3] is a single document (DDI 0487) that covers both AArch32 and AArch64 execution states and all architecture extensions through ARMv9-A. At over 12,000 pages in recent revisions, it is the largest of the four manuals.

Document structure

The ARM ARM is divided into lettered parts:

• Part A: Introduction and architecture overview. Introduces the two execution states (AArch32 and AArch64), the numbered architecture extensions, and the document conventions. This is the orientation part for new readers.

• Part B: The AArch64 Application-level architecture. Defines the programmer-visible state available to user-mode code, covering the general-purpose register file, the PC, the data types, and the application-level memory model.

• Part C: The A64 instruction set. This is the primary reference for AArch64 instructions. Each instruction has its own page (or pages) with an encoding diagram, assembler syntax, pseudocode, and notes.

• Part D: The AArch64 System-level architecture. Defines exception levels (EL0–EL3), system registers, the Generic Interrupt Controller (GIC) interface, address translation, and the memory management unit. The material in Chapter 20 maps to Part D, sections D1 (Exception model) and D5 (Address translation).

• Part E: The AArch32 Application-level architecture. The 32-bit counterpart to Part B. It covers the 32-bit execution state, which is largely of historical interest for new designs.

• Part F: The AArch32 instruction sets (A32 and T32). The 32-bit counterpart to Part C.

• Part G: The AArch32 System-level architecture. The 32-bit counterpart to Part D.

• Part H: External debug architecture. Covers the debug interface, breakpoints, and watchpoints.

• Part I: SVE and SVE2 instruction set. The scalable vector extension instructions are in their own part, separate from the base A64 instructions in Part C.

How to look up an instruction. Go to Part C (for A64 instructions) or Part I (for SVE/SVE2). Instructions are listed alphabetically within each part. Each instruction page shows the encoding (a bit-field diagram with the fields color-coded by type), the assembler syntax (with all valid operand forms), and the pseudocode. The pseudocode is written in ARM’s own typed language, which uses explicit type annotations (bits(N), integer, boolean) and function calls like X[d] (read register d), Mem[addr, size, accdesc] (memory access), and AArch64.TakeException() (exception entry).

How to find a system register. Part D contains the system register descriptions, organized by functional group (exception handling, address translation, debug, performance monitors, etc.). There is also an alphabetical index of system registers. Each register page shows the bit-field layout, the access rules per exception level, and the reset value.

Navigating the extensions

ARM adds features through numbered architecture extensions (FEAT_SVE, FEAT_MTE, FEAT_PAuth, etc.). Each extension is described in a dedicated section within the relevant part of the ARM ARM. The “Feature descriptions” chapter near the front of the manual lists every extension, its one-paragraph summary, and the sections where it is defined. When this book mentions an ARM extension by name, the feature descriptions chapter is the fastest path to the detailed specification.

04.The Intel Software Developer’s Manual

The Intel 64 and IA-32 Architectures Software Developer’s Manual [4] is published as four volumes (in one combined PDF or as separate volumes):

• Volume 1: Basic Architecture. Covers the programming environment (registers, data types, addressing modes), the execution environment, and procedure calls. The material in Chapter 17, Chapter 18, and Chapter 19 maps to Volume 1.

• Volume 2: Instruction Set Reference (A–Z). This is the alphabetical instruction encyclopedia. Each instruction has a page (or pages) with the opcode encoding, operand forms, description, pseudocode (called “Operation”), flags affected, and exceptions. Volume 2 is split into 2A and 2B for printing.

• Volume 3: System Programming Guide. Covers protected mode, real mode, long mode, interrupt and exception handling, task management, memory management (segmentation and paging), and system registers. The material in Chapter 20 maps to Volume 3, Chapters 2 (System Architecture Overview), 6 (Interrupt and Exception Handling), and 4 (Paging).

• Volume 4: Model-Specific Registers. A table-format reference for every MSR, grouped by processor family.

How to read an instruction page

A typical instruction page in Volume 2 has five sections.

Opcode table. Lists every valid encoding of the instruction: the hex opcode bytes, the operand form (register, memory, immediate), the required mode (64-bit, 32-bit, legacy), and the CPUID feature flag the processor must support. For example, the ADD page lists encodings for ADD r/m8, r8, ADD r/m32, imm8, ADD RAX, imm32, and so on. The assembler project in Chapter 23 uses this table format as a model for RISC-V, which is simpler but follows the same idea.

Description. A few sentences of natural language describing what the instruction does.

Operation. Pseudocode that precisely defines the instruction’s behavior. The pseudocode uses a procedural style with IF ... THEN ... ELSE blocks, DEST, SRC, TEMP variables, and function calls like SignExtend(), ZeroExtend(), and FetchDecode().

Flags affected. Lists which bits of RFLAGS (CF, ZF, SF, OF, PF, AF) are set, cleared, or undefined after the instruction.

Exceptions. Lists the conditions under which the instruction raises a fault (invalid opcode, general protection, page fault, alignment check, etc.).

System programming chapters

Volume 3, Chapter 2 (System Architecture Overview) is the key orientation chapter. It introduces the four privilege levels (rings 0 through 3, though modern operating systems use only ring 0 and ring 3), the descriptor tables (GDT, LDT, IDT), and the control registers (CR0, CR3, CR4). The paging chapter (Chapter 4) defines the four-level and five-level page table formats used in 64-bit mode. The interrupt and exception chapter (Chapter 6) lists every architecturally defined exception (divide error, debug, breakpoint, overflow, and so on through machine check) with its vector number and error-code format.

05.The AMD Architecture Programmer’s Manual

The AMD64 Architecture Programmer’s Manual [5] covers the AMD64 extension of x86-64 in five volumes:

• Volume 1: Application Programming. Similar in scope to Intel SDM Volume 1.

• Volume 2: System Programming. Similar to Intel SDM Volume 3. Covers long mode, protected mode, interrupt handling, paging, and system registers.

• Volume 3: General-Purpose and System Instructions. The instruction reference for non-SIMD instructions.

• Volume 4: 128-Bit and 256-Bit Media Instructions. Covers SSE and AVX.

• Volume 5: 64-Bit Media and x87 Floating-Point Instructions. Covers x87 FPU and 3DNow! (legacy).

Because AMD64 and Intel 64 share the same ISA (with minor differences in extension support and system-level features), the AMD APM’s instruction-level content is largely interchangeable with the Intel SDM’s. The two manuals diverge in system-level details: AMD’s Secure Virtual Machine (SVM) extension versus Intel’s VMX (VT-x), AMD’s SEV versus Intel’s SGX/TDX, and vendor-specific MSRs.

When to use the AMD APM versus the Intel SDM

For user-mode instruction semantics (add, subtract, branch, SIMD), either manual is authoritative. For system-level features, use the manual that matches the target processor:

• Virtualization: AMD SVM is in APM Volume 2, Chapter 15. Intel VMX is in SDM Volume 3, Chapter 23.

• Confidential computing: AMD SEV/SEV-SNP is in APM Volume 2, Chapter 15 (appendix). Intel TDX has a separate specification document.

• MSRs: AMD-specific MSRs are in APM Volume 2, Appendix A. Intel-specific MSRs are in SDM Volume 4.

• Memory ordering: Both vendors define the x86-TSO memory model, but the exact wording differs slightly. For formal reasoning, the community consensus paper by Sewell et al. (“x86-TSO: A Rigorous and Usable Programmer’s Model for x86 Multiprocessors”) is the best reference, not the vendor manuals.

06.Cross-Manual Comparison: How the Four Families Organize the Same Information

Despite their different formats, all four manual families cover the same categories of information. The following table maps concepts from the book’s Part II chapters to the specific locations in the RISC-V, ARM, and Intel manuals. The AMD APM is not given a column of its own because its contents map onto the SDM through the volume correspondence listed earlier in this chapter, with APM Volume 1 holding application programming, Volume 2 holding system programming, and Volume 3 holding the general-purpose instruction reference.

The table reveals a structural difference. The RISC-V specifications place user-mode and system-mode material in separate volumes. The ARM ARM interleaves them in a single document but separates them by lettered parts. The Intel SDM splits by function (architecture overview, instruction reference, system programming, MSRs) across four volumes. All three organizations are navigable once the reader knows the high-level map.

07.Reading Strategies

Nobody reads an ISA manual front to back. The following strategies make these documents practical rather than overwhelming.

Start with the register file. Every ISA manual opens with a description of the programmer-visible state: the general-purpose registers, the program counter, the status/flags register, and (for system-level reading) the control and status registers. Reading this section first establishes the vocabulary that every subsequent instruction page uses.

Use the instruction index, not the table of contents. When looking up a specific instruction, the alphabetical instruction index (RISC-V opcode table, ARM ARM Part C alphabetical listing, Intel SDM Volume 2 alphabetical listing) is faster than the table of contents.

Read the pseudocode, not the prose. The natural-language description of an instruction is often ambiguous for corner cases (what happens on overflow? what is the behavior for a zero shift amount?). The pseudocode is the normative definition. When the prose and the pseudocode disagree, the pseudocode wins.

Pay attention to “IMPLEMENTATION DEFINED” and “UNPREDICTABLE.” These labels mark behavior that the ISA does not guarantee. Code that depends on implementation-defined behavior may work on one processor and break on another. Both ARM and RISC-V use these labels extensively. Intel uses “undefined” and “reserved.”

Check the errata. ISA manuals are written by humans and contain errors. Intel publishes a “Specification Updates” document for each processor family. ARM publishes errata lists for the ARM ARM. RISC-V tracks issues in its GitHub repository. When an instruction behaves differently from the manual, check the errata before concluding that the hardware is wrong.

08.A Walkthrough: Looking Up RISC-V JALR

To make the reading strategies concrete, here is a step-by-step walkthrough of looking up the JALR instruction in the RISC-V Unprivileged specification.

Step 1: Find the instruction. Open the specification and go to the opcode map table (Table 34 in the current version). Search for “JALR.” The table shows that JALR uses opcode 1100111 and funct3 000. It is an I-type instruction. The table points to Chapter 2 for the definition.

Step 2: Read the encoding. In Chapter 2, the JALR encoding diagram shows: imm[11:0] | rs1 | 000 | rd | 1100111. The 12-bit immediate is a signed offset added to the value of rs1. The result is the jump target address with the least-significant bit cleared (set to zero).

Step 3: Read the pseudocode. The Operation section states (paraphrased): “Let $t$ be the current PC plus 4. Set PC to $(\texttt{x[rs1]} + \text{sext}(\text{imm})) \mathbin{\&} \sim 1$. Set $\texttt{x[rd]} = t$.” The $\mathbin{\&} \sim 1$ (bitwise AND with the complement of 1) is the bit-clearing operation mentioned in the description.

Step 4: Check for exceptions. The specification states that if the computed target address is not aligned to a 4-byte boundary (or 2-byte if the C extension is present), the processor raises an instruction-address-misaligned exception.

This four-step process (find, read encoding, read pseudocode, check exceptions) works for any instruction in any of the four manuals. The specific table numbers and section letters differ, but the method is the same.

09.A Walkthrough: Looking Up ARM LDR (Immediate)

Step 1: Find the instruction. Open the ARM ARM, Part C. Instructions are alphabetical. Navigate to “LDR (immediate).” ARM distinguishes multiple forms of LDR (immediate offset, register offset, literal, pre-index, post-index), each with its own page.

Step 2: Read the encoding. The encoding diagram shows a 32-bit instruction word with fields for size (2 bits), opc (2 bits), imm12 (12 bits), Rn (5 bits), and Rt (5 bits). The immediate is a 12-bit unsigned value that is scaled by the access size (the manual calls this “scaled offset addressing”).

Step 3: Read the pseudocode. The pseudocode calls Mem[address, datasize, accdesc] to perform the memory read and X[t] to write the destination register. The address computation is $\texttt{X[n]} + \text{LSL}(\text{ZeroExtend}(\text{imm12}), \text{scale})$, where scale depends on the access size (2 for 32-bit, 3 for 64-bit).

Step 4: Check for exceptions. The pseudocode includes alignment checks and permission checks. If the address is not naturally aligned and the SCTLR_ELx.A bit is set, the processor raises an alignment fault.

10.A Walkthrough: Looking Up x86-64 MOV

Step 1: Find the instruction. Open Intel SDM Volume 2. Navigate to “MOV” in the alphabetical listing. The MOV page is one of the longest in the manual because x86 MOV has dozens of encoding variants.

Step 2: Read the opcode table. The table lists encodings such as REX.W + 89 /r (MOV r/m64, r64), REX.W + 8B /r (MOV r64, r/m64), REX.W + C7 /0 id (MOV r/m64, imm32), and so on. The same opcode bytes without the REX.W prefix give the 32-bit operand forms (MOV r/m32, r32 and so on). The “/r” notation means the ModR/M byte encodes both a register operand and a register-or-memory operand. The “/0” notation means the reg field of ModR/M is used as an opcode extension (the value 0 selects this particular MOV variant).

Step 3: Read the Operation. The Operation section is simple: DEST $\leftarrow$ SRC. The complexity of x86 MOV is in the encoding, not the semantics.

Step 4: Check flags and exceptions. Flags affected: none (MOV does not modify RFLAGS). Exceptions: the page lists general-protection fault (if a memory operand violates segment limits in protected mode) and page fault (if the page is not present or the access violates page permissions).

The x86 walkthrough illustrates a key difference from RISC-V and ARM: on x86, the encoding is the hard part. The instruction’s behavior is usually straightforward, but determining which bytes constitute the instruction and how the ModR/M and SIB bytes are interpreted requires careful study of the encoding tables in SDM Volume 2, Chapter 2 (Instruction Format).

11.Versioning, Errata, and the Living-Document Problem

Every ISA manual is a living document. The RISC-V specifications are versioned with dates (e.g., “version 20240411”) and published as PDF files with a clear version number on the title page. When RISC-V International ratifies a new extension or corrects an error in an existing extension, a new version is published and the previous version is archived.

The ARM ARM follows a lettered revision scheme (revision A through J and beyond). Each revision may add new extensions (FEAT_MTE, FEAT_SME, FEAT_GCS) and correct errors in previously defined behavior. The revision letter appears on the title page and in the document identifier (DDI 0487J for revision J). ARM also publishes individual “Architecture Extension Specifications” for extensions that are introduced between major ARM ARM revisions.

Intel and AMD update their manuals multiple times per year. The SDM carries a revision date (month and year) in the footer of every page. The AMD APM carries a publication number with a revision suffix.

The living-document nature creates a practical challenge: a section number cited in a textbook or paper may move in the next revision. When referencing a specific section, always include the document identifier and revision. When the reader encounters a discrepancy between this book and the manual, the manual version should be checked first. If the manual version is newer, the manual is likely correct and the book’s reference is outdated.

Errata. Intel publishes a “Specification Updates” document for each processor family (Alder Lake, Raptor Lake, Sapphire Rapids, etc.) that lists errata: known deviations between the processor’s actual behavior and the behavior defined in the SDM. Some errata have no workaround (the processor behaves differently from the specification in an obscure corner case that is unlikely to affect real software). Others have documented workarounds (the OS must avoid a certain instruction sequence, or the BIOS must set a specific MSR bit). AMD publishes similar errata documents. ARM publishes errata per core (Cortex-A78, Neoverse N2, etc.) rather than per specification revision.

RISC-V tracks specification issues on GitHub. Because RISC-V implementations come from many vendors, errata are per-chip rather than per-specification. The specification itself is corrected through the normal versioning process.

12.Companion Documents: ABI Specifications and Optimization Guides

The ISA manuals define what the hardware does but do not define how software should use it. That job falls to two families of companion documents.

ABI (Application Binary Interface) specifications define the calling conventions, register usage, data layout, ELF relocation types, and other rules that allow separately compiled object files to link together. The RISC-V psABI (Processor-Specific ABI) is maintained as a separate document at github.com/riscv-non-isa/riscv-elf-psabi-doc. The ARM Procedure Call Standard for the Arm 64-bit Architecture (AAPCS64) is published by ARM as a standalone document. The x86-64 System V ABI is maintained by the x86-64 psABI group. The material in Chapter 19 drew from these ABI documents, not from the ISA manuals.

When the reader encounters a question about how arguments are passed, how the stack is laid out, or what alignment a data type requires, the ABI document is the authoritative source, not the ISA manual.

Optimization guides describe the microarchitectural properties of specific processor implementations: instruction latencies, port assignments, cache sizes, branch predictor behavior, and prefetch strategies. Intel publishes the “Intel 64 and IA-32 Architectures Optimization Reference Manual” as a companion to the SDM. AMD publishes the “Software Optimization Guide” for each processor family. ARM publishes “Software Optimization Guides” for individual cores (Cortex-A78, Neoverse V2, etc.). RISC-V does not have a centralized optimization guide because RISC-V is an open ISA with many implementations, but individual implementers (SiFive, THEAD, etc.) publish their own.

These guides are not part of the ISA specification (the ISA is implementation-agnostic), but they are essential reading for anyone writing performance-critical code for a specific processor.

13.Practical Tips for Large PDFs

The ISA manuals are large PDF files (the combined Intel SDM exceeds 5000 pages). A few practical techniques make them manageable.

Use the PDF bookmarks. Every major ISA manual has a full bookmark tree in the PDF. In any PDF reader, expand the bookmark panel (usually on the left side) to navigate by chapter, section, and instruction. This is faster than scrolling.

Search for exact mnemonics. When looking up an instruction, search (Ctrl+F or Cmd+F) for the exact mnemonic in uppercase (e.g., “VADDPS” in the Intel SDM, “FADD” in the ARM ARM). The search will land on the instruction’s page. Searching for generic words like “add” produces thousands of hits.

Download the HTML versions. ARM publishes the ARM ARM as a browsable website at developer.arm.com with cross-linked sections and a search bar. The RISC-V specifications are available as GitHub-hosted PDFs with full text indexing. Intel’s SDM is also available as a browsable online reference at felixcloutier.com/x86/ (unofficial but widely used and accurate). These online versions are often more convenient than the PDF for quick lookups.

Print the opcode maps. The single most useful page in each manual is the opcode summary table: Table 34 in the RISC-V Unprivileged Spec, the Major Opcode Map in Intel SDM Volume 2 Appendix A, and the top-level encoding table in ARM ARM Part C. Print these pages (or save them as separate PDFs) and keep them at hand. They serve as the index into the rest of the manual.

Track the version. Before citing any section number, check which version of the manual you are reading. ARM revises the ARM ARM multiple times per year, and section numbers shift between revisions. Always include the document identifier and revision (e.g., “ARM ARM DDI 0487J, Part D, Section D1.6”) when referencing a specific section.

14.Worked Examples

15.Exercises

References

1. [1]Waterman, Andrew and Asanovi\'c (2024). “The RISC-V.”
2. [2]Waterman, Andrew and Asanovi\'c (2024). “The RISC-V.”
3. [3](2024). “ARM.”
4. [4](2024). “Intel.”
5. [5](2024). “AMD64.”