1.14 计算机组成与三套 ISA：x86-64 / ARM64 / RISC-V 64

1.14.1 从门到指令：组成的最小模型

一台能跑 Linux 的机器，抽象到足够写系统程序，只需要五件东西：

  CPU
  ├── 寄存器文件（16/31 个通用寄存器 + PC + 标志）
  ├── ALU / 乘法器 / 浮点单元
  ├── 控制单元（取指、译码、发射、退休）
  └── MMU（页表基址、TLB、权限检查）
        │
        ├── L1 I/D cache ── L2 ── L3 ── DRAM
        └── 中断控制器（APIC/GIC/PLIC）── 定时器、设备

程序执行的最小循环是：

PC → 取指 → 译码 → 取操作数 → 执行 → 访存 → 写回 → PC+4/跳转

现代 CPU 把这条顺序流水拆成十几级，并允许乱序执行；但对程序员可见的语义仍然是「一条指令接着一条指令，寄存器与内存按序变化」。编译器和内核都依赖这个假象，只有内存屏障、原子指令和 volatile/asm! 才需要关心真实顺序。

1.14.2 ISA 是什么：寄存器、指令格式与特权级

ISA（instruction set architecture）是软件与硬件的契约，规定：

• 有哪些寄存器、各自位宽与用途；
• 指令如何编码（定长/变长）、有哪些寻址方式；
• 哪些指令只能在特权级运行（syscall/svc/ecall、in/out、页表写）；
• 内存模型（强/弱序）、原子指令、异常/中断入口；
• 调用约定（ABI）虽然不属于 ISA，但由 ISA 的寄存器与栈规则派生。

三套 ISA 的骨架：

1.14.3 同一段 C，三种汇编

先看一个足够小、又能暴露调用约定差异的函数：

/* sum3.c — 三个 long 相加；编译：cc -O2 -S sum3.c */
long sum3(long a, long b, long c)
{
    return a + b + c;
}

# x86-64 SysV：a=rdi, b=rsi, c=rdx, 返回=rax
sum3:
    lea    (%rdi,%rsi), %rax   # rax = a + b
    add    %rdx, %rax          # rax += c
    ret

// ARM64 AAPCS64：a=x0, b=x1, c=x2, 返回=x0
sum3:
    add    x0, x0, x1          // x0 = a + b
    add    x0, x0, x2          // x0 += c
    ret                        // 跳回 x30

# RISC-V psABI：a0/a1/a2，返回 a0
sum3:
    add    a0, a0, a1          # a0 = a + b
    add    a0, a0, a2          # a0 += c
    ret                        # jalr x0, 0(ra)

#![allow(unused)]
fn main() {
// sum3.rs — 与 C 版本等价；rustc -O --emit asm sum3.rs
#[no_mangle]
pub extern "C" fn sum3(a: i64, b: i64, c: i64) -> i64 {
    a + b + c
}
}

三份汇编的差别不在「加法怎么做」，而在参数放在哪、返回值放哪、返回地址放哪。这就是 ABI；ISA 只规定寄存器存在，ABI 规定谁负责保存。

1.14.4 调用约定：三张表

1.14.5 系统调用入口：三种指令

# write(1, msg, len) — x86-64 Linux
    mov    $1, %rax            # SYS_write
    mov    $1, %rdi            # fd = stdout
    lea    msg(%rip), %rsi     # buf
    mov    $len, %rdx          # count
    syscall                    # 返回 rax；失败为 -errno

// write(1, msg, len) — ARM64 Linux
    mov    x8, #64             // SYS_write
    mov    x0, #1              // fd
    adr    x1, msg             // buf
    mov    x2, #len            // count
    svc    #0                  // 返回 x0；失败为 -errno

# write(1, msg, len) — RISC-V 64 Linux
    li     a7, 64              # SYS_write
    li     a0, 1               # fd
    la     a1, msg             # buf
    li     a2, len             # count
    ecall                      # 返回 a0；失败为 -errno

1.14.6 编译到三套架构：工具链与验证

# 本机架构
cc -O2 -S sum3.c -o sum3.s

# 交叉编译（需要对应 gcc/clang 与 sysroot）
aarch64-linux-gnu-gcc -O2 -S sum3.c -o sum3-arm64.s
riscv64-linux-gnu-gcc -O2 -S sum3.c -o sum3-riscv64.s

