C语言的本质(四):volatile限定符

2023-10-20 09:50

本文主要是介绍C语言的本质(四):volatile限定符,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

前言

本节探讨一下编译器优化会对生成的指令产生什么影响,在此基础上介绍C语言的volatile限定符。首先看下面的例子。

volatile限定符

      /* artificial device registers */unsigned char recv;unsigned char send;/* memory buffer */unsigned char buf[3];int main(void){buf[0] = recv;buf[1] = recv;buf[2] = recv;send = ~buf[0];send = ~buf[1];send = ~buf[2];return 0;}

我们用recv和send这两个全局变量来模拟设备寄存器。

假设某种平台采用内存映射I/O,串口发送寄存器和串口接收寄存器位于固定的内存地址,而recv和send这两个全局变量也有固定的内存地址,所以在这个例子中把它们假想成串口接收寄存器和串口发送寄存器。

在main函数中,首先从串口接收三个字节存到buf数组,然后把这三个字节取反,依次从串口发送出去。

我们查看这段代码的反汇编结果:

            buf[0] = recv;80483b7:      0f b6 05 19 a0 04 08     movzbl 0x804a019,%eax80483be:      a2 1a a0 04 08           mov   %al,0x804a01abuf[1] = recv;80483c3:      0f b6 05 19 a0 04 08     movzbl 0x804a019,%eax80483ca:      a2 1b a0 04 08           mov   %al,0x804a01bbuf[2] = recv;80483cf:      0f b6 05 19 a0 04 08     movzbl 0x804a019,%eax80483d6:      a2 1c a0 04 08           mov   %al,0x804a01csend = ~buf[0];80483db:      0f b6 05 1a a0 04 08     movzbl 0x804a01a,%eax80483e2:      f7 d0                 not   %eax80483e4:      a2 18 a0 04 08           mov   %al,0x804a018send = ~buf[1];80483e9:      0f b6 05 1b a0 04 08     movzbl 0x804a01b,%eax80483f0:      f7 d0                 not   %eax80483f2:      a2 18 a0 04 08            mov   %al,0x804a018send = ~buf[2];80483f7:      0f b6 05 1c a0 04 08     movzbl 0x804a01c,%eax80483fe:      f7 d0                 not   %eax8048400:      a2 18 a0 04 08           mov   %al,0x804a018

movz指令把字长较短的值存到字长较长的存储单元中,存储单元的高位用0填充。

该指令可以有b(byte)、w(word)、l(long)三种后缀,分别表示单字节、两字节和四字节

比如movzbl 0x804a019,%eax表示把地址0x804a019处的一个字节存到eax寄存器中,而eax寄存器的长度是4个字节,高3个字节用0填充,如果高3个字节采用符号扩展则应该用movsbl指令,z表示zero而s表示sign。

下一条指令mov %al,0x804a01a中的al寄存器正是eax寄存器的低字节,这条指令把eax寄存器的低字节存到地址0x804a01a处的一个字节中。

可以用不同的名字单独访问x86寄存器的低8位、次低8位、低16位或者完整的32位,以eax为例,al表示低8位,ah表示次低8位,ax表示低16位,如图18.7所示。

在这里插入图片描述

如果指定优化选项-O编译,反汇编的结果就不一样了:

      $ gcc main.c -g -O$ objdump -dS a.out|less...buf[0] = recv;80483b7:      0f b6 05 19 a0 04 08   movzbl 0x804a019,%eax80483be:      a2 1a a0 04 08         mov   %al,0x804a01abuf[1] = recv;80483c3:      a2 1b a0 04 08         mov   %al,0x804a01bbuf[2] = recv;80483c8:      a2 1c a0 04 08         mov   %al,0x804a01csend = ~buf[0];send = ~buf[1];send = ~buf[2];80483cd:      f7 d0                  not   %eax80483cf:      a2 18 a0 04 08         mov   %al,0x804a018...

前三条语句从串口接收三个字节,而编译生成的指令显然不符合我们的意图:只有第一条语句从内存地址0x804a019读一个字节到寄存器eax中,然后从寄存器al保存到buf[0],后两条语句就不再从内存地址0x804a019读取,而是直接把寄存器al的值保存到buf[1]和buf[2]。

后三条语句把buf中的三个字节取反再发送到串口,编译生成的指令也不符合我们的意图:只有最后一条语句把eax取反然后写到内存地址0x804a018了,前两条语句形同虚设,根本不生成指令。

为什么编译器优化的结果会错呢?因为编译器并不知道0x804a018和0x804a019是设备寄存器的地址,把它们当成普通的内存单元了。

如果是普通的内存单元,只要程序不去改写它,它就不会变,可以先把内存单元里的值读到寄存器缓存起来,以后每次用到这个值就直接从寄存器读取,这样效率更高,我们知道读寄存器远比读内存要快。

另一方面,如果对一个普通的内存单元连续做三次写操作,只有最后一次的值会保存到内存单元中,所以前两次写操作是多余的,可以优化掉。

