LINUX设备驱动程序如何与硬件通信

LINUX设备驱动程序是怎么样和硬件通信的?下面将由我带大家来解答这个疑问吧，希望对大家有所收获!

　 　LINUX设备驱动程序与硬件设备之间的通信

设备驱动程序是软件概念和硬件电路之间的一个抽象层，因此两方面都要讨论。到目前为止，我们已经讨论详细讨论了软件概念上的一些细节，现在讨论另一方面，介绍驱动程序在Linux上如何在保持可移植性的前提下访问I/O端口和I/O内存。

我们在需要示例的场合会使用简单的数字I/O端口来讲解I/O指令，并使用普通的帧缓冲区显存来讲解内存映射I/O。

I/O端口和I/O内存

计算机对每种外设都是通过读写它的寄存器进行控制的。大部分外设都有几个寄存器，不管是在内存地址空间还是在I/O地址空间，这些寄存器的访问地址都是连续的。

I/O端口就是I/O端口，设备会把寄存器映射到I/O端口，不管处理器是否具有独立的I/O端口地址空间。即使没有在访问外设时也要模拟成读写I/O端口。

I/O内存是设备把寄存器映射到某个内存地址区段(如PCI设备)。这种I/O内存通常是首先方案，它不需要特殊的处理器指令，而且CPU核心访问内存更有效率。

I/O寄存器和常规内存

尽管硬件寄存器和内存非常相似，但程序员在访问I/O寄存器的时候必须注意避免由于CPU或编译器不恰当的优化而改变预期的I/O动作。

I/O寄存器和RAM最主要的区别就是I/O *** 作具有边际效应，而内存 *** 作则没有：由于内存没有边际效应，所以可以用多种 方法 进行优化，如使用高速缓存保存数值、重新排序读/写指令等。

编译器能够将数值缓存在CPU寄存器中而不写入内存，即使储存数据，读写 *** 作也都能在高速缓存中进行而不用访问物理RAM。无论是在编译器一级或是硬件一级，指令的重新排序都有可能发生：一个指令序列如果以不同于程序文本中的次序运行常常能执行得更快。

在对常规内存进行这些优化的时候，优化过程是透明的，而且效果良好，但是对I/O *** 作来说这些优化很可能造成致命的错误，这是因为受到边际效应的干扰，而这却是驱动程序访问I/O寄存器的主要目的。处理器无法预料某些 其它 进程(在另一个处理器上运行，或在在某个I/O控制器中发生的 *** 作)是否会依赖于内存访问的顺序。编译器或CPU可能会自作聪明地重新排序所要求的 *** 作，结果会发生奇怪的错误，并且很难调度。因此，驱动程序必须确保不使用高速缓冲，并且在访问寄存器时不发生读或写指令的重新排序。

由硬件自身引起的问题很解决：只要把底层硬件配置成(可以是自动的或是由Linux初始化代码完成)在访问I/O区域(不管是内存还是端口)时禁止硬件缓存即可。

由编译器优化和硬件重新排序引起的问题的解决办法是：对硬件(或其他处理器)必须以特定顺序的 *** 作之间设置内存屏障(memory barrier)。Linux提供了4个宏来解决所有可能的排序问题：

#include <linux/kernel.h>

void barrier(void)

这个函数通知编译器插入一个内存屏障，但对硬件没有影响。编译后的代码会把当前CPU寄存器中的所有修改过的数值保存到内存中，需要这些数据的时候再重新读出来。对barrier的调用可避免在屏障前后的编译器优化，但硬件完成自己的重新排序。

#include <asm/system.h>

void rmb(void)

void read_barrier_depends(void)

void wmb(void)

void mb(void)

这些函数在已编译的指令流中插入硬件内存屏障具体实现方法是平台相关的。rmb(读内存屏障)保证了屏障之前的读 *** 作一定会在后来的读 *** 作之前完成。wmb保证写 *** 作不会乱序，mb指令保证了两者都不会。这些函数都是barrier的超集。

void smp_rmb(void)

void smp_read_barrier_depends(void)

void smp_wmb(void)

void smp_mb(void)

上述屏障宏版本也插入硬件屏障，但仅仅在内核针对SMP系统编译时有效在单处理器系统上，它们均会被扩展为上面那些简单的屏障调用。

