15. 内联汇编：何时需要内联汇编、基本语法、寄存器约束
说实话，内联汇编这个话题，很多C++开发者可能一年都用不上一次。但一旦用上，往往是因为遇到了常规手段搞不定的硬骨头。我个人习惯把它看作「最后的杀手锏」——能用C++写清楚的，绝不动用汇编；但真到了需要精确控制指令、访问特殊寄存器、或者榨干最后一丝性能的时候，内联汇编就是那把钥匙。
嗯，咱们今天就把这把钥匙的用法讲透。
什么时候需要内联汇编？
先说说我自己的经验。我在做音视频编解码优化时，遇到过这样一个场景：一个核心算法用C++怎么优化都差那么一点，编译器生成的指令总是多几条冗余的加载和存储。后来我手动插了几行内联汇编，直接操作SIMD指令，性能直接提升了30%。
说白了，需要内联汇编的场景其实很明确：
- 访问特殊指令：比如CPU的CPUID指令、内存屏障指令、位扫描指令等，C++标准库没有直接封装。
- 精确控制寄存器使用：编译器有时会为了通用性而牺牲效率，你明确知道某个值该放哪个寄存器。
- 实现原子操作或锁机制：某些平台特定的原子指令，比如CAS（Compare-And-Swap）的变种。
- 性能关键路径的极致优化：比如视频编码中的DCT变换、加密算法中的S盒替换。
基本语法：GCC/Clang 风格
目前主流的C++编译器（GCC、Clang、MSVC）都支持内联汇编，但语法略有不同。我主要讲GCC/Clang的AT&T风格，因为Linux和嵌入式领域用得最多。MSVC的语法是另一套，但核心思想相通。
基本格式长这样：
asm volatile (
"指令序列\n\t"
"指令序列\n\t"
: 输出操作数列表
: 输入操作数列表
: 被破坏的寄存器列表
);你看，它分四个部分：
- 指令模板：用字符串写汇编指令，
\n\t是换行加缩进，让生成的汇编代码可读性好。 - 输出操作数：汇编代码要写回C++变量的那些寄存器或内存位置。
- 输入操作数：从C++变量读入到汇编中的值。
- 被破坏的寄存器：告诉编译器，这段汇编会修改哪些寄存器，让编译器帮你保存和恢复。
举个例子，一个简单的加法：
int a = 10, b = 20, result;
asm volatile (
"addl %2, %1\n\t"
"movl %1, %0"
: "=r"(result)
: "r"(a), "r"(b)
: "cc"
);
// result 现在等于 30这里 %0、%1、%2 分别对应输出和输入操作数列表中的第0、1、2个变量。编译器会自动分配寄存器给它们。
%[name] 这种命名方式，而不是数字编号。比如 "addl %[b], %[a]"，这样代码可读性高很多，尤其当操作数超过3个时。
寄存器约束：编译器和你之间的契约
寄存器约束是内联汇编最核心、也最容易出错的地方。说白了，就是告诉编译器：「嘿，这个变量你帮我放到某个类型的寄存器里，或者直接放到内存里。」
常用的约束字母：
| 约束 | 含义 | 举例 |
|---|---|---|
r |
通用寄存器（GPR） | "r"(x) |
m |
内存地址 | "m"(x) |
i |
立即数（编译期常量） | "i"(42) |
g |
任意：寄存器、内存或立即数 | "g"(x) |
= |
输出操作数（写） | "=r"(result) |
+ |
读写操作数（先读后写） | "+r"(x) |
& |
早期破坏（earlyclobber） | "=&r"(tmp) |
这里有个坑，我曾经踩过。看这个例子：
int x = 5;
asm volatile (
"movl %1, %0\n\t"
"addl $1, %0"
: "=r"(x)
: "0"(x) // 注意这里用了 "0"，表示和输出用同一个寄存器
: "cc"
);
// x 现在等于 6为什么输入约束写 "0" 而不是 "r"？因为我想让输入和输出共用同一个寄存器，这样省一次 mov 指令。但如果你写 "r"(x)，编译器可能会分配两个不同的寄存器，那就多了一条不必要的拷贝。
"+r" 约束，才解决问题。所以，能用 "+r" 就别分开写输入输出。
volatile 关键字：别让编译器「优化」掉你的汇编
你可能注意到了，我前面每个例子都加了 volatile。为什么？
因为编译器很聪明，它看到你的汇编代码「没有副作用」（比如只是计算一个值，没有写内存或访问硬件），可能会直接把它优化掉。加了 volatile 就是告诉编译器：「这段汇编必须执行，不许删。」
什么时候可以不加？如果你的汇编纯粹是为了计算，且结果被后续代码使用，编译器不会删它。但为了保险，我建议一律加上。反正多写几个字母不费事，少写一个可能让你调试一整天。
SVG 知识结构图
实战中的避坑指南
讲几个我实际踩过的坑，希望能帮你省点调试时间。
坑一：忘记加破坏列表
我曾经写了一段汇编，修改了 eax 和 ecx，但破坏列表里只写了 "cc"。结果编译器在汇编前后把重要数据放到了 eax 里，一执行我的代码，数据就丢了。调试了整整一个下午才发现。所以，所有你改过的寄存器，必须列在破坏列表里，一个都不能少。
坑二：AT&T 和 Intel 语法混用
GCC 默认用 AT&T 语法，操作数顺序是「源, 目标」。而 Intel 语法是「目标, 源」。如果你习惯了 Intel 语法，在 AT&T 里写反了，结果就是灾难。我建议在文件开头加一句 #pragma GCC target("arch=corei7") 或者用 -masm=intel 编译选项统一风格。我个人习惯用 AT&T，因为 Linux 内核代码全是这个风格。
坑三：64位模式下的寄存器名
在 x86-64 下，32位寄存器（如 eax）操作会清零高32位，而16位和8位操作不会。如果你在64位代码里用 %eax 做累加，结果可能超出预期。我一般直接用 %rax 或 %r10d（32位操作），避免歧义。
一个完整的例子：获取CPU的TSC时间戳
最后，给你看一个我项目中实际用过的例子——读取CPU的时间戳计数器（TSC），用于高精度计时：
#include <cstdint>
inline uint64_t rdtsc() {
uint32_t lo, hi;
asm volatile (
"rdtsc"
: "=a"(lo), "=d"(hi)
:
: "memory"
);
return (static_cast<uint64_t>(hi) << 32) | lo;
}这里 "=a" 和 "=d" 是特定寄存器约束，分别表示 eax 和 edx。rdtsc 指令把高32位放 edx，低32位放 eax。我们用 "memory" 作为破坏列表，告诉编译器这段汇编可能改变了内存（实际上没有，但 rdtsc 有副作用，加 memory 防止指令重排）。
你看，内联汇编其实不复杂。关键是把那四个部分写清楚，约束用对，破坏列表列全。剩下的，就是编译器帮你搞定寄存器分配和指令调度。
嗯，今天就聊到这儿。记住：内联汇编是把双刃剑，用好了削铁如泥，用不好伤到自己。多写多试，慢慢就有感觉了。