作者：GorgonMeducer 傻孩子
首发：裸机思维
自从红警1重制以来，除了生病、上班、看漫画、补番以外，我最大的乐趣就是在steam上参加夜间多人运动——当然，也就没有啥兴致去更新。上周发了一篇原创以后，冷不丁的被人用“打赏”狠狠的催更了一番，好歹也是十六进制两位数的打赏——手中的鬼畜般“Acknowledge, Affirmtive”顿时就不香了——赶忙开始更新。
【正文】
在前面的文章《编译器玄学报告第一期》中，我们了解到：volatile实际上是告诉编译器“绝不允许对被修饰的变量动手动脚（做优化）”，因为在“编译器不知道的情况下”，这个变量的值是可能会因为各种原因被更新或者是改变的。实际使用中，volatile 阻断了编译器利用通用寄存器对静态变量的操作进行优化，虽然能保证操作的正确性，却无法在某些可以优化的地方提升性能。例如：
static volatile uint32_t s_wVPort = 0;由于volatile的存在，步骤1和步骤2这样的“读改写操作”都会独立生成针对s\_wVPort的读写操作，因此上述代码等效为：
void set_vport_u8(uint8_t chValue, uint8_t chOffset)显然，步骤1.3和2.1是多余的，我们可以手工将其优化为：
void set_vport_u8(uint8_t chValue, uint8_t chOffset)这就是一个手工对volatile修饰的变量进行局部优化的例子，本质上就是替代编译器在合适的位置使用通用寄存器对静态变量进行“手工窥孔优化”。需要注意的是，需要volatile进行修饰的变量通常与多任务或者中断/异常有关，因此，进行手工窥孔优化时，尤其需要注意“确保数据操作的完整性（原子性）”，相关内容，我们将在随后的文章中为您详细展开。
volatile的应用范围非常广泛，尤其是在嵌入式系统中，几乎所有的外设寄存器都可以表述为如下的形式：
//!已知某32位外设寄存器的地址为 XXXXX_IO_REG_BASE_ADDRESS，则对应的寄存器可以定义为考虑到这种情况，应用中很多针对外设寄存器的连续操作都可以通过“手工窥孔优化”来大幅度提高效率。如果可能（在保证程序逻辑正确的情况下），应该尽可能减少volatile的使用；或者是限制其使用的范围；万不得已的情况下，则应该对volatile参与的运算热点进行“手工窥孔优化”。
专栏推荐文章
如果你喜欢我的思维，欢迎订阅裸机思维
版权归裸机思维（傻孩子图书工作室旗下公众号）所有，
所有内容原创，严禁任何形式的转载。