设备驱动程序中使用内存屏障的典型形式如下：

writel(dev->registers.addr, io_destination_address)

writel(dev->registers.size, io_size)

writel(dev->registers.operation, DEV_READ)

wmb()

writel(dev->registers.control, DEV_GO)

在这个例子中，最重要的是要确保控制某种特定 *** 作的所有设备寄存器一定要在 *** 作开始之前已被正确设置。其中的内存屏障会强制写 *** 作以要求的顺序完成。

因为内存屏障会影响系统性能，所以应该只用于真正需要的地方。不同类型的内存屏障对性能的影响也不尽相同，所以最好尽可能使用最符合需要的特定类型。

值得注意的是，大多数处理同步的内核原语，如自旋锁和atomic_t *** 作，也能作为内存屏障使用。同时还需要注意，某些外设总线(比如PCI总线)存在自身的高速缓存问题，我们将在后面的章节中讨论相关问题。

在某些体系架构上，允许把赋值语句和内存屏障进行合并以提高效率。内核提供了几个执行这种合并的宏，在默认情况下，这些宏的定义如下：

#define set_mb(var, value) do {var = valuemb()} while 0

#define set_wmb(var, value) do {var = valuewmb()} while 0

#define set_rmb(var, value) do {var = valuermb()} while 0

在适当的地方，<asm/system.h>中定义的这些宏可以利用体系架构特有的指令更快的完成任务。注意只有小部分体系架构定义了set_rmb宏。

使用I/O端口

I/O端口是驱动程序与许多设备之间的通信方式——至少在部分时间是这样。本节讲解了使用I/O端口的不同函数，另外也涉及到一些可移植性问题。

I/O端口分配

下面我们提供了一个注册的接口，它允允许驱动程序声明自己需要 *** 作的端口：

#include <linux/ioport.h>

struct resource *request_region(unsigned long first, unsigned long n, const char *name)

它告诉内核，我们要使用起始于first的n个端口。name是设备的名称。如果分配成功返回非NULL，如果失败返回NULL。

所有分配的端口可从/proc/ioports中找到。如果我们无法分配到我们要的端口集合，则可以查看这个文件哪个驱动程序已经分配了这些端口。

如果不再使用这些端口，则用下面函数返回这些端口给系统：

void release_region(unsigned long start, unsigned long n)

下面函数允许驱动程序检查给定的I/O端口是否可用：

int check_region(unsigned long first, unsigned long n)//不可用返回负的错误代码

我们不赞成用这个函数，因为它返回成功并不能确保分配能够成功，因为检查和其后的分配并不是原子 *** 作。我们应该始终使用request_region，因为这个函数执行了必要的锁定，以确保分配过程以安全原子的方式完成。

*** 作I/O端口

当驱动程序请求了需要使用的I/O端口范围后，必须读取和/或写入这些端口。为此，大多数硬件都会把8位、16位、32位区分开来。它们不能像访问系统内存那样混淆使用。

因此，C语言程序必须调用不同的函数访问大小不同的端口。那些只支持映射的I/O寄存器的计算机体系架构通过把I/O端口地址重新映射到内存地址来伪装端口I/O，并且为了易于移植，内核对驱动程序隐藏了这些细节。Linux内核头文件中(在与体系架构相关的头文件<asm/io.h>中)定义了如下一些访问I/O端口的内联函数：

unsigned inb(unsigned port)

void outb(unsigned char byte, unsigned port)

字节读写端口。

unsigned inw(unsigned port)

void outw(unsigned short word, unsigned port)

访问16位端口

unsigned inl(unsigned port)

void outl(unsigned longword, unsigned port)

访问32位端口

在用户空间访问I/O端口

上面这些函数主要是提供给设备驱动程序使用的，但它们也可以用户空间使用，至少在PC类计算机上可以使用。GNU的C库在<sys/io.h>中定义了这些函数。如果要要用户空间使用inb及相关函数，则必须满足正下面这些条件：

编译程序时必须带有-O选项来强制内联函数的展开。

必须用ioperm(获取单个端口的权限)或iopl(获取整个I/O空间)系统调用来获取对端口进行I/O *** 作的权限。这两个函数都是x86平台特有的。

