C 代码中的内联汇编语句和适用于 ARM Cortex 架构的扩展 ASM

我正在尝试编译以下两段代码ARM编译器5对于 Cortex A 微处理器：

Part 1:

static inline void cp15_write_sctlr(uint32_t value)
{
    asm("mcr p15, 0, %0, c1, c0, 0" :: "r"(value));
}

static inline uint32_t cp15_read_actlr(void)
{
    uint32_t actlr;
    asm("mrc p15, 0, %0, c1, c0, 1" : "=r"(actlr));
    return actlr;
}

Part 2:

static inline void dmb(void)
{
    asm("dmb" ::: "memory");
}

static inline void dsb(void)
{
    asm("dsb" ::: "memory");
}

static inline void isb(void)
{
    asm("isb" ::: "memory");
}

在这两种情况下我都会遇到编译错误。请参阅下面的示例。

line 64: Error:  #18: expected a ")"
    asm("dsb" ::: "memory");

该错误是由编译器版本（ARM编译器5）引起的，它不支持扩展Asm吗？

如果我重写代码Part 1如下，我没有收到任何错误。以下代码与第 1 部分中的代码等效吗？

static inline void cp15_write_sctlr(uint32_t value)
{
    __asm
    {
        MCR p15, 0, value, c1, c0, 0
    }
}

static inline uint32_t cp15_read_actlr(void)
{
    uint32_t actlr;
    __asm
    {
        MRC p15, 0, actlr, c1, c0, 1
    }
    return actlr;
}

如果编译器不支持扩展 Asm，我如何重写第 2 部分中的代码？ 我想到了以下内容，但我不确定是否相同。

static inline void dmb(void)
{
    __schedule_barrier();
    __asm("dmb");
    __schedule_barrier();
}

static inline void dsb(void)
{
    __schedule_barrier();
    __asm("dsb");
    __schedule_barrier();
}

static inline void isb(void)
{
    __schedule_barrier();
    __asm("isb");
    __schedule_barrier();
}

任何帮助将非常感激。

该错误是由编译器版本（ARM编译器5）引起的，它不支持扩展Asm吗？

这是 GNU C 内联扩展 Asm 语法，所以显然不支持它的编译器会出错。

2016 年 GCC 变化 (PR24414) 给非空 Basic Asm 语句一个隐式的"memory"破坏，以及使它们隐式破坏"cc"在像 x86 这样的目标上，扩展 asm 就可以做到这一点。所以如果你的 GCC 版本足够新，我想你could能够在这里安全地使用 Basic Asm，假设未记录的 GCC 行为继续存在于未来的 GCC 版本中，以帮助编写得不好或旧的代码按照其可能的预期方式工作。 （假设这在 Keil 中实际上也是安全的，那里也有隐式内存屏障）。我不知道这会变成什么 GCC 版本

（跨 asm 语句存储和重新加载全局的试金石将告诉您在任何给定的 GCC 版本上它的行为如何。如果您看到寄存器值被重用asm("" ::: );（扩展时明确没有内存破坏）但不适用于asm("# comment");（非空 Basic），这意味着非空 Basic asm 语句具有隐式内存破坏。否则，您会期望获得与扩展相同的优化。这Godbolt 编译器资源管理器链接显示 GCC 6.4 确实notBasic asm 有一个隐式的 mem clobber，但 GCC7.1 有。

或者更好的是，你可以使用 CPP 宏#if检测错误的编译器并忽略::: "memory"它窒息的部分，假设它将 asm 语句视为具有内存破坏。或者检测__GNUC__ and __GNUC_MINOR__版本等，并使用它来检测任何声称与支持扩展 asm 的 GNU 方言版本兼容的编译器。

绝不能在 GNU C 的函数内部使用基本 Asm，即使对于像这样的指令dsb不读取或写入寄存器，因为没有书面保证订购 wrt。编译器生成的内存访问。https://gcc.gnu.org/wiki/ConvertBasicAsmToExtended。通常你应该只将它用于身体__attribute__((naked))函数，或在全局范围内。

Basic asm 没有什么优势；内联汇编是您永远不应该随意使用的东西，并且您可以使用 Basic 做任何事情，而不能在非裸函数中使用 Extended 显式做。 （实际上，您几乎无法使用 Basic 安全地执行任何操作：您无法安全地触摸寄存器，甚至无法安全地触摸内存中的全局变量（请参阅this，并且不保证可以订购。任何事物。）

因此，依赖于未记录的具有隐式基本 Asm 行为是很糟糕的"memory"破坏。隐式 mem clobber GCC 更改没有充分的理由（除了可能使旧的和/或坏的代码更有可能正常工作）；在 GNU C 中，扩展 asm 来明确这一点总是更好。

Keil支持吗stdatomic.h for atomic_thread_fence(memory_order_seq_cst)发出无法与周围代码重新排序的“dmb”？ （不过对 dsb 和 isb 没有帮助）。