# Clang 直接指定 target（不需要完整 sysroot 也能看汇编）
clang --target=aarch64-linux-gnu -O2 -S sum3.c -o sum3-arm64.s
clang --target=riscv64-linux-gnu -O2 -S sum3.c -o sum3-riscv64.s

# 反汇编与 ELF 信息
objdump -d sum3
readelf -h sum3

没有硬件时，用 QEMU 用户态跑：

qemu-aarch64 -L /usr/aarch64-linux-gnu ./sum3
qemu-riscv64 -L /usr/riscv64-linux-gnu ./sum3

1.14.7 时钟与功耗：一条指令的时间下限

这一节回答：一条指令最快能多快执行完？为什么主频停在 5 GHz 附近而不是继续翻倍？

1.14.7 讲了 CMOS 反相器与 P ≈ αCV²f 的定性结论。真正决定频率的是一个环路的最长组合路径：

$$T_{\text{clk}} \ge T_{\text{cq}} + T_{\text{logic,max}} + T_{\text{setup}} + T_{\text{skew}} + T_{\text{jitter}}.$$

T_cq 是触发器时钟到输出的延迟，T_logic,max 是关键路径上所有门与连线的延迟之和，T_setup 是触发器建立时间。后两项是物理世界的税：时钟树到达不同触发器的时间不一致（skew），电源噪声与温度让周期抖动（jitter）。设计者必须按最坏情况留余量，所以标称 5 GHz 的芯片，实际可持续频率往往只有 4.2–4.6 GHz。

手算一个 7 nm 处理器核：T_cq=30 ps、关键路径 14 级 FO4（每级 9 ps，共 126 ps）、连线 40 ps、T_setup=20 ps、skew 15 ps、jitter 10 ps，则

$$T_{\text{clk}} \ge 30+126+40+20+15+10 = 241\ \text{ps},\qquad f_{\max} \le 4.15\ \text{GHz}.$$

想把频率抬到 5 GHz（200 ps），只能砍逻辑深度（加深流水线）或换更快的工艺；前者会增加分支误预测惩罚，后者会增加漏电。这就是 1.14.8 要算的账。

表里的数字是公开资料的数量级，具体库、电压点、温度都会让结果偏移 20% 以上。不要用工艺节点名直接比较频率：Intel 7、TSMC N7、Samsung 7LPP 的命名不是同一个物理量。

功耗分两块：

$$P_{\text{total}} = \underbrace{\alpha C_{\text{eq}} V^2 f}_{\text{动态}} + \underbrace{I_{\text{leak}} V}_{\text{静态}}.$$

一颗 3 GHz、1.0 V、等效开关电容 200 nF、活动因子 0.1 的芯片，动态功耗是 $0.1 \times 200,\text{nF} \times 1^2 \times 3,\text{GHz} = 60$ W；漏电再占 25%，总功耗 80 W。把电压降到 0.85 V，动态功耗按 $V^2$ 降到 43 W，但 f_max 也会下降——降压与提频不能同时要。

cat > freq.c <<'EOF'
#include <stdio.h>
int main(void)
{
    volatile long x = 1;          /* volatile 防止整段被优化掉 */
    for (long i = 0; i < 1000000000L; i++)
        x = x + 1;                /* 依赖链：每次加法等上一次结果 */
    printf("%ld\n", x);
    return 0;
}
EOF
cc -O2 freq.c -o freq
/usr/bin/time -f '%e s' ./freq
perf stat -e cycles,instructions ./freq

1.14.8 五级流水线：理想 CPI 与真实惩罚

这一节回答：为什么 5 级流水线跑 5 条指令只要 9 个周期，而实际程序却常常 CPI 大于 1？

经典五级流水把一条指令拆成 IF、ID、EX、MEM、WB。相邻指令在不同级重叠：

周期      1   2   3   4   5   6   7   8   9
I1       IF  ID  EX  MEM  WB
I2           IF  ID  EX  MEM  WB
I3               IF  ID  EX  MEM  WB
I4                   IF  ID  EX  MEM  WB
I5                       IF  ID  EX  MEM  WB