然而访问设备寄存器的代码这样优化就错了,因为设备寄存器通常具有以下特性:

  • ● 设备寄存器中的数据不需要改写就可以自己发生变化,每次读上来的值可能不一样。
  • ● 连续多次向设备寄存器中写数据并不是在做无用功,而是给设备发命令,是有意义的。

用优化选项编译生成的指令明显效率更高,但使用不当会出错,为了避免编译器自作聪明,把不该优化的也优化了,程序员应该明确告诉编译器哪些内存单元的访问是不能优化的,在C语言中可以用volatile限定符修饰变量,就是告诉编译器,即使在编译时指定了优化选项,每次读这个变量仍然要老老实实从内存读取,每次写这个变量也仍然要老老实实写回内存,不能省略任何步骤。我们把代码的开头几行改成:

      /* artificial device registers */volatile unsigned char recv;volatile unsigned char send;

然后指定优化选项-O编译,查看反汇编的结果:

            buf[0] = recv;80483b7:      0f b6 0d 19 a0 04 08    movzbl 0x804a019,%ecx80483be:      88 0d 1a a0 04 08        mov   %cl,0x804a01abuf[1] = recv;80483c4:      0f b6 15 19 a0 04 08    movzbl 0x804a019,%edx80483cb:      88 15 1b a0 04 08        mov   %dl,0x804a01bbuf[2] = recv;80483d1:      0f b6 05 19 a0 04 08    movzbl 0x804a019,%eax80483d8:      a2 1c a0 04 08           mov   %al,0x804a01csend = ~buf[0];80483dd:      f7 d1                 not   %ecx80483df:      88 0d 18 a0 04 08        mov   %cl,0x804a018send = ~buf[1];80483e5:      f7 d2                 not   %edx80483e7:      88 15 18 a0 04 08        mov   %dl,0x804a018send = ~buf[2];80483ed:      f7 d0                 not   %eax80483ef:      a2 18 a0 04 08           mov   %al,0x804a018

确实每次读recv都从内存地址0x804a019读取,每次写send也都写到内存地址0x804a018了。值得注意的是,每次写send并不需要取出buf中的值,而是取出先前缓存在寄存器eax、edx、ecx中的值,做取反运算然后写下去,这是因为buf并没有用volatile限定,读者可以试着在buf的定义前面也加上volatile,再优化编译,再查看和比较反汇编的结果。

告诉编译器不不可信寄存器,给我去内存空间取值。

gcc的编译优化选项有-O0、-O、-O1、-O2、-O3、-Os几种。

  • -O0表示不优化,这是缺省的选项。
  • -O1、-O2和-O3这几个选项一个比一个优化得更多,编译时间也更长。
  • -O和-O1相同。
  • -Os表示为缩小目标文件的尺寸而优化。具体每种选项做了哪些优化请参考gcc参考文档。

从上面的例子还可以看到,如果在编译时指定了优化选项,源代码和生成指令的次序可能无法对应,甚至有些源代码可能不对应任何指令,被彻底优化掉了。

这一点在用gdb做源码级调试时尤其需要注意(做指令级调试没关系),在为调试而编译时不要指定优化选项,否则可能无法一步步跟踪源代码的执行过程。

有了volatile限定符可以防止编译器优化对设备寄存器的访问,但对于有Cache的平台仅仅这样还不够,还是无法防止Cache优化对设备寄存器的访问。

在访问内存地址时Cache对程序员是透明的,比如执行movzbl 0x804a019,%eax这样一条指令,我们并不知道eax的值是真的从内存地址0x804a019读到的,还是从Cache中读到的,如果Cache已经缓存了这个地址的数据就从Cache读,如果Cache没有缓存就从内存读,这些步骤都是硬件自动做的,而不是用指令控制Cache去做的,程序员写的指令中只有寄存器、内存地址,而没有Cache,程序员甚至不需要知道Cache的存在。

同样道理,如果执行了mov %al,0x804a01a这样一条指令,我们并不知道寄存器的值是真的写回内存了,还是只写到了Cache中,以后再由Cache写回内存,即使只写到了Cache中而暂时没有写回内存,下次读0x804a01a这个地址时仍然可以从Cache中读到上次写的数据。然而,在读写设备寄存器时Cache的存在就不容忽视了,如果串口发送和接收寄存器的内存地址被Cache缓存了会有什么问题呢?

在这里插入图片描述

如果串口发送寄存器的地址被Cahce缓存,CPU执行单元对串口发送寄存器做写操作都写到Cache中去了,串口发送寄存器并没有及时得到数据,也就不能及时发送,CPU执行单元先后发出的1、2、3三个字节都会写到Cache中的同一个单元,最后Cache中只保存了第3个字节,如果这时Cache把数据写回到串口发送寄存器,只能把第3个字节发出去,前两个字节就丢失了。

