c - 这是 ARM 编译器代码生成错误吗？

Question

我正在开发一个嵌入式系统，其中包括一个 ARM Cortex-M4 CPU 和一些外围设备。其中一个外设包含可从 CPU 端(通过 AHB 总线)访问的 SRAM block ，但访问必须是字大小的事务(使用 LDR)。如果执行字节事务(LDRB)，则会生成异常。

在我的代码中，我从该内存中的数组中读取一个值并将其分配给局部变量。声明是这样的:

typedef enum
{
     eType0 = 0,
     eType1 = 1,
} type_t;

type_t    arr_type;
uint32_t *array  = BUF_ADDR; // array on periph. memory
uint32_t  offset = 0;

arr_type = (type_t) array[offset]; // exception!

运行此代码时，读取内存时出现异常。碰巧这个赋值生成了汇编代码:

LDRB R1, [R2, R3, LSL #2]; // R2=array, R3=offset

即使我添加括号并显式转换表达式也是如此:

type = (uint32_t) (array[offset]);

解决这个问题的方法是将 arr_type 声明为 uint32_t 而不是 type_t。现在，代码是:

LDR R1, [R2, R3, LSL #2];

这是预期的行为吗？我假设括号和转换(如果不是 array 指针的自然类型)将使编译器生成和 LDR 指令。因此这看起来像一个错误。

Answer 1

编译器通常可以使用它想要的任何加载指令，只要它能正常工作，从程序本身的角度来看，就像执行了 array[offset] 隐含的 32 位加载一样。由于加载的值在存储在 arr_type 中时最终被截断为 8 位，因此如果编译器改为使用 8 位加载，它不会更改存储在 arr_type 中的值.

要告诉编译器内存访问的大小很重要并且在程序本身之外有可见的影响，您应该使用 volatile 限定符。

type_t    arr_type;
uint32_t volatile *array = BUF_ADDR;
uint32_t  offset = 0;

arr_type = (type_t) array[offset]; 

更一般地说，在执行任何类型的内存映射 I/O 时，您应该使用 volatile 限定符。它不仅确保始终使用预期大小(如果可能)执行访问，还保证不会删除或重新排序访问。