n 条指令、k 级流水、无停顿的理想周期数是 $k + (n-1)$。5 条指令 9 个周期，1000 条指令 1004 个周期，CPI 是 1.004，相对非流水线的 5000 周期加速 4.98 倍，极限是 5。公式：

$$\text{cycles} = k + (n-1) + \text{stalls},\qquad \text{CPI} = 1 + \frac{\text{stalls}}{n}.$$

停顿来自三类冒险：

转发能把 EX 的结果直接送到下一条指令的 EX 输入，所以大多数 RAW 不需要停顿；但 load 的数据要到 MEM 末尾才可用，下一条若在 EX 就要用，只能停一拍。编译器把「加载」尽量提前，就是在填这一拍。

分支预测的基本单位是 2 位饱和计数器：四个状态（强不跳、弱不跳、弱跳、强跳）按实际方向每次移动一格，只有跨过中点才改变预测。两位状态让预测器在循环边界只错两次（进入与退出），而不是每次迭代都错。现代处理器用 TAGE/ITTAGE 一类的多表历史预测器，把全局分支历史哈希进多个表，准确率可以到 97–99%；返回地址栈（RSB）专门预测 ret。

把准确率代进 CPI：分支占 20%，误预测惩罚 15 拍，则

这张表说明：分支密集的代码，预测准确率从 99% 掉到 90%，性能损失约 26%；而把误预测率从 5% 压到 1%，只能收回 12%。优化要挑「占比大、惩罚重」的那一项。

#include <stdio.h>
#include <stdlib.h>
static int cmp(const void *a, const void *b)
{
    int x = *(const int *)a, y = *(const int *)b;
    return (x > y) - (x < y);
}
int main(int argc, char **argv)
{
    enum { N = 1 << 15 };
    static int a[N];
    unsigned seed = 1;
    for (int i = 0; i < N; i++) {
        seed = seed * 1103515245u + 12345u;
        a[i] = (int)((seed >> 16) & 0xff);
    }
    if (argc > 1 && argv[1][0] == 's')
        qsort(a, N, sizeof a[0], cmp);
    long sum = 0;
    for (int i = 0; i < N; i++)
        if (a[i] >= 128)
            sum += a[i];
    printf("%ld\n", sum);
    return 0;
}

cc -O2 -std=c17 -D_GNU_SOURCE -Wall -Wextra -Werror branch.c -o branch
perf stat -e branches,branch-misses ./branch        # 随机
perf stat -e branches,branch-misses ./branch s      # 排序

1.14.9 乱序执行：窗口、重命名与依赖链

这一节回答：CPU 如何在等待一次 cache miss 的同时继续执行后面的指令？为什么「四条累加链」比「一条累加链」快四倍？

乱序执行把流水线分成前端与后端：

前端按程序顺序取指、译码、重命名；后端在操作数就绪时乱序发射，但退休必须按程序顺序。这样异常和中断看到的仍是顺序语义，编译器不需要知道真实的执行顺序。

重命名消除了 WAW/WAR：mov %rax,%rbx 再 mov %rcx,%rax 写的是不同的物理寄存器，逻辑寄存器同名也不冲突。真正限制并行的是 RAW 依赖链：

若循环是 sum += a[i] 且 sum 是 float，每次加法要等上一次的 4 拍，吞吐被压到 0.25 条/拍。拆成 4 条独立累加链，4 条链可以同时在 4 个周期后各自出结果，平均 1 条/拍；拆成 8 条，达到 2 条/拍的发射上限。这就是「提高指令级并行」最朴素的手法：把一条长依赖链拆成几条短链。

clang --target=x86_64-linux-gnu -O2 -S sum.c -o sum.s
llvm-mca -mtriple=x86_64-linux-gnu -mcpu=skylake sum.s

1.14.10 Cache 地址拆分与 AMAT：手算一个组相联缓存

这一节回答：给定缓存容量、块大小、相联度，一个地址落到哪个组？一次访存平均要多少拍？

设 L1 数据缓存 32 KiB、8 路组相联、块 64 B，虚拟地址 48 位：

