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

Question

我正在开发一个嵌入式系统，其中包括一个 ARM Cortex-M4 CPU 和一些外围设备。其中一个外围设备包含可从 CPU 端（通过 AHB 总线）访问的 SRAM 块，但访问必须是字大小的事务（使用 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 限定符。它不仅确保始终使用预期大小（如果可能）执行访问，还保证不会删除或重新排序访问。

Answer 2

如果您使用标志 --enum_is_int 进行编译，您对枚举的访问将是 32 位且对齐的。

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

Is this an ARM Compiler code generation error?

c

embedded

assembly

arm

ds-5