必须以root身份运行该程序才能调用ioperm或iopl。或者进程的祖先进程之一已经以root身份获取对端口的访问。

如果宿主平台没有以上两个系统调用，则用户空间程序仍然可以使用/dev/port设备文件访问I/O端口。不过要注意，该设备文件的含义与平台密切相关，并且除PC平台以处，它几乎没有什么用处。

串 *** 作

以上的I/O *** 作都是一次传输一个数据，作为补充，有些处理器实现了一次传输一个数据序列的特殊指令，序列中的数据单位可以是字节、字、双字。这些指令称为串 *** 作指令，它们执行这些任务时比一个C语言编写的循环语句快得多。下面列出的宏实现了串I/O：

void insb(unsigned port, void *addr, unsigned long count)

void outsb(unsigned port, void *addr, unsigned long count)从内存addr开始连续读/写count数目的字节。只对单一端口port读取或写入数据

void insw(unsigned port, void *addr, unsigned long count)

void outsw(unsigned port, void *addr, unsigned long count)对一个16位端口读写16位数据

void insl(unsigned port, void *addr, unsigned long count)

void outsl(unsigned port, void *addr, unsigned long count)对一个32位端口读写32位数据

在使用串I/O *** 作函数时，需要铭记的是：它们直接将字节流从端口中读取或写入。因此，当端口和主机系统具有不同的字节序时，将导致不可预期的结果。使用inw读取端口将在必要时交换字节，以便确保读入的值匹配于主机的字节序。然而，串函数不会完成这种交换。

暂停式I/O

在处理器试图从总线上快速传输数据时，某些平台(特别是i386)就会出现问题。当处理器时钟比外设时钟(如ISA)快时就会出现问题，并且在设备板上特别慢时表现出来。为了防止出现丢失数据的情况，可以使用暂停式的I/O函数来取代通常的I/O函数，这些暂停式的I/O函数很像前面介绍的那些I/O函数，不同之处是它们的名字用_p结尾，如inb_p、outb_p等等。在linux支持的大多数平台上都定义了这些函数，不过它们常常扩展为非暂停式I/O同样的代码，因为如果不使用过时的外设总线就不需要额外的暂停。

平台相关性

I/O指令是与处理器密切相关的。因为它们的工作涉及到处理器移入移出数据的细节，所以隐藏平台间的差异非常困难。因此，大部分与I/O端口相关的源代码都与平台相关。

回顾前面函数列表可以看到有一处不兼容的地方，即数据类型。函数的参数根据各平台体系架构上的不同要相应地使用不同的数据类型。例如，port参数在x86平台上(处理器只支持64KB的I/O空间)上定义为unsigned short，但在其他平台上定义为unsigned long，在这些平台上，端口是与内存在同一地址空间内的一些特定区域。

感兴趣的读者可以从io.h文件获得更多信息，除了本章介绍的函数，一些与体系架构相关的函数有时也由该文件定义。

值得注意的是，x86家族之外的处理器都不为端口提供独立的地址空间。

I/O *** 作在各个平台上执行的细节在对应平台的编程手册中有详细的叙述也可以从web上下载这些手册的PDF文件。

I/O端口示例

演示设备驱动程序的端口I/O的示例代码运行于通用的数字I/O端口上，这种端口在大多数计算机平台上都能找到。

数字I/O端口最常见的一种形式是一个字节宽度的I/O区域，它或者映射到内存，或者映射到端口。当把数字写入到输出区域时，输出引脚上的电平信号随着写入的各位而发生相应变化。从输入区域读取到的数据则是输入引脚各位当前的逻辑电平值。