$$\text{sets} = \frac{32,\text{KiB}}{8 \times 64,\text{B}} = 64,\qquad \text{offset} = \log_2 64 = 6,\qquad \text{index} = \log_2 64 = 6,\qquad \text{tag} = 48 - 6 - 6 = 36.$$

地址从高到低拆成 tag(36) | index(6) | offset(6)。取 0x0000_7fff_1234_5678：

同一组的地址只要求 index 相同，也就是低 12 位中的第 6–11 位相同。下面三个地址都映射到组 25：

8 路意味着一个组只能放 8 个 tag。如果程序用 9 个相距 4 KiB 的数组同时顺序扫描，第 9 个流会把最早的那个 tag 挤出去，之后每次访问都 miss——这就是冲突缺失（conflict miss），容量明明够却用不上。把数组间距改成 4 KiB + 64 B，或者把 9 个流分块处理，就能避开。

平均访存时间（AMAT）按层展开：

$$\text{AMAT} = t_{L1} + m_{L1}\left(t_{L2} + m_{L2}\left(t_{L3} + m_{L3},t_{\text{DRAM}}\right)\right).$$

设 L1 命中 4 拍、局部缺失率 5%；L2 命中 12 拍、局部缺失率 20%；L3 命中 40 拍、局部缺失率 10%；DRAM 200 拍：

$$\text{AMAT} = 4 + 0.05\left(12 + 0.2\left(40 + 0.1 \times 200\right)\right) = 4 + 0.05(12 + 0.2 \times 60) = 5.2\ \text{拍}.$$

把 L1 缺失率从 5% 降到 2%，AMAT 变成 $4 + 0.02 \times 24 = 4.48$ 拍，快 14%；把 L2 命中时间从 12 拍降到 8 拍，AMAT 只变成 $4 + 0.05 \times 20 = 5.0$ 拍，快 4%。降低缺失率通常比降低命中时间更划算，因为缺失代价被放大了一次。

getconf -a | grep -E 'LEVEL1_DCACHE_(SIZE|LINESIZE|ASSOC)'
cat > stride.c <<'EOF'
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
static double now_ns(void)
{
    struct timespec ts;
    clock_gettime(CLOCK_MONOTONIC, &ts);
    return (double)ts.tv_sec * 1e9 + (double)ts.tv_nsec;
}
int main(int argc, char **argv)
{
    size_t n = 1u << 26;                 /* 64 MiB，远超 L3 */
    size_t stride = argc > 1 ? strtoul(argv[1], NULL, 0) : 1;
    int *a = malloc(n * sizeof *a);
    if (!a) return 1;
    for (size_t i = 0; i < n; i++) a[i] = 1;
    size_t steps = 0;
    long sum = 0;
    double t0 = now_ns();
    for (size_t i = 0; i < n; i += stride) { sum += a[i]; steps++; }
    double t1 = now_ns();
    printf("stride=%zu steps=%zu %.2f ns/elem sum=%ld\n",
           stride, steps, (t1 - t0) / (double)steps, sum);
    free(a);
    return 0;
}
EOF
cc -O2 -std=c17 -D_GNU_SOURCE -Wall -Wextra -Werror stride.c -o stride
for s in 1 16 1024 8192; do ./stride $s; done
perf stat -e L1-dcache-loads,L1-dcache-load-misses,LLC-loads,LLC-load-misses ./stride 1

1.14.11 三架构栈帧：第 7 个参数之后

这一节回答：参数超过 6 个、函数又有局部变量时，三套 ABI 的栈帧如何排布？为什么同一个第 7 参数在三种架构上的偏移不同？

1.14.11 给了六个参数以内的对照。把第 7、8 个参数和局部变量一起看，差异才完整：x86-64 的栈上第一个字是返回地址，ARM64/RISC-V 的第一个字就是第 7 个参数。

栈的形状可以先记一句话：x86-64 的 [rbp+8] 是返回地址，第 7 个参数从 [rbp+16] 开始；ARM64/RISC-V 没有栈上的返回地址，第 7 个参数就在入口的 [sp]，建帧后移到 [sp+32]。

下面三个版本是同一函数：8 个 long 参数、两个局部变量、一次对 helper 的调用。注意第 7/8 参数的偏移，以及保存返回地址的位置。

