关于挥发性使用的基本问题 [英] A basic question question about volatile use

问题描述

我有一个带有映射的内存映射外设，例如，

struct T {uint8_t read，write，status，forkicks;};


如果我在struct T类型的对象上打了一个volatile，它是否保证

所有对成员的访问都是字节宽的，或者编译器是免费的

到读取或读取 - 修改 - 写入它选择的任何数据宽度？


是否在结构定义的每个成员上打了一个volatile？

不同？更好？更糟糕的是？


谢谢，

方舟

I have a memory-mapped peripheral with a mapping like, say,
struct T {uint8_t read, write, status, forkicks;};

If I slap a volatile on an object of type struct T, does it guarantee
that all accesses to the members are byte-wide, or is the compiler free
to read or read-modify-write in any data width it chooses?

Is slapping a volatile on each member of the struct definition any
different? better? worse?

Thank you,
Ark

推荐答案

> I有一个带有映射的内存映射外设，例如

>I have a memory-mapped peripheral with a mapping like, say,

> struct T {uint8_t read，write，status，forkicks;};
<如果我在struct T类型的对象上使用volatile，它是否保证所有对成员的访问都是字节范围的，或者编译器是否可以自由阅读或读取 - 修改 - 写入它选择的任何数据宽度？

>struct T {uint8_t read, write, status, forkicks;};

If I slap a volatile on an object of type struct T, does it guarantee
that all accesses to the members are byte-wide, or is the compiler free
to read or read-modify-write in any data width it chooses?

我不相信标准中的任何内容都能保证内存映射I / O的正确价值（模糊的承诺）不够好），

但是如果你的系统的编译器支持内存映射的I / O和

用于实际使用内存映射编译驱动程序我/ O，机会

比使用volatile更好。阅读

编译器应附带的具体文档。


如果你的系统实际上需要处理获取I / O的宽度

正确，很可能编译器也会这样。

I don''t believe that anything in the standard guarantees the right
thing for memory-mapped I/O (the vague promises aren''t good enough),
but if the compiler for your system supports memory-mapped I/O and
is used to actually compile drivers using memory-mapped I/O, chances
are much better that it will work using volatile than not. Read
the specific documentation that should come with your compiler.

If your system actually has to deal with getting the width of I/O
correct, chances are the compiler will also.

>在结构定义的每个成员上打一个volatile是否不同？更好？更差？

>Is slapping a volatile on each member of the struct definition any
different? better? worse?

这完全取决于你的编译器。

It depends entirely on your compiler.

Ark Khasin写道，31/07 / 08 06:23：

Ark Khasin wrote, On 31/07/08 06:23:

我有一个带有映射的内存映射外设，例如，

struct T {uint8_t read，写，状态，forkicks;};

I have a memory-mapped peripheral with a mapping like, say,
struct T {uint8_t read, write, status, forkicks;};

请注意，允许编译器填充填充。因为对于非可移植代码来说这显然是
，所以只需在代码中输入

注释即表示你依赖编译器而不是

输入任何填充。

Be aware that the compiler is allowed to put in padding. Since this is
obviously for non-portable code it might be sufficient to just put in a
comment in the code stating that you are relying on the compiler not
putting in any padding.

如果我在struct T类型的对象上打一个volatile，它是否保证

对成员的所有访问都是字节范围的，或者编译器是否可以免费读取或读取 - 修改 - 写入它选择的任何数据宽度？

If I slap a volatile on an object of type struct T, does it guarantee
that all accesses to the members are byte-wide, or is the compiler free
to read or read-modify-write in any data width it chooses?

编译器对volatile的要求非常宽松，甚至

离开是由实现来定义什么算作访问

变量。所以你应该阅读你的编译器文档。


想象一个处理器，它只能以64位/ b
位的块进行物理读/写但是它仍然有一个编译器正常 8位字节。

在这样的实现上，如果结构没有任何填充，

编译器将无法阻止添加所有字节。


