32 位 GCC 编译器存储和操作 char 数组答案

【问题标题】：32 Bit GCC Compiler storage and manipulation of char arrays32 位 GCC 编译器存储和操作 char 数组
【发布时间】：2020-03-30 17:50:25
【问题描述】：

背景：我是 32 位编译器的新手，并使用新采用的目标创建例程来操作嵌入式系统的字符数组：使用 GCC 32 位编译器的 SiLabs Leopard Gecko 处理器。

问题：我们的嵌入式系统上的内存是有限的，我试图了解编译器如何存储字符数组，以便我们有效地使用可用的 RAM 和闪存。编译器报告以 4 字节为增量递增的 RAM 使用情况，这符合默认的 32 位字长（即 char X[1] 到 char X[4] 都导致 RAM 分配 4 字节，char[5] 导致分配8 个字节的报告）。

据我了解，编译器会将所有变量存储为 32 位值（long 等除外）

问题：上述内存报告是否暗示编译器创建了必要的汇编代码以将 char[4] 打包成单个 32 位字并在我要编写诸如 char Y = 之类的行时处理字节解析字符数组[2] ?

【问题讨论】：

如果是C编译器，编译器将符合C语言标准。
我使用的架构在其 EABI 中表明堆栈应该以 8 个字节分配。因此，如果我要创建一个 9 字节的 char 数组，它将导致分配 16 个字节。我假设这种架构也会发生类似的事情。我不认为这个架构在做你描述的这种打包事情，如果它有一个加载字节命令。
@Eraklon 不，这是不正确的。只有在异常处理期间，堆栈才需要对齐。它可以由硬件完成，也可以留给程序员完成。它不是 EABI - 它是硬件。但这里不相关。
@EOF OP 询问 gcc 而不是 C 编译器。
@P__J__ 我不想告诉你，但 gcc 是一个 C 编译器（以及其他语言）。

标签： c arrays 32-bit

【解决方案1】：

这不是分配。 Silab Gecko 是基于 ARM M-3 的 uC。此 uC 对对齐敏感，链接器以这种方式放置对象，以使地址可被4 整除，以避免对齐问题。它在链接描述文件中定义。

【讨论】：

从您的回答中并不清楚对齐如何影响分配，因为 char[4] 和 char[5] 都以相同的方式对齐。您可能应该澄清一下，即使 char[5] 的“可用”内存仍然是 5 个字节，尾随的 3 个字节也必须被消耗，因为没有其他东西可以放在那里（因为它会变得未对齐）。
@GSerg 您可以绝对将内存用于单个 16 位 [unsigned] short 和单个 8 位 [unsigned] char 或三个 [unsigned] chars。
@EOF 是否可以免除对齐要求？如果是这样，这个答案就站不住脚了。
了解对齐方面。但是，如果我到目前为止了解 cmets，则 char X[3] 的声明只会消耗 3 个字节（尽管是一个 32 位字），并且编译器/链接器将处理字节屏蔽/移位以做出诸如 Y = X 之类的语句[2] 工作。我知道作为 C 语句它会起作用，核心问题是关于内存。所以编译器将有助于有效地使用 RAM，但我怀疑汇编代码的大小会受到一点影响。没有？
@BobK silabs.com/mcu/32-bit/efm32-leopard-gecko 建议底层处理器是 ARM cortexm3，它具有原生字节和短加载/存储指令。不需要移位/屏蔽。