这类I/O端口的具体实现和软件接口是因系统而异的。大多数情况下，I/O引脚由两个I/O区域控制的：一个区域中可以选择用于输入和输出的引脚，另一个区域中可以读写实际的逻辑电平。不过有时情况简单些，每个位不是输入就是输出(不过这种情况下就不能称为“通用I/O"了)在所有个人计算机上都能找到的并口就是这样的非通用的I/O端口。

并口简介

并口的最小配置由3个8位端口组成。第一个端口是一个双向的数据寄存器，它直接连接到物理连接器的2~9号引脚上。第二个端口是一个只读的状态寄存器当并口连接打印机时，该寄存器 报告 打印机状态，如是否是线、缺纸、正忙等等。第三个端口是一个只用于输出的控制寄存器，它的作用之一是控制是否启用中断。

如下所示：并口的引脚

示例驱动程序

while(count--) {

outb(*(ptr++), port)

wmb()

}

使用I/O内存

除了x86上普遍使的I/O端口之外，和设备通信的另一种主要机制是通过使用映射到内存的寄存器或设备内存，这两种都称为I/O内存，因为寄存器和内存的差别对软件是透明的。

I/O内存仅仅是类似RAM的一个区域，在那里处理器可以通过总线访问设备。这种内存有很多用途，比如存放视频数据或以太网数据包，也可以用来实现类似I/O端口的设备寄存器(也就是说，对它们的读写也存在边际效应)。

根据计算机平台和所使用总线的不同，i/o内存可能是，也可能不是通过页表访问的。如果访问是经由页表进行的，内核必须首先安排物理地址使其对设备驱动程序可见(这通常意味着在进行任何I/O之前必须先调用ioremap)。如果访问无需页表，那么I/O内存区域就非常类似于I/O端口，可以使用适当形式的函数读取它们。

不管访问I/O内存是否需要调用ioremap，都不鼓励直接使用指向I/O内存的指针。相反使用包装函数访问I/O内存，这一方面在所有平台上都是安全的，另一方面，在可以直接对指针指向的内存区域执行 *** 作的时候，这些函数是经过优化的。并且直接使用指针会影响程序的可移植性。

I/O内存分配和映射

在使用之前，必须首先分配I/O区域。分配内存区域的接口如下(在<linux/ioport.h>中定义)：

struct resource *request_mem_region(unsigned long start, unsigned long len, char *name)

该函数从start开始分配len字节长的内存区域。如果成功返回非NULL，否则返回NULL值。所有的I/O内存分配情况可从/proc/iomem得到。

不再使用已分配的内存区域时，使用如下接口释放：

void release_mem_region(unsigned long start, unsigned long len)

下面函数用来检查给定的I/O内存区域是否可用的老函数：

int check_mem_region(unsigned long start, unsigned long len)//这个函数和check_region一样不安全，应避免使用

分配内存之后我们还必须确保该I/O内存对内存而言是可访问的。获取I/O内存并不意味着可引用对应的指针在许多系统上，I/O内存根本不能通过这种方式直接访问。因此，我们必须由ioremap函数建立映射，ioremap专用于为I/O内存区域分配虚拟地址。

我们根据以下定义来调用ioremap函数：

#include <asm/io.h>

void *ioremap(unsigned long phys_addr, unsigned long size)

void *ioremap_nocache(unsigned long phys_addr, unsigned long size)在大多数计算机平台上，该函数和ioremap相同：当所有I/O内存已属于非缓存地址时，就没有必要实现ioremap的独立的，非缓冲版本。

void iounmap(void *addr)

记住，由ioremap返回的地址不应该直接引用，而应该使用内核提供的accessor函数。

访问I/O内存

在某些平台上我们可以将ioremap的返回值直接当作指针使用。但是，这种使用不具有可移植性，访问I/O内存的正确方法是通过一组专用于些目的的函数(在<asm/io.h>中定义)。

从I/O内存中读取，可使用以下函数之一：

unsigned int ioread8(void *addr)

unsigned int ioread16(void *addr)

unsigned int ioread32(void *addr)

其中，addr是从ioremap获得的地址(可能包含一个整数偏移量)返回值是从给定I/O内存读取到的值。

写入I/O内存的函数如下：

void iowrite8(u8 value, void *addr)

void iowrite16(u16 value, void *addr)

void iowrite32(u32 value, void *addr)

如果必须在给定的I/O内存地址处读/写一系列值，则可使用上述函数的重复版本：

void ioread8_rep(void *addr, void *buf, unsigned long count)

void ioread16_rep(void *addr, void *buf, unsigned long count)

void ioread32_rep(void *addr, void *buf, unsigned long count)

void iowrite8_rep(void *addr, const void *buf, unsigned long count)

void iowrite16_rep(void *addr, const void *buf, unsigned long count)

void iowrite32_rep(void *addr, const void *buf, unsigned long count)

上述函数从给定的buf向给定的addr读取或写入count个值。count以被写入数据的大小为单位。

上面函数均在给定的addr处执行所有的I/O *** 作，如果我们要在一块I/O内存上执行 *** 作，则可以使用下面的函数：

void memset_io(void *addr, u8 value, unsigned int count)

void memcpy_fromio(void *dest, void *source, unsigned int count)

void memcpy_toio(void *dest, void *source, unsigned int count)

上述函数和C函数库的对应函数功能一致。

像I/O内存一样使用I/O端口

某些硬件具有一种有趣的特性：某些版本使用I/O端口，而其他版本则使用I/O内存。导出给处理器的寄存器在两种情况下都是一样的，但访问方法却不同。为了让处理这类硬件的驱动程序更加易于编写，也为了最小化I/O端口和I/O内存访问这间的表面区别，2.6内核引入了ioport_map函数：

void *ioport_map(unsigned long port, unsigned int count)

该函数重新映射count个I/O端口，使其看起来像I/O内存。此后，驱动程序可在该函数返回的地址上使用ioread8及其相关函数，这样就不必理会I/O端口和I/O内存之间的区别了。

当不需要这种映射时使用下面函数一撤消：

void ioport_unmap(void *addr)

这些函数使得I/O端口看起来像内存。但需要注意的是，在重新映射之前，我们必须通过request_region来分配这些I/O端口。

为I/O内存重用short

前面介绍的short示例模块访问的是I/O端口，它也可以访问I/O内存。为此必须在加载时通知它使用I/O内存，另外还要修改base地址以使其指向I/O区域。

下例是在MIPS开发板上点亮调试用的LED：

mips.root# ./short_load use_mem=1 base = 0xb7ffffc0

mips.root# echo -n 7 >/dev/short0

下面代码是short写入内存区域时使用的循环：

while(count--) {

iowrite8(*ptr++, address)

wmb()

}

1MB地址空间之下的ISA内存

最广为人知的I/O内存区之一就是个人计算机上的ISA内存段。它的内存范围在64KB(0xA0000)到1MB(0x100000)之间，因此它正好出现在常规系统RAM的中间。这种地址看上去有点奇怪，因为这个设计决策是20世纪80年代早期作出的，在当时看来没有人会用到640KB以上的内存。

自旋锁（Spin Lock）是一种典型的对临界资源进行互斥访问的手段，其名称来源于它的工作方式。为了获得一个自旋锁，在某CPU上运行的代码需先执行一个原子 *** 作，该 *** 作测试并设置（Test-AndSet）某个内存变量。由于它是原子 *** 作，所以在该 *** 作完成之前其他执行单元不可能访问这个内存变量。如果测试结果表明锁已经空闲，则程序获得这个自旋锁并继续执行；如果测试结果表明锁仍被占用，程序将在一个小的循环内重复这个“测试并设置” *** 作，即进行所谓的“自旋”，通俗地说就是“在原地打转”。当自旋锁的持有者通过重置该变量释放这个自旋锁后，某个等待的“测试并设置” *** 作向其调用者报告锁已释放。理解自旋锁最简单的方法是把它作为一个变量看待，该变量把一个临界区标记为“我当前在运行，请稍等一会”或者标记为“我当前不在运行，可以被使用。如果A执行单元首先进入例程，它将持有自旋锁；当B执行单元试图进入同一个例程时，将获知自旋锁已被持有，需等到A执行单元释放后才能进入。在ARM体系结构下，自旋锁的实现借用了ldrex指令、strex指令、ARM处理器内存屏障指令dmb和dsb、wfe指令和sev指令，这类似于代码清单7.1的逻辑。可以说既要保证排他性，也要处理好内存屏障。

自旋锁主要针对SMP或单CPU但内核可抢占的情况，对于单CPU和内核不支持抢占的系统，自旋锁退化为空 *** 作。在单CPU和内核可抢占的系统中，自旋锁持有期间中内核的抢占将被禁止。由于内核可抢占的单CPU系统的行为实际上很类似于SMP系统，因此，在这样的单CPU系统中使用自旋锁仍十分必要。另外，在多核SMP的情况下，任何一个核拿到了自旋锁，该核上的抢占调度也暂时禁止了，但是没有禁止另外一个核的抢占调度。尽管用了自旋锁可以保证临界区不受别的CPU和本CPU内的抢占进程打扰，但是得到锁的代码路径在执行临界区的时候，还可能受到中断和底半部的影响。为了防止这种影响，就需要用到自旋锁的衍生。

volatile提醒编译器它后面所定义的变量随时都有可能改变，因此编译后的程序每次需要存储或读取这个变量的时候，都会直接从变量地址中读取数据。如果没有volatile关键字，则编译器可能优化读取和存储，可能暂时使用寄存器中的值，如果这个变量由别的程序更新了的话，将出现不一致的现象。下面举例说明。在DSP开发中，经常需要等待某个事件的触发，所以经常会写出这样的程序：

short flag

void test()

{

do1()

while(flag==0)

do2()

}

这段程序等待内存变量flag的值变为1(怀疑此处是0,有点疑问,)之后才运行do2()。变量flag的值由别的程序更改，这个程序可能是某个硬件中断服务程序。例如：如果某个按钮按下的话，就会对DSP产生中断，在按键中断程序中修改flag为1，这样上面的程序就能够得以继续运行。但是，编译器并不知道flag的值会被别的程序修改，因此在它进行优化的时候，可能会把flag的值先读入某个寄存器，然后等待那个寄存器变为1。如果不幸进行了这样的优化，那么while循环就变成了死循环，因为寄存器的内容不可能被中断服务程序修改。为了让程序每次都读取真正flag变量的值，就需要定义为如下形式：

volatile short flag

需要注意的是，没有volatile也可能能正常运行，但是可能修改了编译器的优化级别之后就又不能正常运行了。因此经常会出现debug版本正常，但是release版本却不能正常的问题。所以为了安全起见，只要是等待别的程序修改某个变量的话，就加上volatile关键字。

volatile的本意是“易变的”

由于访问寄存器的速度要快过RAM，所以编译器一般都会作减少存取外部RAM的优化。比如：

static int i=0

int main(void)

{

...

while (1)

{

if (i) do_something()

}

}

/* Interrupt service routine. */

void ISR_2(void)

{

i=1

}

程序的本意是希望ISR_2中断产生时，在main当中调用do_something函数，但是，由于编译器判断在main函数里面没有修改过i，因此可能只执行一次对从i到某寄存器的读 *** 作，然后每次if判断都只使用这个寄存器里面的“i副本”，导致do_something永远也不会被调用。如果变量加上volatile修饰，则编译器保证对此变量的读写 *** 作都不会被优化（肯定执行）。此例中i也应该如此说明。

一般说来，volatile用在如下的几个地方：

1、中断服务程序中修改的供其它程序检测的变量需要加volatile；

2、多任务环境下各任务间共享的标志应该加volatile；

3、存储器映射的硬件寄存器通常也要加volatile说明，因为每次对它的读写都可能由不同意义；

另外，以上这几种情况经常还要同时考虑数据的完整性（相互关联的几个标志读了一半被打断了重写），在1中可以通过关中断来实现，2中可以禁止任务调度，3中则只能依靠硬件的良好设计了。

二、volatile 的含义

volatile总是与优化有关，编译器有一种技术叫做数据流分析，分析程序中的变量在哪里赋值、在哪里使用、在哪里失效，分析结果可以用于常量合并，常量传播等优化，进一步可以死代码消除。但有时这些优化不是程序所需要的，这时可以用volatile关键字禁止做这些优化，volatile的字面含义是易变的，它有下面的作用：

1 不会在两个 *** 作之间把volatile变量缓存在寄存器中。在多任务、中断、甚至setjmp环境下，变量可能被其他的程序改变，编译器自己无法知道，volatile就是告诉编译器这种情况。

2 不做常量合并、常量传播等优化，所以像下面的代码：

volatile int i = 1

if (i >0) ...

if的条件不会当作无条件真。

3 对volatile变量的读写不会被优化掉。如果你对一个变量赋值但后面没用到，编译器常常可以省略那个赋值 *** 作，然而对Memory Mapped IO的处理是不能这样优化的。

前面有人说volatile可以保证对内存 *** 作的原子性，这种说法不大准确，其一，x86需要LOCK前缀才能在SMP下保证原子性，其二，RISC根本不能对内存直接运算，要保证原子性得用别的方法，如atomic_inc。

对于jiffies，它已经声明为volatile变量，我认为直接用jiffies++就可以了，没必要用那种复杂的形式，因为那样也不能保证原子性。

你可能不知道在Pentium及后续CPU中，下面两组指令

inc jiffies

mov jiffies, %eax

inc %eax

mov %eax, jiffies

作用相同，但一条指令反而不如三条指令快。

三、编译器优化 → C关键字volatile → memory破坏描述符zz

“memory”比较特殊，可能是内嵌汇编中最难懂部分。为解释清楚它，先介绍一下编译器的优化知识，再看C关键字volatile。最后去看该描述符。

1、编译器优化介绍

内存访问速度远不及CPU处理速度，为提高机器整体性能，在硬件上引入硬件高速缓存Cache，加速对内存的访问。另外在现代CPU中指令的执行并不一定严格按照顺序执行，没有相关性的指令可以乱序执行，以充分利用CPU的指令流水线，提高执行速度。以上是硬件级别的优化。再看软件一级的优化：一种是在编写代码时由程序员优化，另一种是由编译器进行优化。编译器优化常用的方法有：将内存变量缓存到寄存器；调整指令顺序充分利用CPU指令流水线，常见的是重新排序读写指令。对常规内存进行优化的时候，这些优化是透明的，而且效率很好。由编译器优化或者硬件重新排序引起的问题的解决办法是在从硬件（或者其他处理器）的角度看必须以特定顺序执行的 *** 作之间设置内存屏障（memory barrier），linux 提供了一个宏解决编译器的执行顺序问题。

void Barrier(void)

这个函数通知编译器插入一个内存屏障，但对硬件无效，编译后的代码会把当前CPU寄存器中的所有修改过的数值存入内存，需要这些数据的时候再重新从内存中读出。

2、C语言关键字volatile

C语言关键字volatile（注意它是用来修饰变量而不是上面介绍的__volatile__）表明某个变量的值可能在外部被改变，因此对这些变量的存取不能缓存到寄存器，每次使用时需要重新存取。该关键字在多线程环境下经常使用，因为在编写多线程的程序时，同一个变量可能被多个线程修改，而程序通过该变量同步各个线程，例如：

DWORD __stdcall threadFunc(LPVOID signal)

{

int* intSignal=reinterpret_cast<int*>(signal)

*intSignal=2

while(*intSignal!=1)

sleep(1000)

return 0

}

该线程启动时将intSignal 置为2，然后循环等待直到intSignal 为1 时退出。显然intSignal的值必须在外部被改变，否则该线程不会退出。但是实际运行的时候该线程却不会退出，即使在外部将它的值改为1，看一下对应的伪汇编代码就明白了：

mov ax,signal

label:

if(ax!=1)

goto label

对于C编译器来说，它并不知道这个值会被其他线程修改。自然就把它cache在寄存器里面。记住，C 编译器是没有线程概念的！这时候就需要用到volatile。volatile 的本意是指：这个值可能会在当前线程外部被改变。也就是说，我们要在threadFunc中的intSignal前面加上volatile关键字，这时候，编译器知道该变量的值会在外部改变，因此每次访问该变量时会重新读取，所作的循环变为如下面伪码所示：

label:

mov ax,signal

if(ax!=1)

goto label

3、Memory

有了上面的知识就不难理解Memory修改描述符了，Memory描述符告知GCC：

1）不要将该段内嵌汇编指令与前面的指令重新排序；也就是在执行内嵌汇编代码之前，它前面的指令都执行完毕

2）不要将变量缓存到寄存器，因为这段代码可能会用到内存变量，而这些内存变量会以不可预知的方式发生改变，因此GCC插入必要的代码先将缓存到寄存器的变量值写回内存，如果后面又访问这些变量，需要重新访问内存。

如果汇编指令修改了内存，但是GCC 本身却察觉不到，因为在输出部分没有描述，此时就需要在修改描述部分增加“memory”，告诉GCC 内存已经被修改，GCC 得知这个信息后，就会在这段指令之前，插入必要的指令将前面因为优化Cache 到寄存器中的变量值先写回内存，如果以后又要使用这些变量再重新读取。

使用“volatile”也可以达到这个目的，但是我们在每个变量前增加该关键字，不如使用“memory”方便。

---