我真的不知道如何简洁地问这个问题，所以如果这个问题已经被问到并回答，我深表歉意.
我正在一个ARM平台上工作，该平台具有对外围设备先进先出的32位伪寄存器访问权限. 根据读取或写入的大小，会向FIFA中删除或添加可变数量的字节.
我编写了以下C代码来执行16位(半字)读取:
a_u16_var = *(uint16_t*)&FIFO_REG;
并确认它确实导致对象文件中出现ldrh操作码.
这有保证吗？ 如果我对uint32_t和uint8_t遵循相同的模式，我可以依赖编译器分别生成ldr/str和ldrb/strb吗？ 如果没有，确保适当大小访问的最佳方法是什么？ 在线组装？
编辑:更多平台细节:
对于volatile，是的，如果是机器本地可以执行的大小，那么GCC将try 仅使用宽度与volatile访问类型相匹配的单个访问.
我不记得我在哪里读到了这篇文章;它不在https://gcc.gnu.org/onlinedocs/gcc/Volatiles.html中(这主要是关于什么算作挥发性访问，以及当您执行像x = volatile_var = y;这样棘手的事情时是否有单独的读取)
否则不，零保证，并且您可以构建测试用例，引诱海湾合作委员会进行单个更广泛的访问，或者仅访问低或高字节例如，IIRC var &= 0xFF之类的内容将使其执行零扩展字节加载，而不是半字和单独的零扩展. 100还有另一个反例，它可以使用一对32位半中的stp个来进行非挥发性，在ARMv8.4之前，这并不能保证是单个64位原子访问. 使用volatile uint64_t使其成为单一访问，例如Linux内核可以安全地滚动自己的原子.
对于MMIO，无论如何你肯定想要volatile！！ 但您正在铸造指向plan-uint 16的指针，而不是指向volatile的指针，所以这很糟糕.
a_u16_var = *(volatile uint16_t*)&FIFO_REG;
// should be safe in GNU C for what you're looking for
围绕volatile次访问的规则应该足以让您不需要-fno-strict-aliasing次( comments 中提到了这一点). Volatile访问无法与其他volatile访问一起重新排序(在编译时)，并且编译器不会假设有关加载或存储的值的任何内容. 只要您对MMIO寄存器的所有访问都是volatile，那么GCC就不能做出任何假设.