话虽如此，我希望*编译器在你的情况下做正确的

事情（tm）。我希望这是因为没有这样做

我猜测是针对小型嵌入式设备的编译器会使用b $ b使得它难以使用。

The requirements on the compiler for volatile are quite lax and even
leave is up to the implementation to define what counts as accessing a
variable. So you should read your compiler documentation.

Imagine a processor which can physically only read/write in chunks of 64
bits but which nevertheless has a compiler with a "normal" 8 bit byte.
On such an implementation if the structure did not have any padding the
compiler would not be able to prevent all bytes being added.

Having said that, I would *expect* the compiler to "do the right
thing"(tm) in your case. I would expect this because by not doing so on
what I''m guessing is a compiler targeting a small embedded device would
make it hard to use.

是否在结构定义的每个成员上打了一个volatile？

不同？更好？更差？

Is slapping a volatile on each member of the struct definition any
different? better? worse?

这可能不方便。我有时想要做的一件事是使用

a结构的一般类型，对于一些正常内存的东西

（没有volatile限定符）和内存映射设备。

volatile-qualifying成员会让这个尴尬。


还有一个论点，你不应该使用这个结构

目的*因为*它可能有填充，但如果你的代码与

连接到HW很好地隔离并且编译器文档

说它会工作，然后因为它是高度系统特定的，所以我不会看到一个真正的问题。


对不起，最好的建议是阅读编译器文档，但它确实是你确保它正常工作的最佳机会。
接下来最好的

建议将在专门用于您的特定

实施的小组中或在comp.arch.embedded中询问哪里有更多
$ b比这个

组中经常做这种事情的$ b人。


注意你的问题*是*这里的主题因为volatile *是*

标准语言的一部分，只是为了实现你的目标，你需要超越语言的保证，以及你所保证的事情。
/>
具体实施。

-

Flash Gordon

It could be inconvenient. One thing I''ve sometimes wanted to do was use
a structure of that general type both for some in-normal-memory stuff
(without the volatile qualifier) and for the memory-mapped device.
volatile-qualifying the members would make this awkward.

There is also an argument that you should not use a struct for this
purpose *because* it could have padding, but if your code for
interfacing to the HW is nicely isolated and the compiler documentation
says it will work, then as it is highly system specific anyway I don''t
see a real problem.

Sorry that the best advise is to read the compiler documentation, but it
really is your best chance to ensure it works correctly. The next best
advice would be asking in a group dedicated to your specific
implementation or in comp.arch.embedded where there are a lot more
people who are regularly doing this kind of thing than there are in this
group.

Note your question *is* topical here since volatile *is* part of the
standard language, it''s just that to achieve your aims you need to go
beyond the guarantees of the language to things guaranteed by your
specific implementation.
--
Flash Gordon

Gordon Burditt写道：

Gordon Burditt wrote:

>我有一个内存映射的外围设备，其映射类似于
struct T {uint8_t read，write， status，forkicks;};

如果我在struct T类型的对象上打一个volatile，它是否保证所有对成员的访问都是字节范围的，或者是compil你自由选择读取或读取 - 修改 - 写入的任何数据宽度？

>I have a memory-mapped peripheral with a mapping like, say,
struct T {uint8_t read, write, status, forkicks;};

If I slap a volatile on an object of type struct T, does it guarantee
that all accesses to the members are byte-wide, or is the compiler free
to read or read-modify-write in any data width it chooses?

我不相信标准中的任何内容都能保证内存映射I / O的权利（模糊的承诺）是不够好的），

I don''t believe that anything in the standard guarantees the right
thing for memory-mapped I/O (the vague promises aren''t good enough),

如果它不是I / O但是正常的内存位置有什么意图

byte-大小会员？ （顺便问一下，为什么不同？）


谢谢，

方舟

What if it is not an I/O but a normal memory location with intended
byte-size members? (BTW, why the difference?)

Thanks,
Ark

这篇关于关于挥发性使用的基本问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！