021、C与汇编混合编程：内联汇编与函数调用约定
从一次诡异的栈溢出说起
去年调试一块基于Cortex-M7的工业控制器，跑着跑着就进HardFault。看堆栈回溯，PC指针指向一个看起来完全正常的C函数——一个简单的GPIO翻转函数。单步跟踪发现，函数返回时LR寄存器被篡改成了0xDEADBEEF。查了三天，最后发现是同事在内联汇编里直接写了MOV PC, LR，而编译器优化后把函数调用约定给绕过了。
那次之后我养成了一个习惯：只要代码里出现__asm__关键字，必须手动检查生成的汇编清单。C和汇编的边界，是嵌入式开发中最容易翻车的地方，没有之一。
内联汇编：看似方便，实则暗坑
GCC的内联汇编基本语法长这样：
__asm__volatile("指令序列\n\t":输出操作数:输入操作数:破坏列表);volatile关键字我建议永远加上。别问为什么，问就是被优化掉过中断服务程序里的关键操作。编译器觉得“你这段汇编没用到任何C变量，可以删掉”，然后你的定时器就不工作了。
操作数约束：别让编译器猜你的心思
看个实际例子，我们要读取ARM的CP15寄存器（系统控制协处理器）：
// 别这样写！—— 我见过有人这么干然后跑飞了uint32_tread_cp15(void){uint32_tval;__asm__("MRC p15, 0, %0, c1, c0, 0":"=r"(val));returnval;}这段代码在-O0下能跑，开-O2就随机出0。为什么？因为"=r"告诉编译器“随便给我一个寄存器”，但MRC指令对寄存器有隐含要求——某些ARM变体要求目标寄存器必须是R0-R7。正确的写法：
// 这样写稳如狗uint32_tread_cp15(void){uint32_tval;__asm__volatile("MRC p15, 0, %0, c1, c0, 0\n\t":"=r"(val)::// 这里不破坏任何东西，但别漏了volatile);returnval;}这里踩过坑："=r"和"r"的区别。"=r"是输出操作数，汇编里只能写不能读；"r"是输入操作数，只能读不能写。混用了编译器会报错，但有些老版本GCC只给警告，然后生成错误的代码。
破坏列表：你不告诉编译器，编译器就乱来
最经典的例子——修改了CPSR（当前程序状态寄存器）：
// 危险操作！别这样写voiddisable_irq_bad(void){__asm__volatile("CPSID i");}这段汇编修改了CPSR的I位（IRQ屏蔽位），但编译器不知道。如果编译器之前把某个循环变量优化到了标志寄存器里，你的CPSID指令就把人家的循环条件给毁了。正确做法：
voiddisable_irq(void){__asm__volatile("CPSID i\n\t":::"cc"// 告诉编译器：我改了条件标志寄存器);}"cc"表示修改了条件码寄存器，"memory"表示修改了内存（比如DMA操作后需要内存屏障）。这两个破坏描述符是嵌入式开发里最常用的，但也是最容易被忽略的。
函数调用约定：C和汇编的握手协议
ARM的ATPCS（ARM-Thumb Procedure Call Standard）规定了：R0-R3传参数，R0返回值，R4-R11被调用者保存，LR存返回地址。这些规则在纯C环境里编译器自动处理，一旦混入汇编，就得自己维护。
汇编函数调用C函数
写启动代码时经常需要从汇编跳转到C的main函数：
@ 启动代码片段 .global _start _start: ldr sp, =_stack_top @ 设置栈指针 bl main @ 跳转到C函数 b . @ 死循环（main不应该返回）这里有个细节：bl main之前必须保证栈指针有效，且R0-R3里没有垃圾数据。如果main函数期望参数，需要在bl之前把参数塞进R0-R3。
C函数调用汇编函数
反过来，C调用汇编函数时，要保证汇编函数遵守ATPCS。写一个内存拷贝函数：
@ memcpy_asm.S .global memcpy_asm memcpy_asm: @ R0 = dest, R1 = src, R2 = count cmp r2, #0 beq .L_done .L_loop: ldrb r3, [r1], #1 strb r3, [r0], #1 subs r2, r2, #1 bne .L_loop .L_done: bx lr @ 返回，R0指向拷贝后的地址C端声明：
externvoid*memcpy_asm(void*dest,constvoid*src,size_tcount);这里踩过坑：汇编函数里如果用了R4-R11，必须在入口处压栈保存，返回前出栈恢复。否则C函数里这些寄存器的值就被破坏了，轻则变量值不对，重则栈回溯全乱。
中断服务程序的特殊约定
中断处理函数和普通函数不同。在ARM Cortex-M系列里，硬件自动压栈R0-R3、R12、LR、PC、xPSR，但R4-R11需要软件保存。写中断服务程序时，如果用了内联汇编，必须手动保存和恢复这些寄存器：
// 中断服务程序里的内联汇编voidSysTick_Handler(void){__asm__volatile("PUSH {r4-r11}\n\t"// 保存现场// ... 实际处理代码 ..."POP {r4-r11}\n\t"// 恢复现场:::"memory");}别指望编译器帮你做这件事——编译器认为中断服务程序就是个普通函数，它只按ATPCS保存R4-R11。但硬件中断的压栈机制和函数调用不同，这里必须显式处理。
实战：一个带内联汇编的临界区保护
写一个关中断、执行原子操作、再开中断的宏：
#defineATOMIC_SECTION(code_block)do{\uint32_t__primask;\__asm__volatile(\"MRS %0, PRIMASK\n\t"\"CPSID i\n\t"\:"=r"(__primask)::"cc"\);\{code_block}\__asm__volatile(\"MSR PRIMASK, %0\n\t"\::"r"(__primask):"cc"\);\}while(0)使用方式：
uint32_tshared_counter=0;voidincrement_safe(void){ATOMIC_SECTION({shared_counter++;});}这里有个容易忽略的点：__primask变量必须用volatile吗？不需要，因为内联汇编的输入输出操作数已经建立了依赖关系，编译器不会优化掉。但如果你在code_block里修改了__primask，那就出大事了——所以宏里用了do{...}while(0)来创建作用域，防止外部变量污染。
调试技巧：让编译器给你看汇编清单
遇到内联汇编相关的问题，第一件事是看编译器生成的汇编代码。GCC加-S选项：
arm-none-eabi-gcc-O2-Smyfile.c-omyfile.s然后打开.s文件，找到你的内联汇编位置，检查编译器是否按照你的约束分配了寄存器。我经常发现编译器把同一个寄存器既分配给输入操作数又分配给输出操作数——这在某些指令里是允许的，但在另一些指令里会导致数据覆盖。
另一个实用技巧：在内联汇编里加注释标记，方便在汇编清单里定位：
__asm__volatile("/* MY_ASM_START */\n\t""MOV r0, #0xFF\n\t""/* MY_ASM_END */\n\t":::"r0");然后在汇编清单里搜索MY_ASM_START，一眼就能找到你的代码。
个人经验
能用C就别用汇编。现代编译器的优化能力远超手写汇编，除非你确定编译器生成的代码有性能瓶颈，或者需要操作特殊寄存器。
内联汇编的破坏列表宁多勿少。多写一个
"memory"最多损失一点性能，少写一个可能导致整个系统崩溃。我见过最离谱的bug是某工程师在内联汇编里修改了SP（栈指针）但没告诉编译器，结果函数返回时栈已经不知道歪到哪里去了。函数调用约定不是摆设。写汇编函数时，严格按照ATPCS来。如果函数需要保存R4-R11，就在入口处
PUSH {r4-r11}，返回前POP {r4-r11}。别偷懒只保存用到的寄存器——调试时你会感谢自己的严谨。中断上下文里的内联汇编要格外小心。硬件自动压栈的寄存器只有R0-R3、R12、LR、PC、xPSR。如果你在内联汇编里用了R4-R11，必须手动保存恢复。更安全的做法是：中断服务程序里尽量不用内联汇编，把复杂操作放到普通函数里。
最后一条，也是最重要的：每次修改内联汇编后，用
objdump -d反汇编最终的可执行文件，确认生成的机器码符合预期。编译器有时候会做一些你意想不到的优化，比如把内联汇编里的指令重排——虽然GCC承诺不会重排volatile内联汇编，但某些优化选项下确实出现过问题。
C和汇编的混合编程，本质上是在信任边界上跳舞。你信任编译器会正确处理寄存器分配，编译器信任你会正确声明破坏列表。任何一方的疏忽，都会导致系统在某个深夜突然崩溃。保持敬畏，保持谨慎。
