内核代码绝大部分使用 C 语言编写,只有一小部分使用汇编语言编写,例如与特定体系结构相关的代码和对性能影响很大的代码。GCC 提供了内嵌汇编的功能,可以在 C 代码中直接内嵌汇编语言语句,大大方便了程序设计。简单的内嵌汇编很容易理解,例:
接上篇...
3.5 破坏描述部分
3.5.1 寄存器破坏描述符
通常编写程序只使用一种语言:高级语言或者汇编语言。
高级语言编译的步骤大致如下: 预处理 → 编译 → 汇编 → 链接
我们这里只关心第二步编译(将 C 代码转换成汇编代码):因为所有的代码都是用高级语言编写,编译器可以识别各种语句的作用,在转换的过程中所有的寄存器都由编译器决定如何分配使用,它有能力保证寄存器的使用不会冲突;也可以利用寄存器作为变量的缓冲区,因为寄存器的访问速度比内存快很多倍。
如果全部使用汇编语言则由程序员去控制寄存器的使用,只能靠程序员去保证寄存器使用的正确性。但是如果两种语言混用情况就变复杂了,因为内嵌的汇编代码可以直接使用寄存器,而编译器在转换的时候并不去检查内嵌的汇编代码使用了哪些寄存器(因为很难检测汇编指令使用了哪些寄存器,例如有些指令隐式修改寄存器,有时内嵌的汇编代码会调用其他子过程,而子过程也会修改寄存器),因此需要一种机制通知编译器我们使用了哪些寄存器(程序员自己知道内嵌汇编代码中使用了哪些寄存器) 否则对这些寄存器的使用就有可能导致错误,修改描述部分可以起到这种作用。当然内嵌汇编的输入输出部分指明的寄存器或者指定为“r”“g”型由编译器去分配的寄存器就不需要在破坏描述部分去描述,因为编译器已经知道了。
破坏描述符由逗号格开的字符串组成,每个字符串描述一种情况,一般是寄存器名;除寄存器外还有“memory”。例如:“%eax”“%ebx”“memory”等。
下面看个例子就很清楚为什么需要通知 GCC 内嵌汇编代码中隐式(称它为隐式是因为GCC 并不知道)使用的寄存器。
在内嵌的汇编指令中可能会直接引用某些寄存器,我们已经知道 AT&T 格式的汇编语言中,寄存器名以“%”作为前缀,为了在生成的汇编程序中保留这个“%”号,在 asm 语句中对寄存器的引用必须用“%%”作为寄存器名称的前缀。原因是“%”在 asm,内嵌汇编语句中的作用与“\”在 C 语言中的作用相同,因此“%%”转换后代表“%”
。例(没有使用修改描述符)
:
int main(void)
{
int input, output,temp;
input = 1;
__asm__ __volatile__ ("movl $0, %%eax;\n\t
movl %%eax, %1;\n\t
movl %2, %%eax;\n\t
movl %%eax, %0;\n\t"
:"=m"(output),"=m"(temp)
:"r"(input)
/* input */
);
return 0;
}
/* output */
这段代码使用%eax 作为临时寄存器,功能相当于 C 代码:
“temp = 0;output=input” 对应的汇编代码如下:
movl $1,-4(%ebp)
movl -4(%ebp),%eax
movl $0, %eax;
movl %eax, -12(%ebp);
movl %eax, %eax;
movl %eax, -8(%ebp);
/APP
/NO_APP
显然 GCC 给 input 分配的寄存器也是%eax,发生了冲突,output 的值始终为 0,而不是input。 使用破坏描述后的代码:
int main(void)
{
int input, output,temp;
input = 1;
__asm__ __volatile__
(
"movl $0, %%eax;\n\t
movl %%eax, %1;\n\t
movl %2, %%eax;\n\t
movl %%eax, %0;\n\t"
:"=m"(output),"=m"(temp)
:"r"(input)
/* input */
:"eax"); /* 描述符 */
/* output */
return 0;
}
对应的汇编代码:
movl $1,-4(%ebp)
movl -4(%ebp),%edx
/APP
movl $0, %eax;
movl %eax, -12(%ebp);
movl %edx, %eax;
movl %eax, -8(%ebp); /NO_APP
通过破坏描述部分,GCC 得知%eax 已被使用,因此给 input 分配了%edx。在使用内嵌汇编时请记住一点:尽量告诉 GCC 尽可能多的信息,以防出错。如果你使用的指令会改变 CPU 的条件寄存器 cc,需要在修改描述部分增加“cc”。
3.5.2 memory 破坏描述符
“memory”比较特殊,可能是内嵌汇编中最难懂部分。为解释清楚它,先介绍一下编译器的优化知识,再看 C 关键字 volatile。最后去看该描述符。
3.5.2.1 编译器优化介绍
内存访问速度远不及 CPU 处理速度,为提高机器整体性能,在硬件上引入硬件高速缓存 Cache,加速对内存的访问。另外在现代 CPU 中指令的执行并不一定严格按照顺序执行,没有相关性的指令可以乱序执行,以充分利用 CPU 的指令流水线,提高执行速度。
以上是硬件级别的优化。再看软件一级的优化:一种是在编写代码时由程序员优化,另一种是由编译器进行优化。编译器优化常用的方法有:将内存变量缓存到寄存器;调整指令顺序充分利用 CPU 指令流水线,常见的是重新排序读写指令。
对常规内存进行优化的时候,这些优化是透明的,而且效率很好。由编译器优化或者硬件重新排序引起的问题的解决办法是在从硬件(或者其他处理器)的角度看必须以特定顺序执行的操作之间设置内存屏障(memory barrier)
,linux 提供了一个宏解决编译器的执行顺序问题。
void Barrier(void)
这个函数通知编译器插入一个内存屏障,但对硬件无效,编译后的代码会把当前 CPU寄存器中的所有修改过的数值存入内存,需要这些数据的时候再重新从内存中读出。
3.5.2.2 C 语言关键字 volatile
C 语言关键字 volatile(注意它是用来修饰变量而不是上面介绍的__volatile__)表明某个变量的值可能在外部被改变,因此对这些变量的存取不能缓存到寄存器,每次使用时需要重新存取。该关键字在多线程环境下经常使用,因为在编写多线程的程序时,同一个变量可能被多个线程修改,而程序通过该变量同步各个线程,例如:
DWORD __stdcall threadFunc(LPVOID signal)
{
int* intSignal=reinterpret_cast(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.5.2.3 Memory
有了上面的知识就不难理解 Memory 修改描述符了,Memory 描述符告知 GCC:
(1)不要将该段内嵌汇编指令与前面的指令重新排序;也就是在执行内嵌汇编代码之前,它前面的指令都执行完毕。
(2)不要将变量缓存到寄存器,因为这段代码可能会用到内存变量,而这些内存变量会以不可预知的方式发生改变,因此 GCC 插入必要的代码先将缓存到寄存器的变量值写回内存,如果后面又访问这些变量,需要重新访问内存。
如果汇编指令修改了内存,但是 GCC 本身却察觉不到,因为在输出部分没有描述,此时就需要在修改描述部分增加“memory”,告诉 GCC 内存已经被修改,GCC 得知这个信息后,就会在这段指令之前,插入必要的指令将前面因为优化 Cache 到寄存器中的变量值先写回内存,如果以后又要使用这些变量再重新读取。例:
...........
Char test[100];
char a;
char c;
c = 0;
test[0] = 1;
........
a = test [0];
......
__asm__(
"cld\n\t"
"rep\n\t"
"stosb"
: /* no output */
: "a" (c),"D" (test),"c" (100)
:
"cx","di","memory");
..........
// 我们知道 test[0] 已经修改,所以重新读取
a=test[0];
......
这段代码中的汇编指令功能与 memset 相当,也就是相当于调用了 memset(test,0,100);它使用 stosb 修改了 test 数组的内容,但是没有在输入或输出部分去描述操作数,因为这两条指令都不需要显式的指定操作数,因此需要增加“memory”通知 GCC。现在假设:GCC在优化时将 test[0]放到了%eax 寄存器,那么 test[0] = 1 对应于%eax=1,a = test [0]被换为a=%eax,如果在那段汇编指令中不使用“memory”,Gcc 不知道现在 test[0]的值已经被改变了(如果整段代码都是我们自己使用汇编编写,我们自己当然知道这些内存的修改情况,我
们也可以人为的去优化,但是现在除了我们编写的那一小段外,其他汇编代码都是 GCC 生成的,它并没有那么智能,知道这段代码会修改 test[0]),结果其后的 a=test[0],转换为汇编后却是 a=%eax,因为 GCC 不知道显式的改变了 test 数组,结果出错了。如果增加了“memory”修饰符,GCC 知道:“这段代码修改了内存,但是也仅此而已,它并不知道到底修改了哪些变量”,因此他将以前因优化而缓存到寄存器的变量值全部写回内存,从内嵌
汇编开始,如果后面的代码又要存取这些变量,则重新存取内存(不会将读写操作映射到以前缓存的那个寄存器)
。这样上面那段代码最后一句就不再是%eax=1,而是 test[0] = 1。这两条对实现临界区至关重要,第一条保证不会因为指令的重新排序将临界区内的代码调到临界区之外(如果临界区内的指令被重排序放到临界区之外,What will happen?),第二条保证在临界区访问的变量的值,肯定是最新的值,而不是缓存在寄存器中的值,否则就会导致奇怪的错误。例如下面的代码:
int del_timer(struct timer_list * timer)
{
int ret = 0;
if (timer->next) {
unsigned long flags;
struct timer_list * next;
save_flags(flags);
cli();
临界区开始
//
if ((next = timer->next) != NULL) {
(next->prev = timer->prev)->next = next;
timer->next = timer->prev = NULL;
ret = 1;
}
// 临界区结束
restore_flags(flags);
}
return
ret;
}
它先判断 timer->next 的值,如果是空直接返回,无需进行下面的操作。如果不是空,则进入临界区进行操作,但是 cli()的实现(见下面)没有使用“memory”,timer->next 的值可能会被缓 存到寄存器 中,后面 if ((next =timer->next) != NULL)会从 寄存器中读 取timer->next 的值,如果在 if (timer->next)之后,进入临界区之前,timer->next 的值可能被在外部改变,这时肯定会出现异常情况,而且这种情况很难 Debug。但是如果 cli 使用“memory”,那么 if ((next = timer->next) !=NULL)语句会重新从内存读取 timer->next 的值,而不会从寄存器中取,这样就不会出现问题啦。
2.4 版内核中 cli 和 sti 的代码如下:
#define __cli()
__asm__
__volatile__("cli": : :"memory")
#define __sti()
__asm__
__volatile__("sti": : :"memory")
通过上面的例子,读者应该知道,为什么指令没有修改内存,但是却使用“memory”修改描述符的原因了吧。应从指令的上下文去理解为什么要这样做。使用“volatile”也可以达到这个目的,但是我们在每个变量前增加该关键字,不如使用“memory”方便。
4 GCC 如何编译内嵌汇编代码
GCC 编译内嵌汇编代码的步骤如下:
[1] 输入变量与占位符
根据限定符和破坏描述部分,为输入和输出部分的变量分配合适的寄存器,如果限定符指定为立即数(“i”),或内存变量(“m”),则不需要该步骤,如果限定符没有具体指定输入操作数的类型(如“g”),GCC 会视需要决定是否将该操作数输入到某个寄存器。这样每个占位符都与某个寄存器、内存变量或立即数形成了一一对应的关系。对分配了寄存器的输入变量需要增加代码将它的值读入寄存器。另外还要根据破坏描述符的部分增加额外代码。
[2] 指令模板部分
然后根据这种一一对应的关系,用这些寄存器、内存变量或立即数来取代汇编代码中的占位符。
[3] 变量输出
按照输出限定符的指定将寄存器的内容输出到某个内存变量中,如果输出操作数的限定符指定为内存变量(“m”),则该步骤被省略。
5 后记
该文档参照了 Web 上的许多与 GCC 内嵌汇编相关的文章编写而成,在此表示感谢,如有问题请发 Email 至:bbc631@126.com 一起讨论。