# long f(long a,...,long h)；a=rdi b=rsi c=rdx d=rcx e=r8 f=r9
# 入口：[rsp]=返回地址，[rsp+8]=g，[rsp+16]=h
    .text
    .globl f
    .type f, @function
f:
    pushq   %rbp
    movq    %rsp, %rbp
    subq    $32, %rsp          # 2 个局部变量 + 对齐
    movq    %rdi, -8(%rbp)     # local x
    movq    %rsi, -16(%rbp)    # local y
    movq    16(%rbp), %rax     # g
    addq    24(%rbp), %rax     # h
    call    helper
    leave                      # mov rbp,rsp; pop rbp
    ret

// 入口：sp 指向 g；[sp]=g，[sp+8]=h
    .text
    .globl f
    .type f, %function
f:
    stp     x29, x30, [sp, #-32]!   // 预索引：先减 sp，再存
    mov     x29, sp
    str     x0, [sp, #16]           // local x
    str     x1, [sp, #24]           // local y
    ldr     x9, [sp, #32]           // g（sp 已减 32）
    ldr     x10, [sp, #40]          // h
    add     x0, x9, x10
    bl      helper
    ldp     x29, x30, [sp], #32     // 后索引：先取，再加 sp
    ret

# 入口：sp 指向 g；[sp]=g，[sp+8]=h
    .text
    .globl f
    .type f, @function
f:
    addi    sp, sp, -32
    sd      ra, 24(sp)          # 返回地址
    sd      s0, 16(sp)          # 帧指针
    sd      a0, 0(sp)           # local x
    sd      a1, 8(sp)           # local y
    ld      t0, 32(sp)          # g
    ld      t1, 40(sp)          # h
    add     a0, t0, t1
    call    helper              # auipc ra, ...; jalr ra
    ld      ra, 24(sp)
    ld      s0, 16(sp)
    addi    sp, sp, 32
    ret

参数超过寄存器数量只是第一层。结构体按值传递时，三套 ABI 用不同的分类规则：

1.14.12 指令编码：手算三种格式

这一节回答：给定一条汇编，怎样不查汇编器就写出它的字节？三种 ISA 的字段布局差在哪？

x86-64 先看一条带 SIB 的访存指令：mov 0x10(%rdi,%rsi,4),%eax。它的字节是 8b 44 b7 10：

有效地址是 rdi + rsi*4 + 0x10。ModR/M 的 reg 字段不总是寄存器：某些 opcode 把它当扩展操作码（例如 FF /2 是 call），读手册时要看 opcode 的 /digit 记法。

ARM64 是定长 32 位，字段位置固定。add x0, x0, x1 的编码是 0x8B010000：

拼起来：1000 1011 0000 0001 0000 0000 0000 0000。ldr x0,[x1,#8] 是 0xF9400420，字段为 size=11、111001、opc=01、imm12=1（8/8）、Rn=1、Rt=0。注意 add x0,x0,#1 是 0x91000400，和寄存器版只差几个位，但属于不同编码族——手算时先确定「立即数还是寄存器」。

RISC-V 有 6 种基本格式，立即数被拆开存放：

add a0,a0,a1 是 R 型：funct7=0000000、rs2=01011、rs1=01010、funct3=000、rd=01010、opcode=0110011，拼出 0x00B50533。addi a0,a0,1 是 I 型：imm=1、rs1=01010、funct3=000、rd=01010、opcode=0010011，得到 0x00150513。sd ra,8(sp) 是 S 型：imm[11:5]=0、rs2=00001、rs1=00010、funct3=011、imm[4:0]=01000、opcode=0100011，得到 0x00113423。B 型的立即数按 imm[12|10:5|4:1|11] 打散，bne a0,a1,+8 是 0x00B51463。

printf '\x8b\x44\xb7\x10' > /tmp/m.bin
objdump -D -b binary -m i386:x86-64 /tmp/m.bin
echo 'add x0, x0, x1'   | llvm-mc -triple=aarch64 -show-encoding
echo 'ldr x0, [x1, #8]' | llvm-mc -triple=aarch64 -show-encoding
echo 'add a0, a0, a1'   | llvm-mc -triple=riscv64 -show-encoding
echo 'sd ra, 8(sp)'     | llvm-mc -triple=riscv64 -show-encoding
clang --target=riscv64-linux-gnu -c enc.s -o enc.o && llvm-objdump -d enc.o

1.14.13 RISC/CISC 与内存模型：litmus 实验

这一节回答：同样是「先写 X 再读 Y」，为什么 x86 上可以观察到 r1=r2=0，而直觉上的顺序执行不该出现这个结果？

RISC 与 CISC 的边界今天是模糊的：x86 前端把变长指令译成 µop，内部像 RISC；ARM64 也加入了复杂的寻址与向量指令。真正的差别在译码成本、代码密度与生态：x86 平均 3–4 字节一条指令、译码要预译码器；ARM64/RISC-V 定长 4 字节、字段固定，但 RISC-V 的 C 扩展又把常用指令压回 2 字节。

内存模型是比指令集更容易被忽略的契约。四类重排在三种架构上的允许情况：

经典 Dekker litmus：

初始：X = 0, Y = 0
P0:  X = 1;  r1 = Y;
P1:  Y = 1;  r2 = X;

x86 的 TSO 只允许 Store→Load 重排，所以 r1=r2=0 是可能出现的；要排除它，必须在两次访问之间加 mfence（或把 store 换成 xchg）。ARM64/RISC-V 允许更多重排，需要 dmb ish/fence，或者使用带 acquire/release 语义的指令。

C11 的写法不依赖具体架构：

#include <stdatomic.h>
static atomic_int x, y, r1, r2;

void *p0(void *arg)                        /* p1 与 p0 对称：Y=1; fence; r2=X */
{
    (void)arg;
    atomic_store_explicit(&x, 1, memory_order_relaxed);
    atomic_thread_fence(memory_order_seq_cst);
    r1 = atomic_load_explicit(&y, memory_order_relaxed);
    return 0;
}

把 p0/p1 各跑一百万轮、统计 r1==0 && r2==0 的次数，就能看到重排（x86 上需要很多轮才出现一次）。真正严谨的验证用 herd7 的架构模型（herd7 -model x86tso.cat dekker.litmus），而不是真机碰运气。

# 全屏障：mfence 之前的 load/store 不能越过它
    mfence

// 全屏障；ish = inner shareable 域
    dmb    ish

# 读写屏障；fence rw,rw 约束所有 load/store
    fence  rw, rw

1.14.14 三架构实验：从 C 到字节

这一节回答：怎样用一条可重复的流水线，把同一段 C 变成三套汇编、三份 ELF，并核对指令数、编码与系统调用？

实验 A：同一函数的三套代码。 仍用 sum3.c：

for t in x86_64 aarch64 riscv64; do
  clang --target=$t-linux-gnu -O2 -S sum3.c -o sum3-$t.s
  clang --target=$t-linux-gnu -O2 -c sum3.c -o sum3-$t.o
  printf '%-9s ' "$t"
  llvm-objdump -d sum3-$t.o | awk '/^[[:space:]]+[0-9a-f]+:/{n++; b++} END{print n" insn"}'
  llvm-size -A sum3-$t.o | awk '/\.text/{print "text="$2}'
done

同一个函数，x86 用 8 字节，ARM64 用 12 字节；RISC-V 关闭压缩时 12 字节，默认 rv64gc 只 6 字节。只看「指令条数」，差异被完全掩盖：评估代码密度要看字节数，评估译码压力要看指令条数与格式。

实验 B：不依赖 libc 的 hello。 三个版本都只用到 write 与 exit：

    .section .rodata
msg:    .ascii "hello\n"
len = . - msg
    .text
    .globl _start
_start:
    mov     $1, %rax            # SYS_write
    mov     $1, %rdi            # stdout
    lea     msg(%rip), %rsi
    mov     $len, %rdx
    syscall
    mov     $60, %rax           # SYS_exit
    xor     %rdi, %rdi
    syscall

    .section .rodata
msg:    .ascii "hello\n"
len = . - msg
    .text
    .globl _start
_start:
    mov     x8, #64             // SYS_write
    mov     x0, #1              // stdout
    adr     x1, msg
    mov     x2, #len
    svc     #0
    mov     x8, #93             // SYS_exit
    mov     x0, #0
    svc     #0

    .section .rodata
msg:    .ascii "hello\n"
len = . - msg
    .text
    .globl _start
_start:
    li      a7, 64              # SYS_write
    li      a0, 1               # stdout
    la      a1, msg
    li      a2, len
    ecall
    li      a7, 93              # SYS_exit
    li      a0, 0
    ecall

aarch64-linux-gnu-gcc -nostdlib -static hello-arm64.S -o hello-arm64
riscv64-linux-gnu-gcc -nostdlib -static hello-riscv64.S -o hello-riscv64
cc -nostdlib -static hello-x86_64.S -o hello-x86_64
./hello-x86_64
qemu-aarch64 -strace ./hello-arm64
qemu-riscv64 -strace ./hello-riscv64

-strace 的输出形如：

0 write(1,0x4000c8,6) = 6
0 exit(0)

系统调用号分别是 1/64/64，参数寄存器分别是 rdi,rsi,rdx / x0,x1,x2 / a0,a1,a2；三份 ELF 的 Machine 不同（62/183/243），但 write(1, "hello\n", 6) 的语义相同。

1.14.15 代码尺寸与性能：同一算法的三套指令账

同一段 C 编到三套 ISA，指令数、代码字节数、寄存器压力都不一样。不要凭感觉判断「谁更快」，先量三个数：

一个可复现的对照：

/* size_lab.c — 同一函数的三种写法 */
long sum_array(const long *a, int n) {
    long s = 0;
    for (int i = 0; i < n; i++) s += a[i];
    return s;
}
long sum_unrolled(const long *a, int n) {
    long s = 0; int i = 0;
    for (; i + 4 <= n; i += 4) s += a[i] + a[i+1] + a[i+2] + a[i+3];
    for (; i < n; i++) s += a[i];
    return s;
}

for t in x86_64-linux-gnu aarch64-linux-gnu riscv64-linux-gnu; do
  clang --target=$t -O2 -c size_lab.c -o size-$t.o
  echo "$t $(llvm-size size-$t.o | awk 'NR==2{print $1}')"
  llvm-objdump -d --triple=$t size-$t.o | grep -c '^ *[0-9a-f]*:'
done

预期量级：x86-64 的 sum_array 约 30–40 字节；ARM64 约 40–48 字节；RISC-V 开启 RVC 后约 24–32 字节。展开版代码更大，但循环开销更少；是否更快取决于 n、对齐、cache 与分支预测，必须实测。

怎么读结果：如果展开版 IPC 更高但墙钟没变，瓶颈在内存带宽；如果代码尺寸翻倍但 cache 命中率下降，可能更慢。三架构之间不要直接比绝对周期——频率、微架构、内存都不同；要比「同一架构下两种写法的 IPC/带宽」，或「同一算法在三套 ISA 上的指令数/代码尺寸」。

原子指令与屏障：三套 ISA 的同一件事

C11 的 atomic_compare_exchange_strong 在 x86 上落 lock cmpxchg，ARM64 落 ldaxr/stlxr 或 cas，RISC-V 落 lr/sc。memory_order_seq_cst 还要额外的全屏障；acquire/release 只需单向屏障。写可移植代码时用 <stdatomic.h>，不要手写 volatile 或假设 x86 的 TSO。

原子指令的代价不在指令本身，而在缓存行独占：多核同时 CAS 同一 cache line 会来回弹跳，吞吐随核数下降。分片计数器（每核一个计数，读时求和）、per-CPU 变量、RCU 都是绕开这个瓶颈的办法。测的时候用 perf c2c 看 HITM，而不是只看 lock 指令的延迟。没有 perf c2c 时，用「单线程 vs 多线程同地址 CAS」的吞吐对比也能看出弹跳：核数增加而吞吐不增，通常就是它。

1.14.16 本章出口检查

母本对应

下一站：1.15 汇编与调用约定 把这三套汇编放进完整函数、栈帧与内联汇编里。

原子操作的另一个边界是「不能睡眠」：在原子上下文/中断里做 CAS 可以，但不能在持锁时调用可能睡眠的分配器；否则会触发 BUG: sleeping function called from invalid context。

本章的量化数字是量级，不是目标机器的实测值；换 CPU/编译器后，先用 perf stat 和 llvm-mca 重跑，再下结论。