标签: csapp - ouuan's blog

CS:APP 第九章学习笔记

Mon, 26 Dec 2022 06:44:19 GMT

CS:APP 第九章 “Virtual Memory” 的学习笔记。

本章的主要内容为 page table、address translation、memory mapping、dynamic allocation。

虚存是对 main memory 的抽象，它的主要作用有：

将 main memory 用作 disk 的 cache，只将 active 的部分放在 main memory，在需要时在 disk 和 memory 之间传递数据
通过给应用程序提供统一的地址空间，简化内存管理
通过给不同进程提供独立的地址空间，防止一个进程的数据被其他进程破坏

虚存在系统中起着非常重要的作用，学习虚存一方面可以学会使用它的一些强大功能（例如将文件映射到内存中），另一方面可以避免一些内存管理相关的错误。

Physical and Virtual Addressing

内存有两种寻址方式：物理寻址和虚拟寻址。

main memory 可以看作 $M$ 个 byte 排列在一起，地址分别为 $0 \sim M-1$ ，物理寻址就是 CPU 直接将需要的地址传给 main memory，获取到数据后传回 CPU。

虚拟寻址需要硬件和操作系统配合，CPU 将虚拟地址传给 memory management unit (MMU)，MMU 将虚拟地址翻译成物理地址传给 main memory，而这个过程又和操作系统相关。

Address Spaces

（线性）地址空间是连续的非负整数构成的集合，一个系统有一个物理地址空间 $[0, M-1]$ ，还有若干个虚拟地址空间 $[0, N-1]$ ，其中 $N = 2^n$ ，称作 $n$ -bit 地址空间，一般是 32-bit 或者 64-bit。

同一份数据可以在不同的地址空间有不同的地址，是虚存的一个基本思想。

VM as a Tool for Caching

可以说，虚存是存储在磁盘上的，而物理内存是虚存的 cache。（但实际上虚存在很多时候会只出现在这个 cache 里而只在必要时被写入到磁盘上。）

page table

在物理内存中存放着一张 page table，虚拟地址空间中的每个 page 都对应 page table 中的一项 (page table entry, PTE)。每一项包含一个 valid bit 和一个地址：

cached: valid bit set，地址为该 page 的缓存的物理地址
uncached: valid bit not set，地址指向磁盘上的 virtual page
unallocated: valid bit not set，地址为 null

page fault

在地址翻译时，MMU 会查看传入的虚拟地址对应的 PTE，若 cached，则称作 page hit，就会将 PTE 存储的物理地址传给 main memory；否则，就是 cache miss，在虚存中被称作 page fault。

page fault 是一个 exception，会触发 kernel 中的 page fault handler。page fault handler 会在 physical memory 中选择一个 physical page（victim page）用来存这个触发 page fault 的 page，先将 victim page 原有的数据在必要时放回磁盘，然后将新的数据存入 victim page，再相应地修改 page table 中的这两个 PTE，使得 victim page 原来存的那个 virtual page 变为 uncached，而新存入的 virtual page 变为 cached 并且地址指向 victim page。page fault handler 的最终效果就是，一开始想要的 virtual page 已经 cached，于是在返回到 exception 触发的位置时就可以 page hit 而正常读取数据了。

在磁盘和内存间传递数据在虚存中被称作 swapping 或 paging：

Pages are swapped in (paged in) from disk to DRAM, and swapped out (paged out) from DRAM to disk.

虚存的 cache miss 是非常昂贵的，但由于程序访问内存的 locality，一般来说 page fault 很少触发，效率就不会太差。不断触发 page fault 的情况称作 thrashing，会大大影响程序的效率。

VM as a Tool for Memory Management

实际上，page table 在一个系统中并非只有一份，而是每个进程都有一份，并且可以把同一个 physical page 映射到不同进程中的多个 virtual page。

虚存为内存管理提供了如下的便利：

简化了 linking，使得链接时无需考虑具体的物理地址，不同程序可以使用同样的虚拟地址分配方案。
简化了 loading，使得加载程序时只需将可执行文件的段落映射到虚存中，不用拷贝数据，等访问到某个 page 时才会 page in。这样的将文件内容映射到虚存中的操作称作 memory mapping，Linux 提供了 mmap system call 来进行 memory mapping。
简化了内存共享，操作系统可以将进程私有的数据映射到不同的 physical page，而将共享的数据映射到相同的 physical page。
简化了内存分配，因为应用请求一段连续的 virtual pages 时，操作系统可以将其映射到不连续的 physical pages。

VM as a Tool for Memory Protection

虚存可以轻松地给不同的进程提供不同的私有内存空间。
通过给 PTE 添加 permission bit SUP、READ、WRITE，就可以使某个 page 只读或者只能在 kernel mode 下被访问。如果试图访问一个 page 时权限出错，则会触发 CPU 的 general protection exception，进而由 exception handler 向进程发送 SIGSEGV。

Address Translation

一个内存地址可以被分为两部分，虚拟地址被分为高位的 virtual page number (VPN) 和低位的 virtual page offset (VPO)，物理地址被分为 PPN 和 PPO。

CPU 中有一个 page table base register (PTBR)，指向 page table 的起始地址。地址翻译时，MMU 通过 PTBR 和 VPN 得到 PTE 的地址，从 main memory 获取 PTE，根据 valid bit，要么触发 page fault，要么获取到 PPN，而 PPO = VPO，就得到了物理地址。

SRAM cache 一般会以物理地址来 cache main memory，也就是说，通过 PTE 的地址访问 PTE、通过物理地址访问 main memory 时会首先尝试通过 SRAM cache 来访问。

如果每次都从 main memory 获取 PTE，即使在 L1 cache hit 了效率也不够高，所以 MMU 中还有一个小的 page table cache，叫做 translation lookaside buffer (TLB)。VPN 被分为两部分：低位的 TLBI (index) 和高位的 TLBT (tag)，其中 TLBI 用来选择 cache set，TLBT 用来进行 cache line matching。在地址翻译时，会优先查询 TLB，若 miss 再查询 page table。

地址空间往往很大，如果只用一张 page table，那么 page table 本身就会占用大量的空间，所以可以将 page table 分层，每层 page table 指向下一层 page table，直到最后一层指向 VP / PP。

Case Study: Core i7 Address Translation

Core i7 memory system 如 CS:APP Figure 9.21 所示：

Core i7 使用 48-bit 的虚拟地址空间和 52-bit 的物理地址空间，page size 可以设置为 4KB 或 4MB，有四级 page table。

每个 PTE 有以下内容：（还有一些其他内容）

P: valid bit
R/W: 是否只读
U/S: 是否需要在 kernel mode 下访问
XD: 是否可以被读取指令（是否可执行）
A: reference bit，访问到时由 MMU 设置，而由软件清除（可以用于 replacement algorithm）
Base addr: child page table / physical page 的地址的高位 40 bits（剩下 12 bits 即 4KB，这要求地址以 4KB 对齐，而 page size 一般就是 4KB）

L1 page table 还有一项 PS 用来指定 page size。

L4 page table 还有 dirty bit D 用来表示 page 被写入过需要被 swap out (write back)，以及 G 表示 global page 即切换进程时不从 TLB 中 evict 掉。

VPN 有 36 bits，每 9 bits 用来访问一级 page table。

因为 L1 cache 是 8-way 32KB 的，正好有 12 bits 用来选择 cache set，所以在获取 PPN 的同时就可以把 VPO 发送给 L1 cache 来提前选择好 cache set。

Linux Virtual Memory System

kernel 的虚存中包含：

kernel 的代码以及全局的数据结构
将整个物理内存连续地映射到虚存中，这样就可以方便地访问特定的物理地址
和每个进程相关的数据结构，例如 page table、kernel stack、task_struct 等

（P.S. 这部分虽然是和每个进程相关，但并不会在每个进程中有所不同，CS:APP 中这里写错了，在 errata 中指出了）

Linux 将虚存划分为若干 area（也称 segment）来管理，例如 code segment、data segment、heap、shared library segment，每个 area 是虚存中连续的一段。

kernel 为每个进程维护了一个 task_struct，其中的 mm 一项是一个 mm_struct。mm_struct 的 pgd 一项是 L1 page table 的地址，而 mmap 指向一个 vm_area_struct。每个 vm_area_struct 表示一个 area，有以下几项（还有一些其他项）：

vm_start / vm_end: 指向 area 的开头 / 结尾
vm_page_prot: area 中所有 page 的 access permission
vm_flags: 一些 flag，例如这个 area 中的 page 是否被所有进程共享
vm_prev / vm_next: 指向相邻的 vm_area_struct，构成一个链表

在处理 page fault 时，page fault handler 首先会检查地址是否在某个 area 内（不在则触发 segmentation fault），然后会检查是否有访问权限（没有则触发 protection exception），如果一切 ok 就会根据 replacement algorithm 选择 victim page，若其 dirty 则将其 swap out，然后将新的 page swap in，最后更新 page table 并返回。

Memory Mapping

将一个 object 的内容设为一段虚存的初始值称作 memory mapping。这个 object 可以是文件系统中一个文件的一段 (file-backed)，也可以是一个初始为空的 anonymous file (demand-zero)。

在 map 时并不会立即将数据放到物理内存中，而是等到访问到某个 page 时再 swap in，这称作 demand paging。操作系统会使用 swap file 来进行 swapping，但只有进行了修改才会需要 swap out，否则可以直接从 map 到的文件 swap in。

如果不同的进程映射到了同一个文件的同一段，在物理内存中会只有一份数据。

memory mapping 有 shared 和 private 两种：

map as shared objects: 修改对其他进程可见，如果是 file-backed 还会将内存修改同步到磁盘上的文件。
map as private objects: 修改对其他进程不可见，也不会同步到磁盘上，并且是 copy-on-write 的：一开始将 PTE 设为只读，在触发 protection exception 后，exception handler 发现这个 area 是可以写入但 private 的，就创建一个新的 page，将原来的 page 复制过去，将 PTE 设为可以写入。

fork 的原理

