在没有编译器优化的情况下，特定于平台扩展的 volatile-specifier 替换为硬件寄存器访问？

Question

在 C++20 及更进一步的版本中，变量的 volatile 说明符在很大程度上已被弃用。 使用 GCC 的嵌入式开发人员长期以来一直依赖这个（有缺陷的）说明符。 代码图中可能出现副作用的概念，代码中的 C++ 语句不清楚，这不是一个好的 C++ 核心语言标准想法。 GCC 实现了它自己的 C++ 语言版本，并为 volatile-specifier 赋予了重要意义。 是否有任何特定于 GCC 的方式（可能正在开发中？？？）将 C++ object 正确标记为“不要不合理地假设内容”？ 我对自然的 C++ 语言驱动的赋值操作非常感兴趣，甚至是复合操作。 我知道弃用是由于编译器和 MCU/CPU 指令生成的错误解释的历史问题，因此我们并不是批评 C++ 标准本身。

Answer 1

是否有任何特定于 GCC 的方式（可能正在开发中？？？）将 C++ object 正确标记为“不要不合理地假设内容”？

这就是volatile的意思。 对这种语法结构的需求是volatile仍然存在的主要原因之一。 事实上， 引入弃用对volatile值的某些操作的提案将此作为其主要目标之一：

继续支持历史悠久的 volatile 用法来加载和存储用于共享 memory、信号处理、setjmp / longjmp 或其他外部修改（如特殊硬件支持）的变量。

因此，您正在寻找的工具仍称为volatile 。 所发生的变化只是删除了一些对volatile对象的操作。 不仅没有宣布从语言中完全删除volatile的意图，而且人们清楚地认识到它是一个有用的工具。

---

GCC 实现了它自己的 C++ 语言版本，并为 volatile-specifier 赋予了重要意义。

这是不正确的。 volatile不是告诉编译器做任何事情的神奇标志。 事实上，它恰恰相反：它告诉编译器它不能随便做什么。 它强制编译器按照代码的文字文本的要求发出加载和存储，即使编译器看不到第二次加载可能获得不同值的任何方式。

如上所述， volatile是一种多功能工具，可用于与特定硬件密切相关的各种结构。 Memory-mapped IO寄存器可以通过一个volatile object来读取，其地址分配给MMIO寄存器的地址。 虽然将该 object 映射到该地址可能需要在 C++ 标准之外输入，但您说您想要volatile行为的方式是标准的一部分。

也就是说，假设您正在编写要移植到两个不同设备的代码。 它们都有一个 MMIO 寄存器，功能基本相同，但它们位于不同的地址。 当您为每个设备构建时，您可以为变量分配适当的 memory 地址，可能是通过特定于平台的宏或其他构建命令。 但是您编写的访问它们的代码是相同的，因为volatile不是特定于平台的。

volatile是一个平台中立的工具，允许您访问特定于平台的东西。 没有理由让每个编译器都用自己的方式说，“我将按照您的代码字面意思读取和写入这个 memory 位置”。