zoukankan      html  css  js  c++  java
  • volatile 使用说明

    volatile 影响编译器编译的结果,指出,volatile 变量是随时可能发生变化的,与volatile变量有关的运算,不要进行编译优化,以免出错,(VC++ 在产生release版可执行码时会进行编译优化,加volatile关键字的变量有关的运算,将不进行编译优化。)。

    例如:
    volatile int i=10;
    int j = i;
    ...
    int k = i;

    volatile 告诉编译器i是随时可能发生变化的,每次使用它的时候必须从i的地址中读取,因而编译器生成的可执行码会重新从i的地址读取数据放在k中。

    而优化做法是,由于编译器发现两次从i读数据的代码之间的代码没有对i进行过操作,它会自动把上次读的数据放在k中。而不是重新从i里面读。这样以来,如果i是一个寄存器变量或者表示一个端口数据就容易出错,所以说volatile可以保证对特殊地址的稳定访问,不会出错。

    ==============================================
    建议使用volatile变量的场所:
    (1) 并行设备的硬件寄存器
    (2) 一个中断服务子程序中会访问到的非自动变量(全局变量)
    (3) 多线程应用中被几个任务共享的变量

    不鼓励使用volatile,即使要用也要很小心,因为volatile可能在无意中降低了代码效率,而你却无法察觉


    ==============================================
    根据c/c++语法,const可以出现的地方,volatile几乎也都可以出现。但是,const修饰的对象其值不能改变,而volatile修饰的对象其值可以随意地改变,也就是说,volatile对象值可能会改变,即使没有任何代码去改变它。在这一点上,最典型的例子就是内存映射的设备寄存器和多线程中的共享对象。懂得使用volatile也是一门小小的艺术。使用volatile约束符可以阻止编译器对代码过分优化防止出现一些你意想不到的情况,达不到预期的结果;过频地使用volatile很可能会增加代码尺寸和降低性能。下面举个例子来说明volatile在优化中的微妙作用。

    1.阻止编译器优化
      ARM Evaluator-7T模拟单机板使用基于内存映射的设备寄存器叫特殊寄存器,用来
    控制和交互外围设备。CPU对内存的操作可以做到按位进行,而特殊寄存器是4字节对齐并占四个字节。你可以象unsigned int变量一样操作特殊寄存器(有些人可能更喜欢uint32_t,认为这样体现寄存器占用4个字节的特点。uint32_t在C99 头文件<stdint.h>中有定义)。而这里,为了体现寄存器本身作为寄存器的含义而非它的物理意义的,我们做如下定义:
    typedef uint32_t special_register;

      Evaluator-7T板子上有一个按钮(可以认为是外设之一)。按下该按钮可以对IOPDATA寄存器第8位置1,相反,释放按钮会将该位重新清0。我们使用枚举方法为IOPDATA寄存器的第8位置定义一个掩码mask:
    enum { button = 0x100 };

    IOPDATA寄存器对应的地址为0x3FF5008,我们可以用宏形象地定义IOPDATA:

    #define IOPDATA (*(special_register *)0x03FF5008)

    有了这个定义,我们执行下面的循环就可以使CPU一直等待该按钮被按下:
    while ((IOPDATA & button) == 0)
        ;

      然而这个期望必须建立在编译器不对代码进行优化的前提假设之上。如果编译器优化这段代码,那么它会认为在这个循环中没有什么会改变IOPDATA而且认为条件判断结果总是真或假,最终优化的结果是只对(IOPDATA & button)==0判断一次,之后的循环都不在对其进行判断,其等同于:
    if ((IOPDATA & button) == 0)
        for (;;)
            ;

      显然,如果条件判断结果为真(那么之后都会认为是真),那么这段代码将会陷入死循环。如果判断为假,那么循环就此结束。可以看出,优化的代码效率更高,因为每次循环相比原来的执行时间要短。不幸的是,这段优化代码使得它根本就不能响应按钮的每次动作。那么,如何解决这个问题呢?解决的关键就是不要让编译器优化这段代码,使用volatile就可以办到这一点。我们修改前面关于IOPDATA的宏定义:
    #define IOPDATA (*(special_register volatile *)0x03FF5008)

    这个定义将IOPDATA 定义为volatile类型的寄存器。volatile隐含地告诉编译器特殊寄存器可能会改变内容,即使没有任何显式地代码去改变它的内容。这样一来,编译器就不对IOPDATA作优化,而是每次都去访问IOPDATA,这其实正是我们所期望的。

    2.无意中降低了效率
      有时候,如果不注意的话,使用volatile会无意中降低代码效率。举个例子。Evaluator-7T有一个七段数码显示器见下图:

              

      在IOPDATA 寄存器中第10到16位用来控制显示器的每一段。比如第10位就是用来控制顶部的那段显示,置1则点亮它,清0则熄灭它。我们可以定义一个掩码mask来覆盖从第10到16的所有位:
    enum { display = 0x1FC00 };
    假设变量b用来控制这7段显示器的每一段显示,并且b的值已经你想要设置值(准备用来显示哪几段和熄灭哪几段,其它无关的位均为0)。那么你想要改变设置新的显示方式的操作就是:
    IOPDATA = b;
    但是这种赋值可能会改变第10到16位之外的其它位,这是我们不期望的。所以,采用下面的方法更好:
    IOPDATA |= b
    但是,使用 |= 并不能熄灭那些已经点亮的显示段(1 | 0 -> 1),所以我们可以用下面的函数达到目的:
    void display_put(uint32_t b)
    {
        IOPDATA &= ~display;    /*熄灭所有的段*/
        IOPDATA |= b;        /*点亮想要的段*/
    }

      不过,可能没想到的是这样的操作在无意中降低了代码效率。因为我们定义IOPDATA为
    volatile类型,它阻止了编译器对代码的优化,要求任何读写IOPDATA的操作都死死板板地进行。IOPDATA &= ~display的等价表现为IOPDATA = IOPDATA & ~display,也就是先从IOPDATA读出内容然后与上~display,最后又回写IOPDATA。同理,IOPDATA |=b也有相似的过程。整个过程分别有2次读IOPDATA和2次写IOPDATA的操作。如果IOPDATA不使用volatile,那么编译器会要求将IOPDATA & ~display的结果放在CPU寄存器中,直到完成IOPDATA |= b操作才写回特殊寄存器IOPDATA。显然后者较之前者分别省掉了1次读IOPDATA和1次I写OPDATA的耗时操作(外设操作是最耗时的),效率要高很多。如果你想使用volatile但又能使能优化功能,你可以将函数作如下的修改:

    void display_put(uint32_t b)
    {
        register uint32_t temp = IOPDATA;/*定义局部变量*/
        temp &= ~display;         /*读取IOPDATA内容到temp*/
        temp |= b;              /*将temp内容或上b*/
        IOPDATA = temp;          /*将结果写回IOPDATA*/
    }

    这样做有点烦琐,下面的等效方法更简单:
    void display_put(uint32_t b)
    {
        IOPDATA = (IOPDATA & ~display) | b;
    }

    结论:从该例子看出,它并不鼓励使用volatile,即使要用也要很小心,因为volatile可能在无意中降低了代码效率,而你却无法察觉。但是,我们说,不鼓励并不是说就不能或不要用,而是要懂得何时用,怎么用好它。其所谓智用了

  • 相关阅读:
    Vue3.0官方文档
    简单实现Vue的双向绑定原理
    小程序使用weapp-qrcode二维码插件,宽高自适应解决方法
    小程序判断ios还是android
    手写实现bind
    手写实现call,apply函数
    React onClick点击事件传参三种写法
    zynq 中断
    zynq_ps端点亮led灯代码
    突然发现自己的很多博客无法显示图片,人都傻了,于是就整理了一早上,全部换成了markdown格式,就好了,希望博客的时间不会对大家造成困扰!!!
  • 原文地址:https://www.cnblogs.com/liang123/p/6325802.html
Copyright © 2011-2022 走看看