“r”约束不等于随意分配寄存器，因GCC虽从x0–x31中选，但x0（zero）、x1（ra）、x2（sp）等有特殊ABI语义，必须通过clobber显式声明被修改的寄存器（如"ra"、"sp"），否则破坏调用约定导致静默崩溃。
直接写 "r" 就能用通用寄存器，但必须结合 RISC-V 的寄存器命名习惯和 ABI 约定，否则生成的指令可能破坏调用约定或触发非法分配。
为什么 "r" 在 RISC-V 上不等于“随便挑一个寄存器”
RISC-V 的 "r" 约束会让 GCC 从整数通用寄存器类（GPR）中选一个，但这个类默认包含全部 x0–x31。问题在于：x0 恒为 0、x1 是 ra、x2 是 sp —— 它们不能当普通变量寄存器用。GCC 实际分配时会避开这些特殊寄存器，但前提是你的内联汇编声明了正确的破坏描述符（clobber）。
常见错误现象：asm volatile ("add %0, %1, %2" : "=r"(res) : "r"(a), "r"(b)); 看似没问题，但如果编译器把 a 分配到 x1（ra），而你没在 clobber 里写 "ra"，函数返回就可能出错。
- 输出约束如
"=r"表示“结果写进一个通用寄存器”，GCC 保证不会选x0或x2 - 输入约束如
"r"不做保护性排除，它只承诺“值已放好”，是否安全取决于你是否显式声明 clobber - 若指令修改了
ra、sp、fp（x8）等，必须在第三个冒号后列出，例如：: "ra", "sp"
"=r" 和 "=&r" 的区别直接影响寄存器重用
"=&r" 中的 & 表示“早期输出”（early-clobber）：该输出寄存器在所有输入操作数被读取前就被写入。这对 RISC-V 的多操作数指令很关键，比如一条指令同时读 x5、写 x5 再读 x6，不加 & 可能让 GCC 把输入和输出分配到同一个寄存器，导致数据被提前覆盖。
典型场景是自定义原子操作或需要复用寄存器的序列：
asm volatile ( "add %0, %1, %2\n\t" "sub %0, %0, %3" : "=&r"(tmp) // 必须 &，否则 %0 可能和 %1/%2 重叠 : "r"(a), "r"(b), "r"(c) : "cc" );
- 没加
&：GCC 可能让%0=%1，第一条add就把a覆盖了 - 加了
&：GCC 保证%0是独立寄存器，哪怕只剩一个空闲寄存器也会 spill - RISC-V 没有 flag 寄存器抽象，
"cc"是惯用写法，表示条件码可能被改
要锁死特定寄存器（比如强制用 a0），不能只靠 "r"
标准约束不支持指定物理寄存器编号，但 RISC-V GCC 提供扩展语法："=r"(var) : "{a0}"(val) 这种写法会强制把 val 放进 x10（即 a0）。不过要非常小心：
- 仅限输入约束使用
"{a0}"、"{t0}"等别名；输出侧强制绑定需搭配"=&r"+ 显式寄存器名，例如"=&{a0}"(out) - 如果函数 ABI 要求
a0传参，你在内联汇编里把它当临时寄存器用了，又没在 clobber 里声明"a0"，调用方会拿不到参数 - 硬编码寄存器名会降低可移植性，跨 ABI（如 ilp32 vs lp64）可能失效；优先用
"r"+ 合理 clobber
破坏描述符（clobber）漏写 "memory" 是 RISC-V 内联汇编最常踩的坑
RISC-V 是强顺序架构，但编译器不知道你的汇编是否访问内存。如果你的内联汇编里有 lw、sw、amoswap.w 等指令，却没写 "memory"，GCC 可能在它前后乱序移动内存访问，导致逻辑错误。
示例（原子交换）：
int atomic_xchg(int *ptr, int val) {
int old;
asm volatile (
"amoswap.w %0, %2, (%1)"
: "=r"(old), "+r"(ptr)
: "r"(val)
: "memory" // 缺了这行，编译器可能把前面的 load 提前、后面的 store 推后
);
return old;
}
-
"memory"告诉 GCC：“这段汇编可能读/写任意内存”，禁止相关优化 - 不要用
"cc"代替"memory"—— 它们解决的是完全不同的问题 - 如果只读内存（如
lw），仍建议加"memory"，除非你能 100% 确保无 alias 风险
真正麻烦的地方不在约束语法本身，而在于 RISC-V 的寄存器语义和 ABI 约定是隐式的：编译器不会报错，但生成的二进制会在特定调用路径下静默崩溃。每次写完内联汇编，最好用 gcc -S 看一眼汇编输出，确认寄存器分配没碰 ra、sp，且 clobber 列表和实际行为一致。
