C 语言 volatile 与编译器优化：STM32 寄存器访问为什么不能省？

在 STM32 裸机开发里，几乎每个外设驱动都会写到 volatile：定义寄存器、轮询标志位、写中断标志。但不少初学者只把它当成“固定写法”，并不清楚去掉它会出什么问题。本文从编译器优化的角度讲清楚 volatile 到底保证了什么、不保证什么，以及在 STM32 工程里的三条使用边界。

一、先看一个最典型的翻车现场

假设用轮询方式等串口发送完成，代码写成这样：

#define USART1_SR (*(unsigned int *)0x40013800)

while ((USART1_SR & 0x40) == 0) {
/* 等待 TC 位置 1 */
}

如果 USART1_SR 不是 volatile，开启 -O2 优化后，编译器可能只在循环前读一次寄存器，把判断结果缓存到寄存器里，之后永远不再读内存。硬件明明已经把 TC 位置 1，程序却还在原地打转——这不是硬件 bug，是编译器按 C 语言规则做了合法优化：它认为“这段代码没有修改这个内存地址，所以值不会变”。

加上 volatile 之后，语义就变了：每一次访问都必须真实地发一次读操作，编译器不得缓存、不得合并、不得删掉“看起来没用”的访问。寄存器值由硬件改写，这个假设只有 volatile 能表达。

二、volatile 到底保证了什么

准确地说，volatile 只保证两点：

1. 访问不被优化掉。每一次读和写都会真实发生，不会被合并、缓存或删除。
2. 同一线程内，volatile 访问的相对顺序不被编译器重排到普通变量访问之前或之后之外——注意，是“相对顺序”在编译器层面得到保留，而不是跨核、跨总线的时序保证。

它不保证原子性：一个 32 位变量在 32 位 Cortex-M 上读写通常是单指令，但在 8 位机或非对齐访问下，多字节读写仍可能被拆开；它也不保证多核可见性或内存屏障语义，DMA 缓冲区、双核共享内存需要配合内存屏障或缓存操作，不能只靠 volatile。

三、STM32 工程里的三条使用边界

第一，硬件寄存器必须 volatile。STM32 的 CMSIS 头文件里，外设寄存器结构体成员全部带 __IO（即 volatile），不要自己用普通指针绕过去。自己定义寄存器映射时，写法应为：

#define GPIOA_ODR (*(volatile unsigned int *)0x4001080C)

第二，中断与主循环共享的标志位必须 volatile。例如中断里置位的 rx_ready，主循环轮询它：

volatile uint8_t rx_ready = 0;

void USART1_IRQHandler(void) {
rx_ready = 1;
}

如果 rx_ready 不是 volatile，主循环可能把“读 rx_ready”优化成只读一次，出现中断已触发、主循环却永远等不到的情况。这类故障在 -O0 调试时一切正常、开 -O2 才复现，是最难定位的一类问题。

第三，不要滥用 volatile。普通变量、纯软件计算的中间结果、函数内部局部变量都不需要 volatile。滥用会带来两个代价：一是每次访问都走内存，代码变慢变大；二是它会掩盖真正的同步问题——比如中断与主循环之间需要临界区保护的数据，单靠 volatile 仍可能在中断中途被改写，读到一半新一半旧的值，这种情况要用关中断或原子操作，而不是多加几个 volatile。

四、一个自查清单

写完驱动后，可以按这三问自查：这个变量会被硬件、DMA 或中断改写吗？会被改写就加 volatile。它的读写需要原子性或临界区吗？需要就再加关中断或原子操作，而不是只加 volatile。这个变量只是普通软件状态吗？是就别加，让编译器正常优化。

volatile 不是“让代码变稳的万能药”，它只是告诉编译器：这个内存地址的值，程序之外还有人能改。理解这一点，STM32 上很多“时灵时不灵”的轮询和中断问题，排查方向就清晰了：先看优化等级，再看共享变量有没有 volatile，最后再怀疑硬件时序。