与此类似,如果串口接收寄存器的地址被Cache缓存,CPU执行单元在读第1个字节时,Cache会从串口接收寄存器读上来并缓存,然而串口接收寄存器后面收到的2、3两个字节Cache并不知道,因为Cache把串口接收寄存器当做普通内存单元,并且相信内存单元中的数据是不会自己变的,以后每次读串口接收寄存器时,Cache都会把缓存的第1个字节提供给CPU执行单元。

通常,有Cache的平台都有办法对某一段地址范围禁用Cache,一般是在页表中设置的,可以设定哪些页面允许Cache缓存,哪些页面不允许Cache缓存,MMU不仅要做地址转换和访问权限检查,也要配合Cache工作。

除了设备寄存器需要用volatile限定之外,当一个全局变量被同一进程中的多个控制流程访问时也要用volatile限定,比如信号处理函数和多线程就属于这种情况。主要的目的就是避免多个访问,出现无效和脏数据。

参考资料

《一站式学习C编程》

这篇关于C语言的本质(四):volatile限定符的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/246326

相关文章

C语言自定义类型之联合和枚举解读

《C语言自定义类型之联合和枚举解读》联合体共享内存,大小由最大成员决定,遵循对齐规则;枚举类型列举可能值,提升可读性和类型安全性,两者在C语言中用于优化内存和程序效率... 目录一、联合体1.1 联合体类型的声明1.2 联合体的特点1.2.1 特点11.2.2 特点21.2.3 特点31.3 联合体的大小1

Go语言使用select监听多个channel的示例详解

《Go语言使用select监听多个channel的示例详解》本文将聚焦Go并发中的一个强力工具,select,这篇文章将通过实际案例学习如何优雅地监听多个Channel,实现多任务处理、超时控制和非阻... 目录一、前言:为什么要使用select二、实战目标三、案例代码:监听两个任务结果和超时四、运行示例五

C语言中%zu的用法解读

《C语言中%zu的用法解读》size_t是无符号整数类型,用于表示对象大小或内存操作结果,%zu是C99标准中专为size_t设计的printf占位符,避免因类型不匹配导致错误,使用%u或%d可能引发... 目录size_t 类型与 %zu 占位符%zu 的用途替代占位符的风险兼容性说明其他相关占位符验证示

C语言进阶(预处理命令详解)

《C语言进阶(预处理命令详解)》文章讲解了宏定义规范、头文件包含方式及条件编译应用,强调带参宏需加括号避免计算错误,头文件应声明函数原型以便主函数调用,条件编译通过宏定义控制代码编译,适用于测试与模块... 目录1.宏定义1.1不带参宏1.2带参宏2.头文件的包含2.1头文件中的内容2.2工程结构3.条件编

Go语言并发之通知退出机制的实现

《Go语言并发之通知退出机制的实现》本文主要介绍了Go语言并发之通知退出机制的实现,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面随着小编来一起学习学习吧... 目录1、通知退出机制1.1 进程/main函数退出1.2 通过channel退出1.3 通过cont

Go语言编译环境设置教程

《Go语言编译环境设置教程》Go语言支持高并发(goroutine)、自动垃圾回收,编译为跨平台二进制文件,云原生兼容且社区活跃,开发便捷,内置测试与vet工具辅助检测错误,依赖模块化管理,提升开发效... 目录Go语言优势下载 Go  配置编译环境配置 GOPROXYIDE 设置(VS Code)一些基本

深入理解Go语言中二维切片的使用

《深入理解Go语言中二维切片的使用》本文深入讲解了Go语言中二维切片的概念与应用,用于表示矩阵、表格等二维数据结构,文中通过示例代码介绍的非常详细,需要的朋友们下面随着小编来一起学习学习吧... 目录引言二维切片的基本概念定义创建二维切片二维切片的操作访问元素修改元素遍历二维切片二维切片的动态调整追加行动态

Go语言中make和new的区别及说明

《Go语言中make和new的区别及说明》:本文主要介绍Go语言中make和new的区别及说明,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录1 概述2 new 函数2.1 功能2.2 语法2.3 初始化案例3 make 函数3.1 功能3.2 语法3.3 初始化

Java 线程安全与 volatile与单例模式问题及解决方案

《Java线程安全与volatile与单例模式问题及解决方案》文章主要讲解线程安全问题的五个成因(调度随机、变量修改、非原子操作、内存可见性、指令重排序)及解决方案,强调使用volatile关键字... 目录什么是线程安全线程安全问题的产生与解决方案线程的调度是随机的多个线程对同一个变量进行修改线程的修改操

Go语言中nil判断的注意事项(最新推荐)

《Go语言中nil判断的注意事项(最新推荐)》本文给大家介绍Go语言中nil判断的注意事项,本文给大家介绍的非常详细,对大家的学习或工作具有一定的参考借鉴价值,需要的朋友参考下吧... 目录1.接口变量的特殊行为2.nil的合法类型3.nil值的实用行为4.自定义类型与nil5.反射判断nil6.函数返回的