易失性和非易失性位域

Question

我正在为 Cortex-M0 CPU 和 gcc 编写代码。我有以下结构：

struct {
    volatile unsigned flag1: 1;
    unsigned flag2: 1;

    unsigned foo; // something else accessed in main loop
} flags;

flag1 从 GPIO 中断处理程序和主循环中读取和写入。 flag2 只能在主循环中读写。

ISR 如下所示：

void handleIRQ(void) {
    if (!flags.flag1) {
        flags.flag1 = 1;
        // enable some hw timer
    }
}

主循环如下所示：

for (;;) {
    // disable IRQ
    if (flags.flag1) {
        // handle IRQ
        flags.flag1 = 0;
        // access (rw) flag2 many times
    }
    // wait for interrupt, enable IRQ
}

在主循环中访问flag2 时，编译器是否会优化对它的访问，使其不会在每次在代码中读取或写入时都被提取或存储到内存中？

我不清楚，因为要在 ISR 中设置 flag1，它需要加载整个 char，设置一个位并将其存储回来。

Answer 1

根据我对 C11 标准的解读，为此使用位域是不合适的——即使它们都被声明为 volatile。以下摘自3.14 Memory location：

1. 内存位置
   要么是标量类型的对象，要么是具有非零宽度的相邻位域的最大序列

2. 注意 1 两个执行线程可以更新和访问单独的内存位置，而不会相互干扰。

3. 注意 2 如果同时更新同一结构中的两个非原子位域是不安全的 在它们之间声明的成员也是（非零长度）位域，无论它们的大小如何 中间的位域恰好是。

volatile 也不例外。因此，如果两个执行线程（即主线程和 ISR）如果 ISR 将更新一个标志而主线程将更新另一个标志，则使用上述位域是不安全的。给出的解决方案是在两者之间添加一个大小为 0 的成员，以强制将它们放置在不同的内存位置。但是话又说回来，这意味着这两个标志都会消耗至少一个字节的内存，因此为它们使用非位字段 unsigned char 或 bool 再次变得更简单：

struct {
    volatile bool flag1;
    bool flag2;

    unsigned foo; // something else accessed in main loop
} flags;

现在它们将被放置在不同的内存位置，并且可以在不相互干扰的情况下更新它们。

---

然而，flag1 的 volatile 仍然是绝对必要的，因为否则对 flag1 的更新将在主线程中无副作用，并且编译器可以推断它可以保持仅在寄存器中的该字段 - 或者根本不需要更新任何内容。

但是，需要注意的是，在 C11 下，即使是 volatile 的保证也可能不够：5.1.2.3p5：

当抽象机的处理因收到信号而中断时，既不是无锁原子对象也不是 volatile sig_atomic_t 类型的对象的值是未指定的，浮点环境的状态也是如此。处理程序修改的任何对象（既不是无锁原子对象也不是 volatile sig_atomic_t 类型）的值在处理程序退出时变得不确定，如果浮点环境的状态被处理程序修改且未恢复，则它的状态也是不确定的恢复到原来的状态。

因此，如果需要完全兼容，flag1 应该是例如volatile _Atomic bool 类型；甚至可以使用_Atomic 位域。然而，这两者都需要 C11 编译器。

然后，您可以检查编译器的手册，如果它们保证对此类易失性对象的访问也保证是原子的。

Answer 2

只有一位的 volatile 标志并不是那么有意义 - 它甚至可能是有害的。编译器在实践中可能做的是分配两块内存，可能每块 32 位宽。因为 volatile 标志阻止它在同一分配区域内组合两个位，因为没有可用的位级访问指令。

在主循环中访问 flag2 时，编译器是否会优化对它的访问，使其不会在每次在代码中读取或写入时都被提取或存储到内存中？

这很难说，取决于有多少数据寄存器可用。反汇编代码看看。

总体而言，不建议使用位域，因为标准对它们的定义很差。在这种情况下，单个 volatile 位可能会导致分配额外的内存。

相反，您应该这样做：

volatile bool flag1;
bool flag2;

假设这些标志不是硬件寄存器的一部分，在这种情况下，代码从一开始就不正确，它们都应该是易失性的。