fork 时会将原来的 mm_struct 以及 page table 复制一份，但是将原来的 private area 中的 PTE 可以写入的重新变为只读，从而在之后再写入时重新触发 copy-on-write，就做到了 parent 和 child 一开始有一样的数据但后续写入独立。在 fork 前就创建了的 shared area 会由两个进程共享，可以利用这一点在 parent 和 child 之间通信。

execve 的原理

删除当前进程的所有 area (vm_area_struct)
根据 program header table 进行 memory mapping：
- .init、.text、.rodata: private, file-backed, read-only
- .data: private, file-backed, read/write
- .bss、heap、stack: private, demand-zero, read/write
如果有 link 到共享库，会进行动态链接，将共享库 private, file-backed map
修改 program counter

CS:APP 第八章学习笔记

Sat, 17 Dec 2022 06:27:26 GMT

CS:APP 第八章 “Exceptional Control Flow” 的学习笔记。

本章的主要内容为 exception、system call、process、signal、longjmp。

在一般情况下，PC 会按照指令的顺序以及跳转指令来变化。但在很多时候，这样的控制流是不能满足需要的，需要 exceptional control flow (ECF) 作为跳转指令的补充，以处理一些“异常”的或者来自“外部”的变化。

ECF 存在于各个层次，例如：

硬件监测到事件发生时调用 exception handler
操作系统在不同进程之间进行 context switch
不同进程间通过发送 signal 来调用接收者的 signal handler
程序内部通过 nonlocal jump 来实现错误处理

Exceptions

exception 是由某种“状态改变”（可能是某条指令执行的结果，或者来自外部 I/O 的变化等等）导致的控制流的突变。

处理器检测到这种状态改变后，会调用 exception handler，然后跳转到触发前的指令或下一条指令，或者终止整个程序。

Exception Handling

每种 exception 都会有一个 exception number，某些 exception 的 number 由硬件决定，另一些由操作系统决定。

内存中会有一个 exception table，以 exception number 为索引，每一项是对应的 exception handler。处理器中有一个 exception table base register，用来存 exception table 的起始地址，结合 exception number 就可以对每一项寻址。

exception 与 procedure call 的主要区别有：

procedure call 返回到栈顶存储的返回地址，而 exception 返回到触发时的指令或下一条指令，或终止程序。
调用 exception handler 时，会保存包括 condition codes 在内的一些处理器状态，在返回时恢复。
exception handler 在 kernel mode 下运行，使用的运行栈也是 kernel 的。

Classes of Exceptions

exception 一般有四种：

interrupt: 异步触发（不是某条指令的执行导致了 exception），返回到下一条指令。一般是由外部 I/O 设备触发（设备通过 interrupt pin 告诉处理器有 interrupt，通过 system bus 发送 exception number，处理器在每执行完一条指令后检查 interrupt pin），触发后调用 interrupt handler，再回到原来的位置继续执行下一条指令。
trap: 同步触发，返回到下一条指令。比如 system call 是一种常见的 trap，通过 syscall 指令主动触发 exception，看上去和函数调用类似，但可以在 kernel mode 下运行。
fault: 同步触发，返回到触发 exception 的指令或退出。一般来说，fault handler 会尝试解决导致 fault 发生的问题，如果成功解决则返回到触发 exception 的指令，并且能够不再次触发 exception 而继续执行下去；如果没能成功解决，则 abort。
abort: 同步触发，一定退出。一般代表严重的不可恢复的错误。

Exceptions in Linux/x86-64 Systems

x86-64 中的 fault / abort

Divide Error Exception (Interrupt 0): 除以零。它是 fault，但实际上 Linux 不会尝试从 divide error 中恢复，而是会直接 abort，一般会显示为 “floating point exception”。
General Protection Exception (Interrupt 13): 有多种触发原因，例如访问未定义的内存，尝试写入只读的内存段。Linux 也不会尝试从中恢复，而是会直接 abort，一般会显示为 “segmentation fault”。
Page-Fault Exception (Interrupt 14): page fault 是一个名副其实的 fault，会尝试恢复，详见第九章。
Machine-Check Exception (Interrupt 18): 严重的硬件错误，是 abort。

（完整列表参见 Intel® 64 and IA-32 Architectures Software Developer Manuals Volume 3A 的 “6.15 EXCEPTION AND INTERRUPT REFERENCE” 一节。）

Linux 中的 system call

Linux 中常用的一些 system call 如 CS:APP Figure 8.10 所示：

（更多 system call 参见 man syscalls）

在 C 语言中，可以使用 syscall 函数来调用 system call，但一般不这样做，而是使用每个 system call 对应的 wrapper function。syscall 和 wrapper function 统称为 system-level function。

Processes

一个系统中会有很多进程同时运行，但营造出了每个进程都独占了处理器和内存的假象。

进程独占内存的假象是通过每个进程的 private address space 实现的，详见第九章。

Logical / Concurrent Flow

根据一个程序的指令得到的 control flow 称作 logical (control) flow。系统会在不同的进程间来回切换，从一个进程切换出去称作将这个进程 preempt。

如果两个 control flow 的存活时间有重叠，则称它们是 concurrent flow 或它们 run concurrently。这种现象被称作 concurrency，也被称作 multitasking。每次连续执行的同一个 logical flow 中的一段称作一个 time slice，所以 multitasking 也被称作 time slicing。如果两个 logical flow 在不同的 processor core 上运行，则称它们是 parallel flow，run in parallel。

User / Kernel Mode

在处理器中存有一个 mode bit，表示当前是 user mode 还是 kernel mode。只有在 kernel mode 下才能执行某些 privileged instruction、修改 mode bit、访问地址空间中属于 kernel 的区域。

user mode 的程序只能通过 exception 来进入 kernel mode，以执行 privileged instruction 或者访问 kernel 的数据。在 Linux 中，也可以在 user mode 下访问 /proc、/sys 来获得一些 kernel 的数据。

Context Switch

每个进程都有一个 context，包括寄存器内容、PC、user stack、kernel stack、condition codes、page table、process table、file table 等等。

操作系统通过 context switch 来在不同进程间切换，即保存当前进程的 context，恢复要切换到的进程的 context，最后切换过去。context switch 在 exception 中发生，处理 exception 时操作系统中的 scheduler 会决定是否进行 context switch，schedule 到哪个进程。例如：

在通过 system call 读取文件时进行 context switch，以在等待读取文件时先执行其他进程；读取到文件后在 interrupt 中再 context switch 回来。
系统会周期性地（例如每 1ms）触发 interrupt，从而可以在一个进程执行了一段时间后进行 context switch。

因为程序不知道操作系统会如何 schedule，一般来说，不同进程的执行顺序是没有保证的。

System Call Error Handling

