最稳妥写法是使用扩展内联汇编（extended asm），明确声明输入/输出操作数、clobber列表，并加volatile；MSVC x64不支持内联汇编；asm goto用于跳转到C标签；滥用内联汇编反而降低性能。
gcc/clang 下用 asm 内联汇编最稳妥的写法
直接写裸 asm("mov %0, %%rax" 这种容易崩，尤其换编译器或加优化就报错。核心是用扩展语法（extended asm），让编译器知道哪些寄存器被改、哪些变量要读写。
常见错误现象：error: unknown register name 'rax' in constraint 或运行时值错乱——多半是没声明输入输出，编译器自己乱调度寄存器。
- 必须用
asm volatile：防止编译器把内联块整个优化掉（比如你只读内存却不写，它可能直接删掉） - 输入/输出操作数用方括号命名，比如
["val"] "r" (x)，别用数字索引（"0"）——难维护还容易和约束冲突 - 破坏列表（clobber list）写全：改了
%rax就写"rax"，改了cc（标志位）就写"cc"，漏了会导致后续条件跳转出错 - 字符串字面量里别写换行或注释，
asm不认 C 风格//，要用/* */包在 asm 外面
Windows MSVC 的 __asm 块为什么总报错
MSVC 的内联汇编只支持 x86（32 位），x64 下直接禁用——不是你写得不对，是它压根不让你用。错误信息通常是：error C4409: __asm keyword not supported on this architecture。
使用场景很明确：如果你在写 Windows x64 程序，这条路已经堵死。替代方案只有两个：
立即学习“C++免费学习笔记（深入）”；
- 用
__emulate+ 单独 .asm 文件 + ml64 链接（麻烦但可控） - 改用编译器内置函数（intrinsic），比如
_mm_add_epi32替代手写 SSE 加法，既安全又通常生成同样高效的代码 - 真要绕过限制？只能降级到 x86 目标平台，但得同步放弃所有 x64 特性（如 >4GB 内存访问）
asm goto 在条件跳转场景下的实际用法
想在汇编里跳转到 C 标签（比如错误处理分支），不能用普通 asm，得用 asm goto。否则编译器不知道那个 label 是啥，会报 undefined label。
典型场景：系统调用失败后跳到 cleanup 标签释放资源，比返回错误码再 if 判断更紧凑。
- 语法必须带
goto关键字，且 label 列表写在最后：asm goto ("test %0; jz %l[fail]" : : "r"(x) : : fail); - label 名前必须加
%l（小写 L），这是告诉编译器“这是 C 标签”，不是汇编符号 - 不能在
asm goto里读写变量并同时跳转——输入输出约束和 goto 是互斥的，要跳转就只做控制流，数据传递走外面变量 - gcc 4.8+ 才支持，老版本直接编译不过
内联汇编导致性能反而变差的几个隐性原因
很多人以为手写汇编一定更快，结果 benchmark 一跑，比纯 C 还慢。问题往往不在指令本身，而在编译器失去优化机会。
关键影响点：
-
volatile强制每次执行，无法被循环展开或合并——哪怕你只是读一个固定内存地址 - 破坏列表写太宽泛，比如写
"rax", "rbx", "rcx", "rdx"，编译器不敢把任何值放这些寄存器，后续代码寄存器压力陡增 - 没用约束（constraint）而用硬编码寄存器，比如
"movq %0, %1"中的%1是变量，但没声明输出，编译器可能把该变量分配在栈上，再额外加 mov 指令搬进寄存器 - 现代 CPU 的分支预测、乱序执行对短小 inline asm 友好度低，一段 3 条指令的 asm 块，可能打断流水线，而编译器生成的等效代码有更好排布
真正需要内联汇编的地方其实很少：精确控制指令顺序（如内存屏障）、访问特殊寄存器（rdtsc）、或极小热路径且 profiler 明确指出瓶颈在某条指令。其它时候，先信编译器。
