[参考译文] AM2434：尝试写入 PRU 时 GCC memcpy 停止

尊敬的 Alvaro：

请预计响应会有延迟。 将在本周结束之前返回到您的查询。 同时、您可以继续使用您的权变措施。

此致、
亚伦

大家好、Aaron：

感谢您的答复。 我不着急

此致！

Álvaro μ A

感谢您的耐心 Alvaro。

此致、

亚伦

尊敬的 Aaaron：

我希望你做得好。 您有任何关于此主题的更新吗？

提前感谢、

Álvaro μ A

我也看到了这个问题、但略有不同、所以我将在这里添加我的问题。

我`签署` ti-cgt-armllvm_3.2.LTS 编译器。 在一行的 tiescbsp.c 中打开优化(-O2和-OS)时、会发生未对齐的内存访问问题

tiesc_memset(pRegPermUpdateAddr, TIESC_PERM_READ_ONLY, SYNC_PERMISSION_UPDATE_PDI_SIZE);
// equivalent to
tiesc_memset(0x48000522, 0x02, 10);

似乎正在对 memset 进行优化  

// r0 = 0x48000000
// r1 = 0x0202
// r2 = 0x02020202
strh.w  r1, [r0, #0x52a]
str.w   r2, [r0, #0x526]
str.w   r2, [r0, #0x522]

这会导致未对齐访问错误、因为它正在尝试在仅为字对齐的地址进行 DWORD 存储。 从我可以告诉步进通过具有-O0的内置 memset 的汇编,它最终会 像这样做这些存储

// r0 = 0x48000000
// r1 = 0x02020202
strh.w  r1, [r0, #0x522]
str.w   r1, [r0, #0x524]
str.w   r1, [r0, #0x528]

这些是正确对齐的存储、但会生成高度未优化的代码。 我可以通过找到所有的地方 memset 最终做未对齐的商店,并手动替换它们来解决这个问题,但会更倾向于一个更好的解决方法。

我想知道为什么编译时优化的 memset 不会使用未对齐的存储、而内置 memset 不会使用。 不过、这似乎是常规的 clang / llvm 行为、如 该简化示例所示。

Unknown 说：

我有编译器标志"-munaligned-access"

在基于 gcc 的 AM335x 实现中、我们使用的是 -MnO-UNaligned-access。 munaligned-access 将启用这一功能！！！

-munaligned-access-mno-unaligned-access

启用(或禁用)从非16或32位对齐的地址读取和写入16和32位值。 默认情况下、对所有预 ARMv6、所有 ARMv6-M 和 ARMv8-M 基线架构禁用未对齐访问、并对所有其他架构启用。 如果未启用未对齐访问、则每次访问一个字节的打包数据结构中的字。  

这最终取决于 TI 无法控制的 libc memcpy 实现。 不管怎么说,检查这,让我们知道...

看起来将 _attribute ((noinline))添加到  tiesc_memset 最终会生成相同的结果。 它会强制调用 libc memset、对于 clang、libc memset 仅进行对齐存储器访问。  

__attribute((noinline)) void * tiesc_memset(uint8_t *dst, int8_t val, uint32_t size_bytes)
{
    memset(dst, val, size_bytes);
    return dst;
}

我喜欢这个解决方案,因为它允许程序的其余部分利用硬件的功能,并且它可以在 clang 和 gcc*之间移植。

*我没有测试 gcc, libc memset 函数可能会在允许的情况下尝试执行未对齐的内存写入。

您好、Pratheesh：

我已经尝试过 -MNO-unaligned-access、但我有相同的问题。

以下是我的编译标记：

此致、

Álvaro μ A