system-level function 一般以返回 -1 代表出错，而将具体的错误记录在全局整型变量 errno (#include <errno.h>)，函数 strerror 可以用来根据 errno 得到文字错误信息。

调用 system-level function 时应当检查错误。为了使错误处理更加简便，可以使用类似下面的 wrapper function：

#include <errno.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>

void unix_error(char *msg)
{
    fprintf(stderr, "%s: %s\n", msg, strerror(errno));
    exit(errno);
}

pid_t Fork(void)
{
    pid_t pid = fork();

    if (pid < 0)
        unix_error("Fork error");

    return pid;
}

#include <errno.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>

void unix_error(char *msg)
{
    fprintf(stderr, "%s: %s\n", msg, strerror(errno));
    exit(errno);
}

pid_t Fork(void)
{
    pid_t pid = fork();

    if (pid < 0)
        unix_error("Fork error");

    return pid;
}

Process Control

C 语言中有很多用来控制 Unix 进程的函数。

获取 PID

每个进程都有一个 PID。

pid_t getpid(void): 返回当前进程的 PID
pid_t getppid(void): 返回当前进程的 parent 的 PID

进程的状态

每个进程可能处于三种状态之一：

Running: 正在运行中，会被 schedule。
Stopped: 被 suspend 了，不会被 schedule。Stopped 可能是 SIGSTOP、SIGTSTP、SIGTTIN、SIGTTOU 导致的，可以由 SIGCONT 恢复运行。
Terminated: 进程永久地结束了，可能是从 main 函数返回、调用了 exit 函数或者收到了某些 signal。

void exit(int status): 以某个 exit status 将当前进程 terminate

fork

pid_t fork(void): 创建子进程

fork 会将当前进程的所有状态复制一份创建一个新的进程，新的进程有着和原来相同的代码、数据、文件（例如 stdout），但 PID 不同，并且后续对数据的修改是和原进程独立的。

fork 会调用一次，返回两次，分别在两个进程中返回，在 parent 中返回 child 的 PID，在 child 中返回 0，出错则返回 -1。

fork 出的进程和原进程在接下来会执行同一份代码，所以一般会判断 fork 的返回值是否为 0 来让两个进程执行不同的分支。

process group

每个进程会属于一个 process group，每个 process group 有一个 ID。

创建子进程时，子进程会默认处于 parent 的 process group。

pid_t getpgrp(void): 返回当前进程的 process group ID
int setpgid(pid_t pid, pid_t pgid): 将 pid 对应的进程的 progress group ID 修改为 pgid，pid 为 0 表示当前进程，pgid 为 0 表示修改为 pid 对应的进程的 PID

wait

pid_t waitpid(pid_t pid, int *statusp, int options): 等待子进程结束
pid_t wait(int *statusp): waitpid(-1, statusp, 0)

waitpid 的 pid 参数

参数 pid 决定了要等待的是哪些子进程：

-1: 所有子进程
> 0: PID 为 pid 的子进程
0: process group 与当前进程相同的子进程
< -1: process group ID 为 -pid 的子进程

waitpid 的行为 (options)

默认情况下，waitpid 会等待到有某个被等待的子进程 terminate 再返回，options 可以改变这一行为，其值可以包含下列 flag：

WNOHANG: 立即返回，如果没有符合条件的子进程则返回 0
WUNTRACED: 除了 terminate，子进程 stop 也可以结束等待
WCONTINUED: 除了 terminate，子进程从 stopped 中 continue 也可以结束等待

reap

除了等待，wait 还会将 terminated 的子进程 reap，即彻底清除掉。没有被 reap 但 terminated 的进程被称作 zombie，会占用一定的系统资源。在 ps 中，zombie 显示为 [defunct]。

如果 parent terminate 了，没有 terminate 的子进程会被设置为 PID 为 1 的 init 进程的子进程，而 zombie 子进程则会被 init reap。

wait 获取子进程的 status

如果 statusp 参数不是 NULL，在 waitpid 返回时 *statusp 内就会存有引起等待结束的那个子进程的信息。

有一系列 macro 可以用来提取 status 中的信息（参数是 *statusp，不是指针）：

WIFEXITED(status): 是否正常退出 (从 main 函数返回或调用了 exit 函数)
WEXITSTATUS(status): 如果正常退出，则返回 exit status (main 函数返回值 / exit 函数参数)
WIFSIGNALED(status): 是否由某个 signal terminate
WTERMSIG(status): 如果是由某个 signal terminate，返回这个 signal
WIFSTOPPED(status): 是否被 stop
WSTOPSIG(status): 如果被 stop，返回使其 stop 的 signal
WIFCONTINUED(status): 是否被 continue

wait 的报错

出错时 wait 会返回 -1，errno 可能是 ECHILD 表示被等待的子进程集合为空，可能是 EINTR 表示 wait 函数被某个 signal 中断了。

wait 会在每有一个子进程结束时返回，但子进程全部结束时会报错 ECHILD，可以利用这一点通过 while 循环来等待所有子进程全部结束。

sleep

unsigned int sleep(unsigned int secs): sleep 若干秒，返回剩余应当 sleep 的秒数（正常情况下没被 interrupt 就是 0）
int pause(void): 一直 sleep，直到被 signal interrupt，总是返回 -1

execve

int execve(const char *filename, char *const argv[], char *const envp[])

execve 会以 argv 作为参数、envp 作为环境变量，在当前进程内执行 executable object file filename。可以和 fork 配合来在子进程内执行其他程序。

argv 是一个以 NULL 为结尾的字符串数组，表示各个参数，其中第一个一般是程序的名称。

envp 也是以 NULL 为结尾的字符串数组，每个字符串形如 name=value。

有一些函数可以用来获取、设置环境变量：

char *getenv(const char *name): 返回 NULL 或环境变量的值
int setenv(const char *name, const char *newvalue, int overwrite): 成功则返回 0，失败（overwrite 为 0 而 name 已存在）则返回 -1
void unsetenv(const char *name)

Signals

signal 的种类

可以用 man signal.7 查看 signal 的列表（名称、语义、编号、默认行为）。

特别地：

除以零时会被发送 SIGFPE
执行非法指令时会被发送 SIGILL
非法访问内存时会被发送 SIGSEGV
按 Ctrl+C 时 foreground process group 会被发送 SIGINT
子进程 terminate 时会向 parent 发送 SIGCHLD
可以通过 SIGKILL 来强行 terminate 一个进程

signal 的工作流程

每个进程会记录每个 signal 是否 pending、是否 blocked
发送 signal 会使接收者的这个 signal 变为 pending
进程可以改变每个 signal 的 blocked 状态
在切换到 user mode 执行进程时，如果一个 signal 处于 pending 状态且没有被 blocked，就会接收这个 signal，并设为没有在 pending

这意味着：

signal 只记录是否 pending，不会记录发送了几次，在被接收前多次发送只会被接收一次
在 blocked 状态下被发送 signal，会在 unblock 时收到

发送 signal

kill 命令

可以用 kill 命令在 shell 中向指定的进程发送信号。一般 shell 会有 builtin 的 kill，也有位于 /usr/bin/kill 的 kill，可能有一定的区别。

基础的 kill 命令形如 kill -sig pid，其中 -sig 可以形如 -INT/-SIGINT/-2，而 pid 表示要把信号发送给：

> 0: PID 为 pid 的进程
0: process group 和当前进程相同的进程
-1: 除 PID 为 1 的 init 外的所有进程
< 0: process group ID 为 -pid 的进程

这与 waitpid 的 pid 参数是类似的。

在 shell 中使用键盘发送 SIGINT / SIGTSTP

shell 中会有至多一个 foreground job 和零个或若干个 background job。shell 会给每个 job 中的所有进程指定同样的 process group。

Ctrl+C 会向 foreground group 发送 SIGINT，Ctrl+Z 会向 foreground group 发送 SIGTSTP。

使用函数发送 signal

int kill(pid_t pid, int sig): 与 kill 命令类似
unsigned int alarm(unsigned int secs): 让 kernel 在 secs 秒后向当前进程发送 SIGALRM；如果有尚未发送的 alarm 则取消掉，如果 secs 为 0 则取消后不会发送新的 SIGALRM；没有尚未发送的 alarm 则返回值是 0，否则是被取消的 alarm 还剩的秒数

设置 signal handler

除了 SIGKILL 和 SIGSTOP，其他 signal 的行为可以被改变。

#include <signal.h>
typedef void (*sighandler_t)(int);
sighandler_t signal(int signum, sighandler_t handler);

#include <signal.h>
typedef void (*sighandler_t)(int);
sighandler_t signal(int signum, sighandler_t handler);

函数 signal 用来改变处理 signal signum 的方式。handler 可以是一个函数指针，也可以是 SIG_IGN 表示无视这个 signal，或者 SIG_DFL 表示使用这个 signal 的默认行为。

有 handler 时，接收到一个 signal 就会触发 exception 来执行 handler，在 handler 结束时一般会返回到原来的指令。

在执行 handler 的过程中，相应的 signal 会被 block，但 handler 可以被其他类型的 signal interrupt，在处理完这另一个 signal 后返回到一开始的 handler。

block / unblock signal

进程可以主动 block / unblock 指定的 signal：

int sigprocmask(int how, const sigset_t *set, sigset_t *oldset)

其中 how 是 SIG_BLOCK / SIG_UNBLOCK / SIG_SETMASK，分别表示 block set 里的 signal / unblock set 里的 signal / 将 blocked set 设为 set。

若 oldset 不是 NULL，则会将修改前的 blocked set 存下来。

还有一些用来设置 sigset_t 的函数：

int sigemptyset(sigset_t *set): 将 set 设为空
int sigfillset(sigset_t *set): 将 set 设为所有 signal
int sigaddset(sigset_t *set, int signum): 将 signum 加入 set
int sigdelset(sigset_t *set, int signum): 将 signum 从 set 中删去
int sigismember(const sigset_t *set, int signum): 检查 signum 是否在 set 中，返回 0/1 或出错返回 -1

编写、使用 signal handler

编写安全的 signal handler

由于 signal handler 和主程序并行运行、共享数据，并且主程序可能在意想不到的地方接收到 signal 而被 interrupt，编写安全的 signal handler 是困难的，一般要遵循下面的守则：

handler 应当尽量简单，例如可以设置一个 flag 而在主程序中检查 flag 并进行处理，而非直接在 handler 中处理
在 handler 中只调用 async-signal-safe 的函数（函数列表参见 man signal-safety），常用的 printf、sprintf、malloc、exit 都不是 async-signal-safe 的
存储并恢复 errno，保证调用 handler 前后 errno 不变
访问 handler 与主程序共享的数据时，block signal 以防止在访问的中途被 interrupt
把在 handler 中修改而在主程序中访问的的全局变量声明为 volatile 的，防止编译器误认为变量没有被修改而错误地进行优化
将 flag 声明为 sig_atomic_t 类型，它的单次访问是 atomic 的，不会被 interrupt（但先读后写是两次访问，可能被 interrupt）

正确处理多次发送的 signal

多次发送 signal 可能只会收到一次，所以处理 signal 时不能误以为收到的次数与发送的次数相同。

例如，接收 SIGCHLD 来 reap child 时，应当在 handler 中 reap 掉所有已 terminate 的子进程，而非只 reap 一个子进程。

不同系统上 signal handling 的差异

在一些系统上，signal handling 的语义会有区别：

在一些系统上，调用了 handler 后这个 signal 就会恢复默认行为，需要在 handler 中重新调用 signal 才能一直使用这个 handler。
在一些系统上，需要执行较长时间的 system call 会在被 interrupt 后报错 EINTR，而在现代系统上会尽可能地自动重新执行这个 system call，详见 man signal.7 的 “Interruption of system calls and library functions by signal handlers” 一节。

（P.S. 这就是 Rise of Worse Is Better 中用来举例的 “PC loser-ing problem”，原本采用 worse-is-better 的 Unix 现在也进化成了 the right thing）（P.P.S. 当时读这篇的时候我完全没看懂这一段，没想到现在竟然还能记起来）

可以通过 sigaction 函数来设置想要的 signal handling 语义。

注意 handler 被调用的时机

handler 可能会在意想不到的时机被调用，为了避免出错（race），可能会需要暂时 block signal 来确保 handler 在正确的时机被调用。详见 CS:APP 上的例子。

等待 signal

int sigsuspend(const sigset_t *mask): 将 blocked set 设为 mask，在接收到任何 signal 后返回

可以在程序的其他部分 block 掉某个 signal，然后在 sigsuspend 的参数中将其 unblock，以达到等待该 signal 的目的。因为 sigsuspend 等待的不是某个特定的 signal，可以配合 while 循环来检查由 handler 设置的某个 flag。

sigsuspend 的效果类似于下面的这段代码：

sigprocmask(SIG_SETMASK, &mask, &prev);
pause();
sigprocmask(SIG_SETMASK, &prev, NULL);

sigprocmask(SIG_SETMASK, &mask, &prev);
pause();
sigprocmask(SIG_SETMASK, &prev, NULL);

不同的是，上面这段代码有可能会恰好在 sigprocmask 之后、pause 之前接收到 signal，导致这个 signal 没有将 pause interrupt 而一直 sleep 下去。sigsuspend 是 atomic 的，就不存在这样的问题。

Nonlocal Jumps

int setjmp(jmp_buf env)
void longjmp(jmp_buf env, int val)

setjmp 会将当前的 PC 和寄存器等信息存在 env 中，而 longjmp 会恢复 env 中保存的信息，跳转到 setjmp 的位置。

这意味着 setjmp 可能返回多次，而 longjmp 不会返回。第一次调用 setjmp 会返回 0，而之后调用 longjmp 时会在 setjmp 的位置返回参数 val 的值（特别地，如果 val 的值是 0，会返回 1，强制和首次返回区分开）。

因为 setjmp / longjmp 只是恢复 PC 和寄存器（包括 %rsp）：

调用 longjmp 时 setjmp 所在的函数必须还没有返回，否则 setjmp 所在的 stack frame 就失效了。
setjmp 的返回值只应出现在一些简单的表达式中，否则是 UB。特别地，不应将 setjmp 的返回值赋给一个变量，但可以放在 if 或 switch 里。这是考虑到，计算一个复杂的表达式可能会有一些中间量以及 dynamic stack allocation，而 longjmp 回来时这些中间量、dynamic stack allocation 不一定能被正确恢复，导致表达式不一定能被正确计算。
如果修改了存放在内存中的局部变量，跳转后会是被修改过的值而不是原来的值，而存放在寄存器中的值则会被恢复。要确保变量不被存在寄存器中，必须使用 volatile 声明变量，否则（即便使用了 register 或 auto 来声明变量）编译器可能任意地把变量放在内存或寄存器中，造成跳转后变量的值不确定。

int sigsetjmp(sigjmp_buf env, int savesigs)
void siglongjmp(sigjmp_buf env, int val)

sigsetjmp / siglongjmp 会额外存储、恢复 pending / blocked signal 的信息（需要以非 0 savesigs 调用 sigsetjmp），可以用于 signal handler。

nonlocal jump 主要有两种用途：

出错时直接跳转到一个集中的位置来处理错误，而不用一层层往上返回
处理 signal 时不返回到被 interrupt 的位置，而跳转到指定的位置

在 signal handler 中使用 nonlocal jump 时需要注意：

先 sigsetjmp 再 install signal handler，否则可能 race
siglongjmp 跳转到的后续代码中只能调用 async-signal-safe 的函数

nonlocal jump 可能造成可读性的问题，也可能因为跳过了中间很多函数的返回，造成内存泄露等后果，要谨慎使用。

Tools for Manipulating Processes

strace: 显示程序调用的所有 system call，可以静态链接来避免看到大量共享库相关的输出
ps: 列出进程信息
top: 列出进程的资源使用（可以用 htop）
pmap: 查看进程的 memory map
/proc: 查看各种进程相关的信息 (man proc.5)

CS:APP 第六章学习笔记

Mon, 05 Dec 2022 07:47:43 GMT

CS:APP 第六章 “The Memory Hierarchy” 的学习笔记。

这章的主要内容有：各种存储设备（RAM、ROM、HDD、SSD）的特点、程序的局部性、缓存的结构以及原理、缓存对程序性能的影响。

因为时间不太够，本来我想先跳过这章以后再补的，但学第九章的时候感觉还是跳不得，否则第九章有些东西感觉学了个半懂。~~虽然只用学一小部分就足以满足第九章的需求，但我打算摆烂了，该学的东西学不完就学不完，我想学啥就学啥。~~

Storage Technologies

RAM

Random access memory 分为 SRAM 和 DRAM 两种，SRAM 有更快的访问速度但更加昂贵。

SRAM

SRAM (Static RAM) 将每个 bit 存储在一个 bistable 的 memory cell 中，每个 cell 由 6 个晶体管组成，有两种可能的稳定态，遇到微小的扰动也会迅速恢复到这两种状态之一。

DRAM

DRAM (Dynamic RAM) 将每个 bit 存储在一个很小的电容中，容易受到外界干扰，所以需要周期性地将数据复制出去再复制回来以进行刷新，可能还会配合纠错码来保证数据正确。

DRAM 的设计使其存储密度更高，但访问速度更慢；SRAM 则更快，但密度更低，更贵，更费电。访问 DRAM 的用时大约是 SRAM 的 10 倍，而 SRAM 的造价大约是 DRAM 的 1000 倍。

Conventional DRAM

DRAM 芯片被分为若干 supercell，每个 supercell 存储一个 word，一般是 1 byte。supercell 排列为二维阵列，可以用二维坐标 $(i, j)$ 定位。

DRAM 通过 pin 连接到 memory controller 来和外界通信。读取位于 $(i, j)$ 的 supercell 时，memory controller 会依次发送 row access strobe (RAS) $i$ 和 column access strobe (CAS) $j$ ，在收到 RAS 后 DRAM 会将第 $i$ 行复制到一个内部的 row buffer，收到 CAS 后再从 row buffer 里将第 $j$ 列发送给 memory controller。

Memory Module

DRAM 芯片会被组装为 memory module 来插到主板上。

DIMM 是一种 memory module。例如，一个 DIMM 可以包含 8 个 DRAM 芯片，每个 64-bit 的 word 在每个 DRAM 芯片的同一个地址上分别存一个 byte，从而整个 DIMM 可以以 64-bit 为单位与外界通信。

Enhanced DRAM

朴素的 DRAM 是比较慢的，历史上曾经有过若干对 conventional DRAM 的优化：

FPM (fast page mode) DRAM: 如果连续两次 RAS 是一样的，可以省略掉后续相同的 RAS，直接发送 CAS
EDO (extended data out) DRAM: 延长了数据输出的时间，对 pipelining 有帮助
SDRAM (synchronous): 通过时钟信号的 rising edge 同步地通信，而非通过发送 RAS/CAS 异步通信
DDR (double data-rate) SDRAM: 通过同时使用时钟信号的 rising edge 和 falling edge 达到 double data-rate，分为 DDR、DDR2、DDR3、DDR4、DDR5 等
VRAM (video): 一般用于显卡、frame buffer 等，它的输出是直接输出整个 buffer，并且可以并行地同时读和写

ROM

RAM 会在断电后丢失数据，所以是 volatile 的。与之相对，还有 nonvolatile 的存储器，统称为 read-only memory (ROM)，尽管有的 ROM 是可以写入的。ROM 的写入称作 reprogram。

PROM (programmable ROM) 只能被写入一次。
EPROM (erasable PROM) 需要用特殊设备写入，可以写入大约 1000 次。
EEPROM (electrically EPROM) 不需要用特殊设备就可以写入，可以写入大约 $10^5$ 次。
flash memory 是一种基于 EEPROM 的 nonvolatile 存储器，被广泛使用，包括用于 SSD。
固件 (firmware) 往往存储于 ROM 中。

访问 main memory

一个 bus 是一组用来通信的导线，可以传输地址、数据、控制信号等。CPU 和 main memory 之间的通信通过 bus transaction 进行。

CPU 通过 system bus 连接 I/O bridge，I/O bridge 通过 memory bus 连接 main memory。I/O bridge 负责 system bus signal 和 memory bus signal 之间的转换。

HDD

磁盘的结构

磁盘由若干 platter（盘片）组成。每个 platter 有两个 surface（表面），每个 surface 上覆盖着磁性记录材料。platter 由位于中心的 spindle（主轴）带动，以某个一般是 5400~15000 RPM 的速度转动。

每个 surface 被分成若干个称作 track（磁道）的同心圆环，每个 track 被分为若干 sector（扇区）。每个 sector 存有相同大小的数据（一般是 512 bytes），相邻的 sector 之间由 gap（间隙）隔开，gap 不存储数据，而是用来识别 sector。

一个磁盘通常由多个堆叠在一起的 platter 构成，这些 platter 共享一个 spindle。对于某个距离 $k$ ，一个磁盘内所有 surface 上离转轴距离为 $k$ 的 track 的集合称作一个 cylinder（柱面）。

整体结构如 CS:APP Figure 6.9 所示：

磁盘的容量

磁盘的容量有三个衡量指标：

recording density: 单位长度的 track 存储的 bit 数量
track density: 单位长度的半径上的 track 个数
areal density: 单位面积上存储的 bit 数量

早期的磁盘的所有 track 都有相同数量的 sector，这样的话位于外部的 track 的 sector 就会更加稀疏。后来为了提高容量，将 cylinder 划分成了若干个 recording zone，每个 recording zone 由若干相邻的 cylinder 组成，同一个 recording zone 内的所有 track 有相同数量的 sector。

磁盘的读写

磁盘通过连在传动臂上的读写头进行读写，每次读写前需要先将读写头移动到相应的位置（寻道），并等待目标 sector 转动到读写头下，再开始读写。

寻道用时与读写头原本的位置到目标位置的距离有关，等待转动的用时则看运气。在 CS:APP 举的例子中，寻道平均用时为 9 ms，等待旋转平均用时为 4 ms，读写一个 sector 用时 20 μs。

也就是说，磁盘读写的主要用时是寻道以及等待旋转用时，也就是初次访问一段连续的 sector 的用时，而与访问多少个连续的 sector 关系不大。对于单个 sector，磁盘访问的用时可以达到 SRAM 的 $10^4$ 倍，DRAM 的 $10^3$ 倍，但连续 sector 的读写用时仅为 DRAM 的不到十倍。

Logical Disk Blocks

磁盘对外提供了 logical block 作为 sector 的抽象，每个 logical block 的大小和一个 sector 相同，由连续的非负整数索引，通过 disk controller 翻译成形如 (surface, track, sector) 的坐标。

I/O bus

不同的 I/O 设备通过 I/O bus 与 I/O bridge 连接。例如显卡、连接各种设备的 USB controller、通过 SCSI/SATA 等接口连接磁盘的 host bus adapter 等都会连接到 I/O bus。

访问磁盘

访问磁盘需要向磁盘发送三条指令：

向磁盘发送一个信号，告诉磁盘要读取数据
将要读取的 logical block number 发送给磁盘
告诉磁盘读取到的数据要放在 main memory 的哪个地址

发送完这些指令后，CPU 会继续干其他事情。磁盘读取到数据后，会通过 I/O bus 直接将数据存放到 main memory 中而不经过 CPU，这被称作 direct memory access (DMA)。存放好数据后，磁盘向 CPU 发送 interrupt signal 来跳转到处理磁盘读取完成的 signal handler。

SSD

SSD 将一个或多个 flash memory 包装起来，并且有一个 flash translation layer 来将输入的 logical block number 转换为对 flash memory 的访问，对外表现出与 HDD 类似的接口。

flash memory 由若干 block 组成，每个 block 又由若干（32-128 个）page 组成，每个 page 一般是 512B-4KB 大，数据传输的最小单位是 page。

SSD 的写入比较特殊：一个 page 需要在所属的整个 block 都被擦除（改为全 1）后才能写入一次，如果要写入第二次就得再把整个 block 擦除一遍。在写入时，为了擦除某个 block，可能会需要把这个 block 存储的数据复制到其他 block。擦除是一个耗时相对较长的操作，需要约 1 ms，并且每个 block 在擦除约 $10^5$ 次后就会损坏。

这使得 SSD 的写入比读取略慢，并且写入很多次后可能损坏。flash translation layer 会通过 wear-leveling logic 来尽可能使得每个 block 的擦除次数相同，以延长 SSD 的使用寿命。

disk、RAM、CPU 速度差异的历史变化如 CS:APP Figure 6.16 所示，其中 CPU cycle time 是单核的，effective CPU cycle time 是多核的：

Locality

好的程序具有良好的 locality。locality 有两种表现形式，temporal locality 指的是最近访问过的数据更有可能在不久的将来再次被访问，spatial locality 指的是访问过一处的数据后更有可能在不久的将来访问邻近的其他数据。

具有良好 locality 的程序跑得更快，因为计算机系统设计的各个层面都利用 locality 做了优化。

一些 locality 的例子：

重复引用同一个变量的程序有良好的 locality。
在一段连续内存（数组）中依次访问每个元素称作 stride-1 reference pattern，每次间隔 $k-1$ 个元素进行访问称作 stride-k reference pattern， $k$ 越小 locality 越好。遍历高维数组时尤其要注意访问的顺序。
由于循环会重复访问同一段指令，循环的指令读取局部性良好

The Memory Hierarchy

在硬件上，不同存储技术之间存在性能、价格、容量的 trade-off；在软件上，程序具有 locality。硬件和软件的这两条性质正好可以搭配在一起，促使 memory system 采用了如 CS:APP Figure 6.21 所示的称作 memory hierarchy 的组织方式：

memory hierarchy 的构成并不一定和上图完全一致，例如 SRAM 的级数可能不是三级、DRAM 和 HDD 间可能还有 SSD、磁带也可以作为 memory hierarchy 中比 HDD 更低的一级。

Cache

caching 指的是用一个相对小而快的存储设备来存储一个相对大而慢的存储设备中最为活跃的部分，这个小的存储设备称作大的存储设备的 cache。

在 memory hierarchy 中，每一级都是下一级的 cache。数据会在各个相邻层级间不断地传输，不同层级之间会以不同的 block size 作为数据传输的基本单位。

从 cache 获取数据

想要从 memory hierarchy 的某一级获取数据时，首先会尝试从它的 cache 获取数据，如果成功获取则称作 cache hit，否则称作 cache miss。

发生 cache miss 时，一般会先将数据从下一级复制到上一级，从而最终还是表现为从 cache 中获取数据。如果 cache 满了，在从下一级获取数据时，就需要删除 cache 中的一些数据来腾出空间，这时需要在 cache 中选择被删除的数据，被删除的 block 称作 victim block，这个行为称作将 victim block evict，而选择 victim block 是根据 replacement policy 进行的，例如 random replacement policy、least recently used (LRU) replacement policy 等。

Cache 的管理

cache 可能由硬件、OS、软件以及它们之间的相互配合来进行管理，而这在大部分时候都是自动完成的，无需应用程序的程序员操心。

各级 cache 如 CS:APP Figure 6.23 所示：

Cache 对 locality 的利用

temporal locality 使得重复使用的数据留存在 cache 中从而更容易 cache hit；cache 中的数据按 block 存储则利用了 spatial locality，使得一个数据被 cache 时与其邻近的处于同一个 block 的数据也被 cache。

Cache Memories

随着 CPU 和 DRAM 的速度差异越来越大，SRAM 被用来填充它们之间的 gap。

在下面的讨论中，为了简便，假设只有 L1 cache，没有 L2、L3 cache。（或者也可以看成是在介绍 L3 cache 是如何工作的。）

Cache 的结构与读取

设 main memory 有 $2^m$ 个地址，每个地址存放一个 byte。它的 cache 会分成 $2^s$ 个 cache set，每个 cache set 包含 $E$ 个 cache line，每个 cache line 存放一个大小为 $2^b$ byte 的 data block、一个 valid bit、以及长度为 $t = m-b-s$ 的 tag bits。

每个地址会被分成三部分，高位的 $t$ 位是 tag，中间 $s$ 位是 set index，低位 $b$ 位是 block offset。获取存放在某个地址的数据时，先根据其 set index 找到对应的 cache set，再在 cache set 中找到 valid bit 为 1 且 tag 相符的 cache line，最后通过 block offset 来从 block 中提取出单个 byte。

在 cache miss 时，需要从下一级获取数据，存放到 cache 中。如果对应的 cache set 所有 cache line 都满了，就需要 evict 某个已有的 cache line。

Conflict Miss

cache set 的设计基于一个假设，即在局部内访问的数据地址的低位往往是不同的，但实际上可能并非如此。如果以 $2^{s+b}$ 的倍数为地址间隔访问数据，就可能连续访问同一个 cache set 内的数据，导致 cache miss（ $E$ 较小，尤其是 $E=1$ 时，这种情况更可能触发）。例如，数组的大小是 $2$ 的次幂而交替访问相邻数组的同一个下标时就可能这样。（这大概在 APIO2019 讲过，当时我自然是啥都没听懂，就只记得数组不要开 $2$ 的次幂。）

Cache 的分类

$E=1$ 的 cache 称作 direct-mapped cache。（~~书上在这仔细解释了半天，感觉废话好多啊。~~）

$E > 1$ 的 cache 称作 set associative cache。其中， $s > 0$ 的称作 E-way set associative cache，而 $s = 0$ 的称作 fully associative cache。

Cache 的写入

在 cache hit 时，有两种处理方式：

write-through: 既修改 cache，又修改下一级
write-back: 只修改 cache，并且在每个 cache line 中添加一个 dirty bit，用来记录是否被修改过，在被 evict 时若 dirty 则写入下一级

在 cache miss 时，也有两种处理方式：

write-allocate: 先从下一级获取数据，然后用与 cache hit 相同的处理方式
no-write-allocate: 直接写入下一级，不获取到 cache 中

一般 write-through 和 no-write-allocate 搭配，write-back 和 write-allocate 搭配。

实际上，cache 写入的优化是非常复杂的问题，这里只是简单介绍了一下。作为程序员，可以把 cache 写入当成是 write-back、write-allocate 的。

i-cache 和 d-cache

只存放指令的 cache 称作 i-cache，只存放数据的 cache 称作 d-cache，都存放的 cache 称作 unified cache。

将 i-cache 和 d-cache 分开，就可以对它们分别进行优化，例如 i-cache 是只读的，二者可以有不一样的大小、不一样的 cache set 设置。将两者分开还可以一定程度上避免 conflict miss。

在 Core i7 处理器中，每个核有自己的 L1 i-cache、L1 d-cache、L2 unified cache，所有核共享一个 L3 unified cache。

Cache 的性能

cache 性能的衡量指标有：

miss rate
hit rate
hit time: cache hit 时的访问用时
miss penalty: cache miss 时的访问用时，与最终从哪一级获取到数据有关

一般来说，cache 的参数对性能的影响是：

cache size 越大，hit rate 就越高，但速度会慢。
增大 block size 可以更好地利用 spatial locality，但也有可能因 cache line 数量减少而降低 hit rate，并且会因为每次需要传递的数据变多而增大 miss penalty。
更大的 $E$ 可以降低 conflict miss 的可能性，但也会使得 tag 匹配以及 victim line 的选择更加复杂，从而增大 hit time 和 miss penalty。在 Core i7 处理器中，L1、L2 cache 是 8-way 的，L3 cache 是 16-way 的。
write-through 实现起来更加容易，并且在 read miss 时不会触发写入。而 write-back 可以减少数据传递的总量，降低 I/O bus 带宽的占用，也可能降低数据传递的用时。一般来说，memory hierarchy 中较低的层级更倾向于使用 write-back。

The Impact of Caches on Program Performance

The Memory Mountain

对一定 size 的数据按照一定的 stride 进行访问，将 size、stride 与数据吞吐量的关系画成三维图像，就得到了 memory mountain。

CS:APP Figure 6.41 展示了一座 Core i7 的 memory mountain:（这也是 CS:APP 的封面）

Memory mountain 较为完整地呈现了一个 memory system 的性能，以及 temporal locality 和 spatial locality 对性能的影响。

在每级 cache 的容量处，吞吐量会发生明显的突变。

在 size 相同时，stride 越小吞吐量越高。在 stride 接近 1 时变化尤其明显，这和 Core i7 系统的 prefetching 技术息息相关，处理器能够识别出 stride-1 reference pattern 并在实际访问到数据之前就进行 prefetch。

矩阵乘法的循环顺序

（书上在这讲了半天，~~感觉废话好多~~，我就放个测试结果上来吧。）（CS:APP Figure 6.46）

CS:APP 第七章学习笔记

Mon, 31 Oct 2022 10:39:06 GMT

CS:APP 第七章 “Linking” 的学习笔记。

这章的主要内容为程序的链接。学习链接有助于：理解链接报错，避免链接相关的 bug，理解变量（函数）的作用域，理解程序运行过程中与链接相关的步骤，了解如何使用共享库（动态链接库）。

Compiler Drivers

编译源文件其实分成若干步骤，compiler driver（如 gcc）会依次调用这些步骤，可以用 gcc -v 来查看这些步骤的详细信息。

cpp: 预处理，源代码 .c -> intermediate file .i
cc1: .i -> 汇编代码 .s
as: .s -> relocatable object file .o
ld: 链接，多个 .o (或 library) -> executable object file

P.S. 中间步骤的文件也可以作为参数传递给 gcc，例如 gcc a.s -o a。

Static Linking

静态链接主要有两个任务：

Symbol resolution: relocatable object file 中有很多 symbol，包括函数、全局变量、静态变量等，linker 需要将每个 symbol reference 对应到一个 symbol definition。
Relocation: relocatable object file 中地址从 0 开始，linker 需要将每个 symbol definition 重新分配到正确的地址，并相应地修改每个 symbol reference。

Object Files

object file 分为三种：

Relocatable object file
Executable object file
Shared object file: 一种特殊的 relocatable object file，可以在 load time 或 run time 进行动态链接

object file 有不同的格式，Windows 使用 Portable Executable (PE) 格式，macOS 使用 Mach-O 格式，现代的 x86-64 Linux/Unix 系统使用 Executable and Linkable Format (ELF) 格式。本章会基于 ELF-64。

Relocatable Object Files

ELF relocatable object file 通常包含以下 section：

.text: 程序的机器码
.rodata: 只读的数据
.data: 需要初始化的全局变量和静态变量
.bss: 未初始化或初始化为零的全局变量和静态变量，它们在运行时会以零为初值，从而在 object file 中不占据文件大小
.symtab: symbol table，存储 symbol（函数、全局变量）的信息，不需要 -g 编译选项，但不含局部变量的信息
.rel.text: 列出了 .text 中在链接时需要修改的地方，一般是调用外部函数或引用全局变量时需要修改，而调用本地函数不需要修改
.rel.data: 列出了 .data 中在链接时需要修改的地方，一般是全局变量的值为其他全局变量或外部函数的地址时需要修改
.debug: 调试信息，包含局部变量的信息、typedef 信息、源代码等，需要 -g 编译选项才有
.line: 源代码与机器码行号间的对应关系，需要 -g 编译选项才有
.strtab: 一堆字符，用于其它 section，可以指向其中一个位置来表示一个字符串（从这个位置起到 \0 为止）

Symbols and Symbol Tables

对 linker 来说，symbol 有三种：

本地定义，可以被外部访问的: C 中非 static 的函数和全局变量
外部定义的，例如 C 中 extern 的全局变量
本地定义，外部不可访问的: C 中 static 的函数和变量

一个 ELF64 symbol 包含如下信息（CS:APP Figure 7.4）：

typedef struct
{
    int   name;      /* String table offset */
    char  type:4,    /* Function or data (4 bits) */
          binding:4; /* Local or global (4 bits) */
    char  reserved;  /* Unused */
    short section;   /* Section header index */
    long  value;     /* Section offset or absolute address */
    long  size;      /* Object size in bytes */
} Elf64_Symbol;

typedef struct
{
    int   name;      /* String table offset */
    char  type:4,    /* Function or data (4 bits) */
          binding:4; /* Local or global (4 bits) */
    char  reserved;  /* Unused */
    short section;   /* Section header index */
    long  value;     /* Section offset or absolute address */
    long  size;      /* Object size in bytes */
} Elf64_Symbol;

value 在 relocatable object file 中是 symbol 的地址相对于 section 开头的 offset，在 executable object file 中是 symbol 的绝对地址。

section 是 object file 的 section 之一（的 index），在 relocatable object file 中还可以是一个 pseudosection:

ABS: 不应被 relocate 的 symbol
UNDEF: 未定义（在其他 module 中定义）的 symbol
COMMON: 多个 module 共用的 symbol（见 Symbol Resolution），此时 value 的值给出 data alignment 的要求，size 给出的是 minimum size

未初始化的静态变量以及初始化为零的全局或静态变量会放在 .bss。

未初始化的全局变量，如果启用了 -fcommon 编译选项则会放在 COMMON，否则放在 .bss。在 gcc 9 及之前默认选项是 -fcommon，而自 gcc 10 起默认选项是 -fno-common。在 C++ 中 -fcommon 是无效的，未初始化的全局变量总是放在 .bss。

可以使用 readelf -s a.o 来查看 a.o 的 .symtab。

Symbol Resolution

Symbol resolution 即把每个 symbol reference 对应到一个 symbol definition。

local symbol 的 resolution 是容易的，因为编译单个 module 时就保证了 local symbol 是唯一的。

global symbol 可能遇到几种情况：

只有一个 module 里定义了这个 global symbol，则使用这个 symbol
没有任何 module 里定义了这个 global symbol，则报错 undefined reference
在多个 module 里定义了这个 global symbol，则：
- 如果其中有多个 symbol 不在 COMMON 段，则报错 multiple definition
- 如果其中只有一个不在 COMMON 段，则使用这个 symbol
- 如果这些 symbol 都在 COMMON 段，则使用其中 size 最大的一个（如果 size 相同则使用哪个是没有区别的）；如果这些 symbol 有不一样的 size，linker 还会给出警告

也就是说，若编译选项为 -fcommon，如果在多个 module 中定义了同一个全局变量且其中最多有一个初始化了，则可能导致意外的结果。可以理解为，multiple definition 在本质上是 multiple initialization。

在 C++ 中，函数重载、类方法会通过 mangling 来使得函数的每种重载有独特的 symbol name。

Static Libraries

Static library 其实就是一堆 object file 包装在一起，它的好处是：

不用每次重新编译（比起提供源码）
使得库和编译器解耦（比起将库函数内置到编译器中）
只需将用到的 object file 复制到最终的可执行文件中，避免空间浪费（比起提供单个 object file）
可以自动选择用到的 object file，在编译命令中只需指定少量库的名称（比起提供一堆 object file）

可以使用类似 ar rcs libabc.a a.o b.o c.o 的命令来创建一个 static library。

在编译时，有两种使用 static library 的方式：

直接将 static library 的路径作为参数: libabc.a
使用 -lname 来使用 libname.a，但需要使用 -Ldir 来将 dir 加入到 -l 的搜索路径之中: -L. -labc

特别地，编译器会自动将 libc.a 提供给 linker，不需要手动指定。

在链接时，linker 会依次处理每个参数：

如果一个参数是 object file 就一定会使用
如果是 static library，则会依次查看其中包含的每一个 object file，如果一个 object file 中定义了某个当前引用了但仍未定义的 symbol，则会使用这个 object file，而这样的过程会反复迭代进行直到没有新的 object file 被使用为止（例如 main.c 引用了 b.o 而没有引用 a.o，而 b.o 中引用了 a.o，且在 libabc.a 中 a.o 位于 b.o 之前，那么第一次迭代中只会使用 b.o，第二次迭代才会使用 a.o，而 c.o 不会被使用）

这样的过程使得编译命令中参数的顺序以及 static library 中 object file 的顺序可能影响编译结果：

一般来说需要将 library 放在编译命令的末尾，否则处理一个 library 时还没有引用其中的 symbol，就不会使用相应的 object file，最后就会报错 undefined reference
如果多个 library 之间有依赖关系，需要将被其他 library 依赖的 library 放在靠后的位置
如果多个 library 之间有循环依赖，可能需要在编译命令中多次指定同一个 library（或者也可以将这两个 library 合并成一个，这样的话通过多次迭代就可以解决循环依赖）
library 的设计应当避免 multiple definition，但理论上存在不同的参数顺序或 static library 中 object file 的顺序导致 multiple definition 的可能

Relocation

relocation 分为两步：

给 symbol definition 重新分配内存地址
相应地修改 symbol reference

第一步是简单的，把各个 object file 中的各个 section 分别拼在一起即可。

为了让 linker 知道如何修改 symbol reference，需要让 linker 知道：

需要被修改的 symbol reference 在哪
需要修改成什么

在 relocatable object file 的 .rel.text 和 .rel.data 中存放了相关的信息，一条这样的信息称作一个 relocation entry，包含的内容为：

offset: 这个 symbol reference 相对于其所在的 section 的偏移量。也就是说，在这个 reference 所在的 section 的地址的基础上加上 offset 就得到了这个 reference 的地址。
type: 有很多种 relocation，CS:APP 中只介绍其中的 R_X86_64_PC32 和 R_X86_64_32 两种。
symbol: 被 reference 的 symbol 在 symbol table 中的 index。
addend: 计算 symbol 地址时加在最后的常数（见后文）。

简单来说，R_X86_64_32 使用绝对地址进行定位，R_X86_64_PC32 使用相对于 PC 的地址进行定位，且这两种类型的 relocation 都只支持 32 位的地址（如果一个程序的大小超过 2GB，就需要指定编译选项 -mcmodel=medium/large）。

R_X86_64_32: 修改后的 reference 为 symbol 的地址加上 addend
R_X86_64_PC32: 修改后的 reference 为 symbol 的地址与 reference 的地址之差加上 addend；需要注意的是，是与 reference 的地址之差，而不是与执行到 reference 所在语句时的 PC 之差，所以通常会需要通过 addend 来修正

可以使用 objdump -dx 以在反汇编结果中显示 relocation entry，或者使用 readelf -r 显示所有 relocation entry。

例如，使用 GCC 8.5 编译

int foo(int *arr);

int a[3] = {1, 2, 3};
int *b = &a[2];

int bar()
{
    return foo(&a[1]);
}

int foo(int *arr);

int a[3] = {1, 2, 3};
int *b = &a[2];

int bar()
{
    return foo(&a[1]);
}

readelf -r:

Relocation section '.rela.text' at offset 0x250 contains 2 entries:
  Offset          Info           Type           Sym. Value    Sym. Name + Addend
000000000001  000a0000000a R_X86_64_32       0000000000000008 a + 4
000000000006  000b00000002 R_X86_64_PC32     0000000000000000 foo - 4

Relocation section '.rela.data' at offset 0x280 contains 1 entry:
  Offset          Info           Type           Sym. Value    Sym. Name + Addend
000000000000  000a00000001 R_X86_64_64       0000000000000008 a + 8

Relocation section '.rela.text' at offset 0x250 contains 2 entries:
  Offset          Info           Type           Sym. Value    Sym. Name + Addend
000000000001  000a0000000a R_X86_64_32       0000000000000008 a + 4
000000000006  000b00000002 R_X86_64_PC32     0000000000000000 foo - 4

Relocation section '.rela.data' at offset 0x280 contains 1 entry:
  Offset          Info           Type           Sym. Value    Sym. Name + Addend
000000000000  000a00000001 R_X86_64_64       0000000000000008 a + 8

在 .rela.text 中，a 的 addend 是 4，是直接得到 a[1] 而非 a[0] 的地址；foo 的 addend 是 -4，是因为 reference 的地址是 reference 所在的 jmp 指令的下一条指令的地址减 4，导致 PC 的地址加上 foo 的地址减去 reference 的地址得到的是 foo 的地址加 4，需要 addend 来修正。

Executable Object Files

可执行文件的内容大体上和 relocatable object file 类似，主要的区别是：

在 ELF header 中指定了程序的 entry point
有一个 .init section，定义了一个简单的函数，用来初始化程序
有一个 program header table，描述了程序文件与内存的对应关系，即要把文件的哪一段映射到内存的哪一段，地址如何对齐，以及每一段的权限（.init、.text、.rodata 的权限为 r-x，.data 和 .bss 的权限为 rw-）
.symtab、.debug、.line、.strtab 在执行时不会加载到内存中
如果 fully linked，则没有 .rel section

Loading Executable Object Files

在程序运行时，run-time memory image 大致如下图（CS:APP Figure 7.15）所示：

（errata 中指出，栈的起始地址并不是 $2^{48}-1$ 。）

因为地址对齐、address-space layout randomization 等原因，实际上的内存结构会与上图有一定的差异，但每一段的相对位置是和图中一致的。

loader 加载可执行文件时，首先创建 memory image，然后根据 program header table 将可执行文件的内容映射到内存中，最后跳转到程序的 entry point。C 语言程序的 entry point 是 _start 函数（在 crt1.o 中定义）的地址，_start 又会调用 __libc_start_main 函数（在 libc.so 中定义），进行运行环境的初始化，然后调用 main 函数，最后对返回值进行处理。

Dynamic Linking with Shared Libraries

静态库有一些问题：

更新静态库需要重新链接
每个程序都有一份库的拷贝，会造成空间的浪费

共享库 (shared library) 可以解决这些问题。共享库可以在 run time 或者 load time 被动态链接。动态链接由 dynamic linker 完成。共享库也被称作 shared object，在 Linux 中后缀名为 .so，在 Windows 中被叫做 DLL。

共享库在两个层面上被共享：

在文件系统上只有一份 .so 文件，而在可执行文件中没有库的拷贝
在内存中共享库的 .text section 的单份拷贝可以被多个进程同时使用

可以用类似于 gcc -shared -fpic a.c b.c c.c -o libabc.so 的命令构建共享库。编译选项中 -shared 告诉编译器要生成 shared object，-fpic 用来生成 position-independent code。

可以用类似 gcc main.c ./libabc.so -o main 的命令来使用共享库。

运行 main 时，loader 会在进入 entry point 前在 .interp section 中发现 dynamic linker ld-linux.so，于是让 dynamic linker 完成共享库的 relocation 并修改程序中的 symbol reference，最后将控制权交还给程序。

Loading and Linking Shared Libraries from Applications

除了在编译时指定要链接到的共享库并在 load time 链接，也可以在 run time 加载并使用共享库。

C 语言中的相关函数放在 dlfcn.h 头文件中，编译时需要 -ldl 来使用这些函数：

void *dlopen(const char *filename, int flag): 加载共享库
- 返回值: 成功加载则返回 handle，否则返回 NULL
- filename: 共享库文件名
- flag: 影响如何处理共享库中引用的 external symbol，必须包含 RTLD_NOW 和 RTLD_LAZY 两者之一
  - RTLD_NOW: 立即 resolve 所有 external symbol
  - RTLD_LAZY: 等到运行共享库中的代码时再 resolve external symbol
  - RTLD_GLOBAL: 之后给其他共享库 resolve external symbol 时可以使用当前这个共享库
  如果编译程序时启用了 -rdynamic 选项，在 resolve external symbol 时，除了使用其他加载时启用了 RTLD_GLOBAL 选项的共享库，也可以使用程序自身的 global symbol。
void *dlsym(void *handle, char *symbol): 获得共享库中某个 symbol 的地址
- symbol: symbol 名称
- 返回值: 成功获取则返回 symbol 地址，否则返回 NULL
int dlclose(void *handle): 关闭共享库
- 返回值: 成功关闭则返回 0，出错则返回 -1
const char *dlerror(void): 获取最后一次调用 dlopen / dlsym / dlclose 的报错信息，如果最后一次调用没有出错则返回 NULL

CS:APP 给出了一份参考代码 code/link/dll.c。

Position-Independent Code (PIC)

共享库的一条重要性质是它的代码段在内存中只有一份，而可以被多个进程共享，这就使得它的代码中的 symbol reference 不能在动态链接时被修改，适用于静态链接的 relocation 无法完成，所以共享库的代码需要是 position-independent 的。

PIC 的主要思路基于以下两点：

虽然共享库的代码段是共享的，但数据段是每个进程各有一份的
无论整个共享库被放到内存的哪个位置，代码段和数据段地址的距离是固定的（这与上一条不矛盾，应该是因为虚存）

因此，可以在数据段中存放效果相当于 relocation 的信息，来间接达到 relocation 的效果。说白了就是，因为没法修改代码段，所以把 symbol 的地址放到数据段里。具体实现中，数据段的开头有一个 global offset table (GOT)，表中每一项都是一个地址，可以由 dynamic linker 进行修改，而由于代码段和数据段的地址距离固定，就可以用 PC-relative 的方式寻址到表中的项。

PIC data reference 是简单的，只要在 GOT 中为每个 data symbol (全局或 static 变量) 创建一个表项，在动态链接时由 dynamic linker 修改这些项，而在代码中通过这个表项来间接地进行 data reference，例如 (CS:APP Figure 7.18，GOT[3] 中存放了全局变量 x 的地址)：

    movq Ox2OO8b9(%rip), %rax   # %rax = *GOT[3] = &x
    addl $0x1, (%rax)           # ++x

    movq Ox2OO8b9(%rip), %rax   # %rax = *GOT[3] = &x
    addl $0x1, (%rax)           # ++x

如果是本地定义的变量，也可以使用 PC-relative 的定位方式直接引用，而只对外部定义的变量使用 GOT，但编译器也可能选择不做这样的区分而是使用统一的方法来处理。

PIC procedure call 也可以和 data reference 一样处理（可以用 -fno-plt 编译选项来这样做），但实际上会使用名为 lazy binding 的技术进行优化。

这是因为，链接到一个共享库时，往往最终会调用的只是它提供的大量函数中的一小部分，如果对整个共享库用到的外部函数都在动态链接时计算出相应的 offset，就可能造成浪费。而 lazy binding 则是在第一次调用某个外部函数时绑定这个函数的地址。

lazy binding 基于一个名为 procedure linkage table (PLT) 的结构。PLT 位于代码段中，表中的每一项其实是三条指令，如 CS:APP Figure 7.19 所示：

整个流程就是：

调用 addvec 时，实际上调用的是 PLT[2] 的地址
PLT[2] 的第一条指令会跳转到 GOT[4]，GOT[4] 里一开始放的是 PLT[2] 的第二条指令，所以首次调用 PLT[2] 时就从第一条指令跳到第二条指令
第二条指令是往栈里压入 addvec 的 ID，是用来告诉 dynamic linker 这是哪个函数
第三条指令会跳转到 PLT[0]
PLT[0] 的第一条指令是往栈里压入 relocation entries 的地址，第二条指令是跳转到 dynamic linker
dynamic linker 通过放在栈中的函数的 ID 以及 relocation entries 计算出 addvec 的地址，放在 GOT[4]，然后跳转到 addvec
因为一路上都是 jmp，跳转到 addvec 后可以正常返回到调用 PLT[2] 的位置
第二次调用 PLT[2] 时，GOT[4] 里已经是 addvec 的地址，所以就在 PLT[2] 的第一条指令处跳转到了 addvec

Library Interpositioning

Linux 的链接器支持一个名为 library interpositioning 的技术，可以用来把共享库的函数替换掉，一般会换成一个 wrapper function 用来 trace，但也可以换成完全不同的东西。

看了下中文版 CS:APP，这个东西竟然叫“库打桩”（

编译时的 library interpositioning 就是用 #define 换掉某个函数 ~~，在机房里被 #define sort random_shuffle 过的大家想必对此非常熟悉~~。

链接时的 library interpositioning 是给 linker 传参 --wrap foo，然后调用 foo 就会实际上调用 __wrap_foo，而调用 __real_foo 则会调用原本的 foo。一般会给 gcc 而非 ld 传参，就是用 gcc -Wl,--wrap,foo 代替 ld --wrap foo，其中 -Wl 表示给 linker 传参，后面的逗号会被换成空格。

运行时的 library interpositioning 是在运行程序时设置环境变量 LD_PRELOAD="/path/to/wrapper.so /path/to/anotherwrapper.so"，然后在使用任意共享库中的函数之前就会优先尝试使用 wrapper.so 和 anotherwrapper.so。这时，为了能在 wrapper function 中调用原本的函数，就需要在运行时加载共享库。

如果想看具体实现，可以参考 CS:APP。

编译时的 library interpositioning 需要修改源代码，链接时的 library interpositioning 需要获取到 object file 并重新链接得到可执行文件，而运行时 library interpositioning 只需要设置环境变量，不需要对可执行文件进行任何修改，可以方便地对很多不同程序的某个函数调用进行跟踪。

CS:APP 第四章学习笔记

Mon, 17 Oct 2022 02:30:45 GMT

CS:APP 第四章 “Processor Architecture” 的学习笔记。

这章的主要内容为一个简化的指令集 Y86-64 的设计以及 Y86-64 处理器的实现（顺序实现和 pipeline 实现）。

The Y86-64 Instruction Set Architecture

这部分定义了在这一章中用作演示的名为 “Y86-64” 的玩具 ISA。

Y86-64 程序状态

15 个寄存器（x86-64 的寄存器除去 %r15，为了简化编码）
3 个 status flag: ZF、SF、OF
program counter: PC
memory
status code: Stat，用来表示程序正常运行或发生了异常

Y86-64 指令

Y86-64 指令大致上是 x86-64 的一个子集，但在 operand 等方面有一些简化或区别。

operand 与 x86-64 的区别是：

Immediate、Register、Memory 都只有 64 位的版本
Register 只有 15 个
Memory 不支持 (, ri, s) 的部分，只能是 Imm/(rb)/Imm(rb)

condition code 只有六个，即 signed compare: le/l/e/ne/ge/g

指令列表，以及与 x86-64 的区别：

irmovq/rrmovq/mrmovq/rmmovq，即将 movq 按 operand 类型拆成了四个指令
addq/subq/andq/xorq，它们只接受寄存器作为 operand，且只设置 ZF、SF、OF 三个 status flag
jmp/jle/jl/je/jne/jge/jg，包括 jmp 在内都只能跳转到固定的地址，不接受寄存器作为 operand，且这个地址是绝对地址而非相对于 PC 的地址
cmovle/cmovl/cmove/cmovne/cmovge/cmovg，它们只接受寄存器作为 operand
call: 地址是绝对地址
ret、pushq、popq、nop: 与 x86-64 基本相同
halt: 停止运行，将 status code 设为 HLT

Y86-64 指令编码

Y86-64 通过对指令的简化，同时也使编码得到了简化，但相应地使得编码不紧凑，会有浪费。

CS:APP Figure 4.2 简明地展示了 Y86-64 的指令编码：

指令类型的编码

指令编码的第一个 byte 表示指令的类型。这个 byte 的高位叫做 code，低位叫做 function，其中 function 只在某几个指令有用。特别地，rrmovq 和 cmovXX 的 code 是相同的，这表示 rrmovq 可以看作一种特殊的 cmovXX。

算术运算的 function: add 0, sub 1, and 2, xor 3

condition code 的 function: le 1, l 2, e 3, ne 4, ge 5, g 6；jmp 的 function 为 0

Register Specifier Byte

除了 jXX 和 call，指令编码的第二个 byte（如果有）的高低位分别表示一个 register identifier。

Constant Word

在 irmovq、rmmovq/mrmovq、jXX/call 中，分别有一个 8-byte 的 constant word，用来表示 immediate value 或地址，byte ordering 是 little endian。

Y86-64 异常

status code Stat 有四种可能的取值：

AOK: 正常
HLT: 执行了 halt 指令
ADR: 访问了不合法的地址
INS: 指令编码不合法

在 Y86-64 中，遇到异常后处理器会立即停止运行。

Y86-64 程序

CS:APP Figure 4.8 展示了一个完整的 Y86-64 程序：

可以下载 Y86-64 tools 并使用 yas 进行汇编，使用 yis 模拟运行。编译 yas 时需要添加 -fcommon 编译选项。

对 %rsp 进行 push/pop

pushq %rsp、popq %rsp 这两条指令虽然没什么用，但它们的行为可能有歧义，所以在设计 ISA 时明确规定它们的行为是有必要的。

Y86-64 遵循和 x86-64 相同的规则：pushq %rsp 会将旧的（没有减 8 的）%rsp 的值入栈，popq %rsp 相当于 mrmovq (%rsp), %rsp。

Logic Design and the Hardware Control Language HCL

这一章中使用玩具语言 HCL (hardware control language) 来描述 Y86-64 处理器的逻辑设计。（与之类似但不是玩具的语言，例如 VHDL、Verilog 等，叫做 “hardware description language (HDL)”。）

逻辑门

CSAPP Figure 4.9:

图中只展示了输入个数为 2 的 AND 和 OR，但可以有更多输入
一旦输入改变，逻辑门的输出很快就会随之改变

组合逻辑电路

组合逻辑电路即由若干逻辑门组合而成的电路，它的特点是无状态，输出仅与输入有关，输入改变后输出很快就会随之改变。

在 HCL 中，用逻辑表达式来表示组合逻辑电路，例如 bool eq = (a && b) || (!a && !b) 表示计算 a、b 是否相等的电路。因为它表示的是电路而不是计算，在这条语句之后，一旦 a、b 的值发生改变，eq 的输出也会改变（和 Vue 的 computed 类似）。

以 word 为单位进行操作的电路

在处理器的设计中，经常需要对一个 word 而非单个 bit 进行操作。

在 HCL 中，一般使用大写的名称表示 word，例如: bool Eq = (A == B) 表示计算 word A、B 是否相等的电路，可以实现为判断每个 bit 是否相等再 AND。

Multiplexor (MUX)

multiplexor (MUX) 的功能是通过信号输入的值来在其它输入中选择一个作为输出，word-level 的 MUX 电路如图 (CSAPP Figure 4.13)：

在 HCL 中，使用 case expressions 表示 MUX，例如

word Mux = [
    !s1 && !s0: A;
    !s1: B;
    !s0: C;
    1: D;
];

word Mux = [
    !s1 && !s0: A;
    !s1: B;
    !s0: C;
    1: D;
];

表示一个由 s0 和 s1 控制的、在 A、B、C、D 中选一个作为输出的 MUX。

case expression 在逻辑上的语义是依次判断每个条件，以第一个满足的条件作为输出，类似于 Rust 的 match。

下面的 HCL 代码表示计算 A、B、C 中的最小值：

word Min3 = [
    A <= B && A <= C: A;
    B <= C: B;
    1: C;
];

word Min3 = [
    A <= B && A <= C: A;
    B <= C: B;
    1: C;
];

Arithmetic/logic unit (ALU)

ALU 是用来进行算术/逻辑运算的组合逻辑电路元件，它接收两个 data input 以及一个表示进行何种运算的 control input，输出运算的结果。

测试值是否属于集合

在 HCL 中，可以使用 in 来表示测试值是否属于集合的电路，例如:

bool s1 = code in { 2, 3 };
bool s0 = code in { 1, 3 };

bool s1 = code in { 2, 3 };
bool s0 = code in { 1, 3 };

Memory and Clocking

组合逻辑电路是无状态且实时更新的；与之相对，memory 可以存储状态，但更新由 clock 控制。

这一章中会用到的 memory 有两大种三小种：

clocked register: 存储一个值，有一个输入和一个输出。输出即存储的值，而每次 clock rise 时会将存储的值修改为输入。
random access memory:
- register file: 存储 15 个值（在 Y86-64 处理器中），有两个 read port 和一个 write port：
  - 每个 read port 有一个输入 src 表示 register identifier，有一个输出 val 表示这个 register 存储的值，且 src 改变后 val 会立刻改变。
  - write port 有一个输入 dst 表示 register identifier，另有一个输入 val 用于写入。每次 clock rise 时，如果 dst 不是 F 就会将 val 写入相应的 register。
- data memory: 存储很多个值，用地址进行索引。
  - 有一个地址输入 address。
  - 有一个信号输入 write 表示进行写入而非读取。
  - 有一个数据输出 data out。若 write 为 0，data out 会立刻输出 address 处存储的值。
  - 有一个数据输入 data in。若 write 为 1，在 clock rise 时会将 data in 写入 address 处。
  - 有一个信号输出 error，在 address 不是合法地址时输出 1。

可以看到，这几种 memory 的共同点是读取是实时的，但写入由 clock 控制。

在 Y86-64 的程序状态中，寄存器存在 register file 中，status flags、program counter、status code 存在 clocked register 中，memory 存在 data memory 中。

Y86-64 处理器还有一个额外的 read-only instruction memory 用来读取指令，而在真实的处理器中这是和内存一体的。

Sequential Y86-64 Implementations

这一节会实现一个名为 SEQ 的顺序执行的处理器。在这个处理器中，指令是按顺序一条接着一条执行的，且每条指令都会在一个 clock cycle 内执行完毕，这要求 clock cycle 很长，会导致处理器的执行很慢，下两节将对此进行优化。

指令执行的阶段划分与具体操作

将指令的执行划分为多个阶段，可以使行为有很大差别的不同指令有一定的统一性，方便硬件实现。

本节会将指令执行划分为六个阶段：

Fetch: 将指令编码中不同部分的值读取出来
Decode: 读取寄存器的值（我感觉 fetch 和 decode 这两个名字互换一下才比较对 🤔）
Execute: 执行运算
Memory: 写入或读取内存
Write back: 写入寄存器
PC update: 更新 program counter

每个指令每阶段的具体操作如图（CS:APP Figure 4.18~4.21、Solution 4.17）：

SEQ 的主体电路

CS:APP Figure 4.23 大致展示了 SEQ 的主体电路：

其中蓝色的元件是 black box，灰色的元件会在后面进行设计，还有部分电路连接没有画出来。

这个电路大概看着有个印象即可，细节会在后面说明。

SEQ 的时序控制

在 SEQ 中，每个时钟周期执行一条指令，而时钟控制的只有各种 memory 的写入，memory 的读取和运算都是用组合逻辑电路实现的，虽然在逻辑上有执行顺序，在电路上却是同时执行的，可以看成一个关于 memory 的函数。

也就是说，整个执行过程是：读取 memory 并计算出需要写入 memory 的值，然后在 clock rise 时执行写入，从而读取到新的 memory 的值而执行下一条指令。

为了这个设计能够实现，一条重要的原则是 “No reading back”，即一条指令不能先更新再读取同一个值。例如，在 pushq 中，不是先更新 R[%rsp] 再写入 M[R[%rsp]]，而是先算出 valE，再写入 M[valE]，最后将 valE 写入 R[%rsp]。又例如，有的指令会修改 status flags，有的会读取，但没有指令既修改又读取。

因为运算都是同时进行的，执行的六个阶段实际上是六个部分。