有很多关于volatile变量及其用法的说法和文章。在这些文章中,可以找到两个略有不同的想法:
1 - 当变量在编译程序之外被更改时,应该使用Volatile 2 - 当变量在函数的正常流量之外变化时,应该使用Volatile。
第一个语句限制了对内存映射寄存器等的易失性使用和多线程内容,但第二个实际上将中断添加到了作用域中。
本文(http://www.barrgroup.com/Embedded-Systems/How-To/C-Volatile-Keyword)举例说明了volatile修饰符应该用于中断期间更改的全局变量,并提供了这个示例:
int etx_rcvd = FALSE;
void main()
{
...
while (!ext_rcvd)
{
// Wait
}
...
}
interrupt void rx_isr(void)
{
...
if (ETX == rx_char)
{
etx_rcvd = TRUE;
}
...
}
注意如何在这里方便地省略设置rx_isr()作为回调。 因此我写了我自己的例子:
#include <stdio.h>
#include <time.h>
#include <signal.h>
void f();
int n = 0;
void main()
{
signal(2,f);
time_t tLastCalled = 0;
printf("Entering the loop\n");
while (n == 0)
{
if (time(NULL) - tLastCalled > 1)
{
printf("Still here...\n");
tLastCalled = time(NULL);
}
}
printf ("Done\n");
}
void f()
{
n = 1;
}
使用各种优化级别的linux上的gcc编译,每次循环退出时,当我按下ctrl + c时,我看到“完成”,这意味着真正的gcc编译器足够聪明,不能在此优化变量n。
那就是说,我的问题是:
如果编译器可以真正优化由中断服务例程修改的全局变量,那么:
1.当可以从另一个文件中调用全局变量时,为什么它有权优化全局变量?
2.为什么互联网上的示例文章和许多其他文章表明编译器不会“注意到”中断回调函数?
3.如何修改代码才能完成此任务?
答案 0 :(得分:6)
因为您有对外部函数的函数调用,所以while循环每次都会检查n
。但是,如果删除这些函数调用,优化程序可能会注册或取消n
的任何检查。
Ex(gcc x86_64 -O3):
volatile int n;
int main() {
while(n==0) {}
return 0;
}
变为:
.L3:
movl n(%rip), %eax
testl %eax, %eax
je .L3
xorl %eax, %eax
ret
但是
int n;
int main() {
while(n==0) {}
return 0;
}
成为:
movl n(%rip), %eax
testl %eax, %eax
jne .L2
.L3:
jmp .L3
在这种情况下,永远不会在无限循环中查看n
。
如果有一个修改全局的信号处理程序,你真的应该标记全局volatile。你跳过这个可能不会遇到麻烦,但是你要么运气好,要么指望优化者无法验证全局是否被触及。
在链接时(llvm)交叉模块优化中存在一些变动,因此有一天优化程序可能会告诉time
或printf
的调用不是触摸文件中的全局变量。发生这种情况时,即使您有外部函数调用,错过volatile关键字也可能会导致问题。
答案 1 :(得分:2)
如果编译器可以真正优化由中断服务例程修改的全局变量,那么:
- 当可以从另一个文件中调用全局变量时,为什么它有权优化全局变量?
醇>
这里的关键是在没有中断的“普通”单线程程序中,全局变量不能随时修改。无论访问哪个文件,所有对变量的访问都以可预测的方式排序。
优化可能很微妙。它不是那么简单,“啊,好像这个全局似乎没有被使用,让我们完全删除它”。相反,对于像
这样的代码while(global)
{
do_stuff(global);
}
优化器可能会创建类似于:
的行为register tmp = global;
loop:
do_stuff(tmp);
goto loop;
完全改变了程序的含义。由于缺乏挥发性而导致的这种错误如何总是与案例有所不同。他们很难找到。
- 为什么互联网上的示例文章和许多其他文章都说编译器不会“注意到”中断回调函数?
醇>
因为嵌入式编译器在这方面传统上是愚蠢的。传统上,当编译器发现你的非标准中断关键字时,它只会做两件事:
现在可能有更聪明的编译器。 PC /桌面编译器在处理回调函数/线程时面临同样的问题,但它们通常足够聪明,意识到它们不应该假设与回调共享的全局变量。
在优化方面,嵌入式编译器传统上比PC /桌面编译器更加笨重。它们通常质量较差,而且标准合规性较差。如果您是支持特定目标或可能是唯一供应商的少数编译器供应商之一,那么缺乏竞争意味着您不必担心质量问题。你可以出售废话并为此收取很多费用。
但是,即使是优秀的编译器也可能会遇到这样的情况,特别是那些对“目标x”中的中断等工作方式一无所知的多平台编译器。
所以你有一个好的,多平台的编译器太通用来处理这个bug的情况。与此同时,“目标x”的糟糕,狭窄的编译器编写得太差,无法处理它,即使它应该知道中断如何在“目标x”上工作。
- 如何修改代码才能完成此操作?
醇>
制作此类全局volatile
。