1 为什么要看一层汇编
把程序复制到服务器的固态硬盘上，并不意味着 CPU 已经开始执行它。文件里的代码字节要经过操作系统装载，映射到进程的地址空间，CPU 才能沿着指定入口执行。高级语言方便人表达业务规则；机器码规定处理器实际接受的指令编码；汇编则用助记符、寄存器名和地址表达式，让人能够阅读这些指令。学习这层表示，主要是为了把“程序说要做什么”和“这台机器实际执行什么”接起来。
设想 1 台装有 32 GiB 内存的 x86-64 服务器，通过 PCIe 连接网卡和 NVMe 固态硬盘。程序收到采集板上传的 4 字节测量值，把它放进普通内存，再执行加法。到这时，加法指令处理的是寄存器和内存中的数值，并不直接理解“网卡”“传感器”或“文件”。网卡如何搬运数据、驱动如何通知应用，属于其他层的职责。看汇编能定位加法读取了哪个地址，却不能只凭这条加法判断网络链路是否丢包。
同样的程序也可能运行在采用 AArch64 指令集的开发板上。板子可以有相似容量的内存，也能连接 PCIe 外设，但它接受的机器码与 x86-64 不同。判断能否直接运行某个可执行文件，不能只比较主频、内存容量或机器外形，还要检查目标指令集、操作系统和二进制接口。塔式服务器、机架服务器与小型板卡是机器形态；指令集是软件可见的执行规则，二者不能混为一谈。
阅读汇编的收益通常出现在边界处：程序在某个地址崩溃，调试器只能给出寄存器；源代码写了调用，发布版本里却看不到对应函数；相同源文件换编译选项后速度明显变化。汇编能帮助确认故障指令、实际访问宽度、调用是否存在，或某段计算是否已经被编译器消除。它提供具体证据，但不自动给出原因。地址错误可能来自更早的越界写入，程序停下的位置只是错误首次变得可见的位置。
本课以 Linux 上的 x86-64 System V ABI 为主要例子，汇编采用 Intel 语法：目的操作数在前，源操作数在后。这个约定只适用于这里的示例。其他平台可能使用不同的寄存器传参规则，反汇编工具也可能默认采用 AT&T 语法。开始观察之前，先写下平台和语法，往往比背熟更多助记符更有用。
目标是能读懂短小的指令片段，辨认数据来自哪里、运算发生在哪里、控制流走向哪里，并知道何时需要更深入的证据。无需先掌握指令编码表，也不必立刻学习处理器内部如何并行执行。这些内容会在后续课程中逐步展开。
2 指令、操作数与寻址
可以把 1 条指令读成“动作加参与者”。在 add eax, 5 中，add 表示加法，eax 是保存结果的寄存器，5 是直接写进指令的立即数。寄存器是 CPU 提供给指令使用的小容量存储位置，不能按普通内存地址随意编号访问。立即数属于指令编码的一部分，它不是从某个数据地址临时读出来的数值。区分这 2 类来源，是看懂短片段的起点。
再看 mov eax, DWORD PTR [rdi]。rdi 保存地址，方括号表示访问该地址处的内存，DWORD PTR 指定本次读取 4 字节。这里复制的是地址所指向的数据。相比之下，mov rax, rdi 复制寄存器中的值，若该值原本是地址，复制后仍是地址数值；它不访问这个地址对应的内存。调试时混淆“指针”和“指针指向的内容”，会让正确的地址看起来像异常的数据。
在本课的平台上，rax 是 64 位寄存器，eax 是它的低 32 位。写入 eax 会把 rax 的高 32 位清零。这是指令集定义的效果，不是所有处理器对部分寄存器写入都遵循的通用规则。寄存器名称也不代表语言类型：相同的位模式可以被程序解释为无符号数、有符号数或地址。要判断含义，必须结合使用它的指令以及源代码中的类型约束。
寻址表达式还可以包含偏移和索引。例如 mov eax, DWORD PTR [rdi + rcx*4 + 8] 先计算地址，再从该地址读 4 字节。当 rdi 指向某个数组布局的起点、rcx 表示元素索引时，乘以 4 可能对应每个元素的字节数，8 可能是前置字段的长度。但这些只是需要验证的解释；结构体布局、数组起点和索引范围都必须有证据支持。看到常数 4 并不能直接认定它就是数组。
还有看似相近的 lea rax, [rdi + rcx*4 + 8]。它把计算出的数值写进 rax，不读取该地址中的数据，因此常被用于地址计算，也能用于某些整数运算。若调试器显示某条访存指令失败，要检查的包括计算后的地址、访问宽度以及页面权限。地址数值看起来合理，也可能落在已释放区域或不可写区域；仅凭地址的十六进制外观无法判断其合法性。
机器码是字节序列，不是助记符的文字编码。8b 07 在这里解码为 mov eax, DWORD PTR [rdi]，但脱离执行模式和指令起点，不能把任意字节都这样解释。x86-64 指令长度可变，取错起点可能仍然反汇编出貌似正常的内容。阅读工具输出时，要确认它来自代码区域，并结合符号或控制流核对边界。入门阶段只需理解编码与解释条件的关系，无需手工计算每个编码字段。
3 汇编与高级语言的对应
考虑这个用于修正测量值的函数。它假设参数指向有效、可读的普通内存，且执行期间没有其他线程并发修改同一对象。
#include <stdint.h>
uint32_t add5(const uint32_t *sample) {
return *sample + 5u;
}在常见的 x86-64 Linux 编译环境中，优化后的核心代码可能只有下面的样子。这里展示的是有代表性的结果，具体编译器版本和选项可能改变输出。
mov eax, DWORD PTR [rdi]
add eax, 5
retrdi 中的参数地址来自调用约定，eax 中的结果也按约定交给调用者。源代码里的变量名 sample 不一定留在机器指令中；类型中的 const 也不是某条“只读指令”。它约束源代码通过这个指针修改对象的方式，不能代替操作系统的内存保护。理解这些区别，可以避免把语言层的标注当成硬件层的保护机制。
这里的加法采用 32 位结果。由于源代码的结果类型是 uint32_t，超出范围时按无符号整数规则取模。例如 4294967293 + 5 的结果为 2。但不能把这条结论套到所有 C 整数表达式：有符号溢出的语言规则不同，编译器可能据此进行优化。机器能够执行某种位级加法，不等于源程序中的每种写法都保证得到相同效果。
高级语言与指令之间也不是逐行对应。常量表达式可能在编译时计算，短函数可能被内联到调用者，循环可能被展开，暂时变量可能只存在于寄存器。未优化版本为了方便调试，往往保留更多内存读写；优化版本则可能让源代码中的多行对应少量指令。单步时行号前后跳动，不一定是控制流错误，也可能是调试信息在描述经过重排的代码。
反过来，1 行源代码也可能变成很多指令。例如读取带边界检查的容器、进行较宽的整数运算，或调用库函数，都可能引入额外路径。评估时应先明确比较目标：是在解释程序行为，核对接口，还是测量运行成本。指令条数可以帮助描述结果，却不能独立代表耗时；访存等待、输入分布、函数调用频率都会改变总体表现。
源文件通常先被编译为目标文件，再由链接器把代码和所需符号组织成可执行文件。目标文件中的某些引用还要经过重定位，因此其中显示的地址未必等于运行地址。共享库和地址随机化又会改变装载位置。记录“偏移 0x20”时必须同时记录所属模块；否则另一次启动中相同的绝对地址可能指向完全不同的位置。
对于网卡队列描述符、磁盘协议字段或板卡寄存器，结构体布局、字节序和访问方式还会受接口规范约束。普通内存中的这个小函数不能直接作为设备寄存器访问模板。设备内存可能具有特殊语义，应使用平台提供的驱动接口。先把普通程序读懂，再理解特殊接口的额外要求，能让知识边界更清楚。
4 动手：读一小段反汇编
把上面的源代码保存为 sample.c，在具有 GCC 和 GNU binutils 的 x86-64 Linux 环境中，可以观察编译器生成的目标文件。这里不要求服务器有特定型号的网卡或存储设备，因为这个例子只访问普通内存。
gcc -O2 -g -c sample.c -o sample.o
objdump -d -M intel sample.o-c 表示只生成目标文件，-O2 开启常用优化，-g 保留调试信息，-M intel 选择本课使用的语法。先核对输出里的文件格式和函数名，再读指令。有些工具链会加入入口保护指令或其他辅助内容，所以实际结果不必与下面逐字一致。若主机采用其他指令集，应使用匹配目标的工具链，不能把错误架构下的反汇编当作有效证据。
0000000000000000 <add5>:
0: 8b 07 mov eax,DWORD PTR [rdi]
2: 83 c0 05 add eax,0x5
5: c3 ret左侧的 0、2、5 是本示例中相对函数起点的偏移；中间是机器码字节；右侧是工具解码出的指令。第 1 条占 2 字节，第 2 条占 3 字节，第 3 条占 1 字节，所以相邻偏移并不相差固定值。源代码中的十进制 5 与输出中的十六进制 0x5 是相同数值。先区分地址、字节和操作数这 3 列，能避免把机器码里的数字误认作计算结果。
现在给这段代码补上运行状态：假设它被装载在 0x00401000，rdi 为 0x00001000，该地址处的 4 字节为 25 00 00 00。x86-64 的小端表示让这组字节对应十进制 37。执行读取后，eax 为 37；执行加法后为 42。内存仍为原来的字节，因为代码没有写回。地址、装载位置和初始值都是本课人为设定的观察条件，并不要求真实进程允许访问这些示例地址。
动画用单条指令推进，重点观察寄存器值与数据内存是否变化。它呈现的是指令完成后的可见状态，不能据此推导真实 CPU 每个时钟周期做了什么。特别是 ret，它从栈中取出返回地址并转移控制流，不是把 eax 写回参数指针。返回值保留在约定的寄存器中，由调用者继续使用。
如果真实调试中第 1 条指令报错，应先检查 rdi 的值、对应区域是否映射、以及 4 字节访问是否跨入不可访问区域。若第 2 条的结果与预期不同，应核对输入位宽、无符号规则和读取到的实际数据。把故障按指令效果拆开，能减少“看到崩溃就怀疑 CPU 损坏”这类跳跃判断。
最后把编译器版本、完整命令、目标文件标识和观察到的字节一起记下。只有函数名不够，因为同名函数可能来自不同构建。若要用线上崩溃记录解释发布版本，应优先取得对应发布产物和符号；本地重新编译的文件可以帮助实验，却不能保证具有相同地址、指令或布局。
5 调用约定与栈帧直觉
函数在源代码中像独立的小盒子，但机器执行时需要共同规则：参数放在哪里，结果从哪里取，哪些寄存器可以被改写，调用结束后从哪里继续。ABI，即应用二进制接口，包含这类约定，也涉及数据布局等规则。只知道 CPU 能识别哪些指令，还不足以让不同编译单元正确协作。双方即使都使用 x86-64，也可能因为采用不同 ABI 而传错参数。
在本课采用的 System V AMD64 ABI 中，普通整数或指针参数通常依次通过 rdi、rsi、rdx、rcx、r8、r9 传递，更多参数或某些复杂类型需要其他处理。整数或指针结果通常使用 rax 及其相应部分。浮点数、结构体和可变参数具有额外规则，不能靠这个简表猜测。Windows x64 的规则又有差异，所以移植手写汇编时不能只改文件扩展名。
call 会把后续执行所需的返回地址压入栈，再转到目标函数；ret 从栈顶取回这个地址。栈位于内存中，rsp 表示当前栈顶。在这里，压入 8 字节会让 rsp 减少 8。函数需要局部空间时，也可能从 rsp 减去相应大小；释放空间时再加回来。栈向低地址增长只是本例平台的规则，并不是“所有数据都倒着存放”。
栈帧可以理解为某次函数调用使用的那部分栈空间，里面可能包含局部数据、保存的寄存器和对齐空间。rbp 有时被用作稳定的栈帧参考点，但优化后也可能不用它。没有 push rbp 并不代表函数没有调用关系，更不代表调试器一定无法回溯。准确展开调用栈还可能依赖编译器生成的展开信息，本课只建立空间与返回路径的直觉。
寄存器保存规则同样重要。调用者保存寄存器允许被被调用函数改写，如果调用者还需要旧值，应自行保存；被调用者保存寄存器则要求函数返回前恢复。System V AMD64 中 rbx、rbp、r12 至 r15 属于后者，rsp 也必须正确恢复。违规不一定当场崩溃：某个值可能直到后续循环或指针计算时才被使用，因此故障表面上可能离错误函数很远。
还要留意栈对齐。对本课普通调用场景，执行 call 之前，调用者应让 rsp 按 16 字节对齐。call 压入 8 字节返回地址后，被调用函数刚进入时的 rsp 对 16 取余为 8。它可以据此安排后续栈空间。这里讨论的是常见基本要求，特殊参数类型可能带来更严格的要求，实际接口仍应查对应 ABI 文档。
因此，读到函数入口和出口时，可以做连续核对：参数从哪个位置进入，哪些寄存器被修改，栈指针怎样变化，返回前是否恢复。只盯着函数中间的算术，很容易漏掉真正决定兼容性的边界。进入高级的异常展开或编译器后端之前，把这些基础关系核对清楚，就已经能够解释很多跨语言调用故障。
6 常见坑：把汇编当优化的唯一路径
“指令更少，所以程序更快”是常见误判。服务器处理数据时，CPU 可能在等内存，也可能在等磁盘、网卡或其他线程。1 条读取指令的等待时间并不固定；把多条算术指令改成较少指令，也可能增加访存或引入数据依赖。讨论性能时，先指出测量对象是整项任务、某个函数，还是某段循环，并说明输入规模与重复次数。没有边界的“更快”难以复核。
例如，1 个采集服务每批处理用时 100 ms，性能采样表明目标转换函数占 30%。即使把这个函数本身加速到原来的 2 倍，其他部分保持不变，总耗时也只是变成 85 ms，整体约快 1.18 倍。若主要时间花在从 NVMe 读取数据，优化这个函数还可能让占比下降得更明显。局部收益要通过实际占比折算，不能直接复制为整机收益。
滑块把目标占比、局部加速倍数和新增固定开销放在同一模型中。它用于解释算术关系，前提是总工作量及其他部分耗时保持不变。真实系统可能出现缓存行为改变、线程竞争或 I/O 重叠，不能用模型输出替代基准测试。若模型显示即使局部无限快也难达到目标，就应重新检查瓶颈范围，而不是继续增加手写汇编的复杂度。
另一个陷阱是比较条件不一致。把开启优化的手写版本与关闭优化的 C 版本比较，测到的可能主要是编译配置差异。只运行很短的输入，可能把启动、计时与函数调用开销当成核心成本。编译器如果发现结果无人使用，还可能移除整个计算。有效比较应使用相同输入、相同目标平台和合理的构建设置，保证结果被真实使用，并记录多次测量的波动。
手写汇编也增加维护责任。它可能依赖特定指令扩展，部署到缺少该扩展的 CPU 上就触发非法指令异常；可能破坏寄存器保存规则，在换编译选项后才显现；也可能妨碍编译器在更大范围内优化。开发机与线上服务器都叫 x86-64，并不保证支持完全相同的扩展。发布时需要核对目标能力和构建参数，必要时提供通用路径。
更常见的改进顺序是先修正算法、数据布局与不必要的复制，再检查编译器是否获得了足够信息，最后判断是否值得使用平台相关实现。例如每个元素都触发随机访存时，改善连续访问可能比缩短加法代码更有价值。需要专用指令时，也应考虑编译器内建接口或成熟库，并验证它们在实际工作负载中的效果。
阅读汇编本身仍然很有用：它可以确认循环是否保留、额外复制是否发生、某条扩展指令是否出现。但观察到某个实现选择，只能形成假设。下一步应回到可重复的测量，并同时检查正确性。优化必须保持预定的数值规则、边界行为与接口约定，否则更短的耗时可能只是因为程序少做了必要工作。
7 案例：一次 ABI 误解导致的崩溃
下面是基于明确调用条件构造的教学案例。某个采集程序通过手写的 x86-64 汇编桥接函数 bridge 调用 C 函数 normalize。程序部署到同样采用 Linux System V AMD64 ABI 的服务器后，调用链在 normalize 内崩溃。采集板通过 PCIe 网卡送来的数据仍然正常，故障却最初被误认为是传输缓冲区损坏，因为调试器停在了一条内存写指令上。
桥接函数的错误版本非常短。它不改参数寄存器，但也没有调整栈指针。
bridge:
call normalize
ret误解在于：“参数已经在寄存器里，所以这个桥接函数不需要管栈。”普通调用者在调用 bridge 前已经做好对齐，进入 bridge 后却因为返回地址入栈而偏移了 8 字节。此时它又发起 call，就必须为新的调用重新满足对齐要求。直接调用会让 normalize 看到不符合约定的入口栈状态，问题与参数是否经过栈传递无关。
设复现记录中，bridge 入口的 rsp 是 0x7fffffffd0d8。错误版本直接调用后，normalize 入口的 rsp 成为 0x7fffffffd0d0，对 16 取余为 0，而它按约定应为 8。假设该构建中的 normalize 先执行 sub rsp, 0x28，随后执行 movaps XMMWORD PTR [rsp+0x10], xmm0。写入目标变为 0x7fffffffd0b8，没有按 16 字节对齐。
这里的 movaps 是具有对齐要求的 SIMD 数据传送指令，本课只需要知道本例内存操作要求 16 字节对齐。目标地址所在的页面即使有效、可写，也不能消除这个要求。故障现场因此可以表现为访问异常；具体信号与报告细节取决于系统。这个入口、栈空间和指令组合是案例的既定条件，不能假定所有编译版本都会生成相同序列。
修复后的桥接函数在调用前留出 8 字节，返回后再恢复。对这个不使用局部数据、无需额外保存寄存器的普通调用片段，修复可以写成：
bridge:
sub rsp, 8
call normalize
add rsp, 8
ret此时调用前 rsp 是 0x7fffffffd0d0，进入 normalize 时是 0x7fffffffd0c8，再减去 0x28 得到 0x7fffffffd0a0，对应写入地址为对齐的 0x7fffffffd0b0。栈恢复后，bridge 仍能取到自己的正确返回地址。若函数还保存寄存器或分配其他空间，就必须重新计算，不能机械地到处插入 sub rsp, 8。
排查记录应保留故障指令、寄存器、目标地址、调用链和确切构建，说明页面可写但对齐不满足，并通过修复后的复现对比闭合证据。仅把 movaps 换成允许非对齐访问的指令，会掩盖这次表现，调用边界仍然违规。完整汇编函数还需按工程要求补充符号与展开等信息，这里只展示导致故障和修复所需的核心序列。
8 把「需要下沉到汇编」的判据写进排查手册
排查手册应让工程师知道何时打开反汇编视图，以及打开后要回答什么。适合下沉的信号包括：程序在稳定位置发生非法指令或访问异常；源代码与发布产物的行为明显不一致；跨语言边界出现参数错位或返回后损坏；性能采样已把热点定位到很短的计算路径。每个信号都对应可检查的具体事实，避免把“复杂问题”直接等同于“必须看汇编”。
同时设置继续停留在较高层的条件。若请求多数时间等待磁盘，先查看存储延迟与访问模式；若网卡接收计数异常，先检查链路、驱动和队列统计；若板卡无法枚举，先核对供电、连接和 PCIe 设备识别。这些问题可能最后也涉及底层软件，但应用程序的加法指令通常不是首要证据。实物服务器的故障面跨越硬件、系统和程序，工具应跟着问题走。
进入汇编层之前，收集目标架构、操作系统、ABI、可执行文件与共享库版本、构建标识、符号文件以及可复现输入。若使用崩溃转储，还应保留模块装载地址。地址随机化下，模块名加模块内偏移比单独的绝对地址更便于定位。日志中的旧函数名、本地的新二进制和线上的旧转储如果混在一起，会产生看似精确但实际上无法对应的结论。
随后按指令效果组织观察。对访存指令，记录基址寄存器、索引、偏移、访问宽度及最终地址；对调用和返回，核对参数位置、栈对齐、保存规则与返回地址；对非法指令，核对实际字节、解码起点和 CPU 支持能力。不要先猜一个熟悉的原因，再挑选能支持它的寄存器值。记录中应区分“直接观察到的事实”和“目前用于解释事实的假设”。
例如“第 1 条读取使用了 rdi=0”是观察，“对象提前释放导致指针无效”仍是假设，而且空指针与释放后的悬空指针不是同一种状态。类似地，程序停在 ret 附近，可能涉及返回地址损坏，也可能是错误的栈恢复。应沿调用边界核对具体变化，并视需要借助内存检查工具追溯更早的写入。反汇编能说明当前动作，未必保留导致错误的全部历史。
性能问题则需要另一种闭环：先有代表性输入和耗时分布，再提出可解释的代码变更，最后对比相同环境下的结果与正确性。报告同时保留局部耗时和总体耗时，说明是否改变 CPU、内存容量、并发数或存储设备。若这些条件同时变化，就不能把全部收益归给某段汇编。测试结果有明显波动时，应先解释波动来源，再讨论小幅收益。
手册最后写明停止下沉的条件：已经找到违反接口的边界并验证修复，或已有证据表明瓶颈位于其他层，就把工作移交给对应路径。遇到疑似内存硬件故障，也需要结合系统错误记录和硬件诊断，不能仅凭某个指针异常下结论。可复核的排查结论应说明证据覆盖到哪里、哪些解释仍待验证，以及下一次故障如何快速取得相同信息。
9 从机器码走向 CPU 流水线（H19）
到这里，我们把程序看成沿着控制流完成的一串指令。这个视角足以解释 mov 读了什么、add 改了什么、call 与 ret 怎样交接控制权，也能检查 ABI 是否被遵守。它描述的是程序可观察的执行效果。真实 CPU 内部还要组织取指、解码、执行与访存等工作；这些活动的安排，会让“最终效果相同”的代码表现出不同耗时。
首先要保留指令集与实现的区别。指令集规定软件可以依赖的操作及效果，CPU 的具体实现决定这些操作怎样完成。采用相同指令集的 2 颗处理器可以运行同类机器码，却不保证每条指令耗时相同。服务器与开发板的外形、功耗和散热能力也可能影响持续运行表现，因此单独记录主频不足以解释完整性能差异。
其次，不要把本课动画中的每次推进理解为真实时钟的 1 个周期。动画让前一条指令完成后再显示后一条，是为了便于追踪状态。实际处理器可能让不同指令的处理阶段重叠，也会受到数据是否就绪等条件限制。H19 将用流水线解释这种重叠关系；在那之前，只需把“逻辑顺序”与“内部时间安排”分别记住，暂不展开乱序执行等更深机制。
现在就能提出有用的问题。mov eax, [rdi] 后面的 add eax, 5 需要使用读取结果，二者存在数据依赖；如果数据还没准备好，加法无法凭空得到正确输入。另一个独立计算是否有机会同时推进，则需要进一步了解具体实现。类似地，分支会改变后续指令地址，但分支带来多少时间成本不能仅从助记符推断。问题应从依赖关系出发，再交给性能证据回答。
这也解释了为什么源码行数、机器码字节数与运行时间不能互相替代。字节数描述存储占用，指令序列描述操作，时间还受到 CPU 实现和数据路径影响。压缩了代码大小可能有益，却不必然缩短某个输入上的执行时间。反过来，更多指令也可能因为改善数据访问方式而获得收益。理解这种边界，可以让后续学习流水线时不再执着于简单数指令。
在进入 H19 前，可以带着本课的例子做口头检查：哪条指令访问数据内存，哪条改变返回路径，哪处依赖输入，哪项规则来自 ABI。再把尚未回答的问题单独列出，例如读取延迟从哪里来、连续指令为何能重叠、控制流改变为何影响吞吐。这样既保留已经得到的确定结论，也为后续课程留下明确接口，无需用尚未学习的处理器内部术语填补空白。
放进方案里
在服务器采集服务的设计与运维方案中，为汇编层观察预留可执行的入口。平台说明写清目标指令集、操作系统和 ABI，记录发布构建使用的指令扩展基线。若服务同时部署到机架服务器和不同架构的板卡，应分别提供匹配产物。硬件清单保留 CPU 能力、内存容量、PCIe 网卡与 NVMe 存储信息，帮助区分执行兼容性与数据传输瓶颈。
发布流程把可执行文件、共享库、构建标识和符号按版本关联保存。故障记录至少包含模块与偏移、故障指令字节、关键寄存器、调用栈及可复现输入的描述。对采集数据中的敏感内容按既有规则处理，优先保留足以复现计算的最小样本。责任人应能从线上记录找到确切产物，避免用重新编译的文件解释旧地址。
跨语言或手写汇编接口单独列出参数类型、位宽、结构体布局、返回方式、寄存器保存与栈对齐要求。评审用本课的调用路径逐项核对，验收覆盖普通输入、边界值及多次调用后的状态；不能以“某个样例没有崩溃”代替接口正确性。接口变化时同时检查两端产物，防止旧调用方与新实现混用。
性能目标分别写总体预算与热点占比。例如批次预算为 100 ms、目标函数占 30%，先估算局部加速能带来的总体收益，再确定是否值得引入平台相关代码。验收保持输入、并发和硬件条件可比，记录正确性与耗时波动。出现崩溃时，先依故障指令核对地址和 ABI；出现 I/O 等待时，转向网卡、存储和系统路径。方案最终交付应包含进入汇编层的触发条件、所需证据、修复验证方式与停止条件，让不同工程师能够重复得到结论。
10 小结：下一步 CPU 流水线（H19）
汇编让机器码中的动作变得可读：分清寄存器、立即数与内存，才能追踪数据；分清指令集与 ABI，才能解释调用；保留构建与运行状态，才能把反汇编变成证据。看懂指令不等于能单凭指令数预测性能，修复接口也不能靠掩盖某条报错指令完成。
自测时，试着解释 mov rax, rdi、mov eax, [rdi] 与 lea rax, [rdi+8] 的差别，再说明桥接函数为何必须检查栈对齐。下一步进入 H19，用 CPU 流水线理解指令处理如何重叠，以及数据依赖为什么影响执行节奏。