GCC是否保证匹配大小的访问？ARM外设FIFO指令生成疑问

核心结论 #

在你使用的ARM GNU工具链11.3.1环境下，只要正确处理volatile修饰符和地址对齐，你的写法通常可以保证生成对应宽度的加载/存储指令；若要彻底消除编译器行为依赖，优先使用编译器内置函数而非内联汇编。

详细说明 #

1. 现有写法的有效性与注意事项 #

你的代码a_u16_var = *(uint16_t*)&FIFO_REG;能生成ldrh指令的前提是：

• FIFO_REG必须被声明为volatile uint32_t类型——外设寄存器是内存映射的硬件单元，volatile会强制编译器执行实际的内存操作，避免优化掉关键的读写动作；
• 寄存器地址满足对齐要求——STM32H5的外设寄存器均为32位对齐，uint8_t/uint16_t访问均符合平台对齐规则。

在ARM GNU工具链中，对volatile指针的解引用操作，编译器会严格按照指针类型生成对应宽度的内存访问指令。但从C标准层面，这种跨类型指针转换访问违反了严格别名规则，属于未定义行为；不过嵌入式编译器针对外设访问场景做了特殊支持，只要符合平台要求，实际使用中是可靠的。

2. 不同宽度访问的指令生成可靠性 #

对uint32_t和uint8_t采用相同模式时：

• 使用*(volatile uint32_t*)&FIFO_REG会生成ldr/str指令；
• 使用*(volatile uint8_t*)&FIFO_REG会生成ldrb/strb指令。

只要保留volatile修饰符且地址对齐，完全可以依赖ARM GCC生成对应指令。

3. 确保正确访问的最佳方式 #

如果想彻底消除编译器行为依赖，优先选择ARM GCC内置函数，而非内联汇编——内置函数更简洁、可读性更强，且由编译器直接映射到对应ARM指令：

• 8位读写：

  uint8_t val8 = __ldrb((volatile uint8_t*)&FIFO_REG);
  __strb(val8, (volatile uint8_t*)&FIFO_REG);
  

• 16位读写：

  uint16_t val16 = __ldrh((volatile uint16_t*)&FIFO_REG);
  __strh(val16, (volatile uint16_t*)&FIFO_REG);
  

• 32位读写：直接访问FIFO_REG即可（若其为volatile uint32_t类型），或使用__ldr/__str函数。

内联汇编虽然也能保证指令正确性，但代码可读性差、移植性低，仅在极端场景下需要使用。

内容的提问来源于stack exchange，提问作者Brian A. Henning