【转】函数调用方式

Posted by Ryan @ 10:02 am, 11月 3rd, 2011

http://www.cnblogs.com/Dah/archive/2006/11/29/576867.html

在C语言中,假设我们有这样的一个函数:

int function(int a,int b)

调用时只要用result = function(1,2)这样的方式就可以使用这个函数。但是,当高级
语言被编译成计算机可以识别的机器码时,有一个问题就凸现出来:在CPU中,计算机没
有办法知道一个函数调用需要多少个、什么样的参数,也没有硬件可以保存这些参数。
也就是说,计算机不知道怎么给这个函数传递参数,传递参数的工作必须由函数调用者
和函数本身来协调。为此,计算机提供了一种被称为栈的数据结构来支持参数传递。

栈是一种先进后出的数据结构,栈有一个存储区、一个栈顶指针。栈顶指针指向堆栈中
第一个可用的数据项(被称为栈顶)。用户可以在栈顶上方向栈中加入数据,这个操作
被称为压栈(Push),压栈以后,栈顶自动变成新加入数据项的位置,栈顶指针也随之修
改。用户也可以从堆栈中取走栈顶,称为弹出栈(pop),弹出栈后,栈顶下的一个元素变
成栈顶,栈顶指针随之修改。

函数调用时,调用者依次把参数压栈,然后调用函数,函数被调用以后,在堆栈中取得
数据,并进行计算。函数计算结束以后,或者调用者、或者函数本身修改堆栈,使堆栈
恢复原装。

在参数传递中,有两个很重要的问题必须得到明确说明:

当参数个数多于一个时,按照什么顺序把参数压入堆栈
函数调用后,由谁来把堆栈恢复原装
在高级语言中,通过函数调用约定来说明这两个问题。常见的调用约定有:

stdcall
cdecl
fastcall
thiscall
naked call
stdcall调用约定
stdcall很多时候被称为pascal调用约定,因为pascal是早期很常见的一种教学用计算机
程序设计语言,其语法严谨,使用的函数调用约定就是stdcall。在Microsoft C++系列
的C/C++编译器中,常常用PASCAL宏来声明这个调用约定,类似的宏还有WINAPI和CALLB
ACK。

stdcall调用约定声明的语法为(以前文的那个函数为例):

int __stdcall function(int a,int b)

stdcall的调用约定意味着:1)参数从右向左压入堆栈,2)函数自身修改堆栈 3)函数
名自动加前导的下划线,后面紧跟一个@符号,其后紧跟着参数的尺寸

以上述这个函数为例,参数b首先被压栈,然后是参数a,函数调用function(1,2)调用处
翻译成汇编语言将变成:

push 2 第二个参数入栈
push 1 第一个参数入栈
call function 调用参数,注意此时自动把cs:eip入栈

而对于函数自身,则可以翻译为:

push ebp 保存ebp寄存器,该寄存器将用来保存堆栈的栈顶指针,可以在函数退出
时恢复
mov ebp,esp 保存堆栈指针
mov eax,[ebp + 8H] 堆栈中ebp指向位置之前依次保存有ebp,cs:eip,a,b,ebp +8指向
a
add eax,[ebp + 0CH] 堆栈中ebp + 12处保存了b
mov esp,ebp 恢复esp
pop ebp
ret 8

而在编译时,这个函数的名字被翻译成_function@8

注意不同编译器会插入自己的汇编代码以提供编译的通用性,但是大体代码如此。其中
在函数开始处保留esp到ebp中,在函数结束恢复是编译器常用的方法。

从函数调用看,2和1依次被push进堆栈,而在函数中又通过相对于ebp(即刚进函数时的
堆栈指针)的偏移量存取参数。函数结束后,ret 8表示清理8个字节的堆栈,函数自己
恢复了堆栈。

cdecl调用约定
cdecl调用约定又称为C调用约定,是C语言缺省的调用约定,它的定义语法是:

int function (int a ,int b) //不加修饰就是C调用约定
int __cdecl function(int a,int b)//明确指出C调用约定

在写本文时,出乎我的意料,发现cdecl调用约定的参数压栈顺序是和stdcall是一样的
,参数首先由有向左压入堆栈。所不同的是,函数本身不清理堆栈,调用者负责清理堆
栈。由于这种变化,C调用约定允许函数的参数的个数是不固定的,这也是C语言的一大
特色。对于前面的function函数,使用cdecl后的汇编码变成:

调用处
push 1
push 2
call function
add esp,8 注意:这里调用者在恢复堆栈
被调用函数_function处
push ebp 保存ebp寄存器,该寄存器将用来保存堆栈的栈顶指针,可以在函数退出
时恢复
mov ebp,esp 保存堆栈指针
mov eax,[ebp + 8H] 堆栈中ebp指向位置之前依次保存有ebp,cs:eip,a,b,ebp +8指向
a
add eax,[ebp + 0CH] 堆栈中ebp + 12处保存了b
mov esp,ebp 恢复esp
pop ebp
ret 注意,这里没有修改堆栈

MSDN中说,该修饰自动在函数名前加前导的下划线,因此函数名在符号表中被记录为_f
unction,但是我在编译时似乎没有看到这种变化。

由于参数按照从右向左顺序压栈,因此最开始的参数在最接近栈顶的位置,因此当采用
不定个数参数时,第一个参数在栈中的位置肯定能知道,只要不定的参数个数能够根据
第一个后者后续的明确的参数确定下来,就可以使用不定参数,例如对于CRT中的sprin
tf函数,定义为:

int sprintf(char* buffer,const char* format,…)

由于所有的不定参数都可以通过format确定,因此使用不定个数的参数是没有问题的。

fastcall
fastcall调用约定和stdcall类似,它意味着:

函数的第一个和第二个DWORD参数(或者尺寸更小的)通过ecx和edx传递,其他参数通过
从右向左的顺序压栈
被调用函数清理堆栈
函数名修改规则同stdcall
其声明语法为:int fastcall function(int a,int b)

thiscall
thiscall是唯一一个不能明确指明的函数修饰,因为thiscall不是关键字。它是C++类成
员函数缺省的调用约定。由于成员函数调用还有一个this指针,因此必须特殊处理,th
iscall意味着:

参数从右向左入栈
如果参数个数确定,this指针通过ecx传递给被调用者;如果参数个数不确定,this指针
在所有参数压栈后被压入堆栈。
对参数个数不定的,调用者清理堆栈,否则函数自己清理堆栈
为了说明这个调用约定,定义如下类和使用代码:

class A
{
public:
int function1(int a,int b);
int function2(int a,…);
};
int A::function1 (int a,int b)
{
return a+b;
}
#include
int A::function2(int a,…)
{
va_list ap;
va_start(ap,a);
int i;
int result = 0;
for(i = 0 i < a i ++)
{
result += va_arg(ap,int);
}
return result;
}
void callee()
{
A a;
a.function1 (1,2);
a.function2(3,1,2,3);
}

callee函数被翻译成汇编后就变成:

//函数function1调用
0401C1D push 2
00401C1F push 1
00401C21 lea ecx,[ebp-8]
00401C24 call function1 注意,这里this没有被入栈
//函数function2调用
00401C29 push 3
00401C2B push 2
00401C2D push 1
00401C2F push 3
00401C31 lea eax,[ebp-8] 这里引入this指针
00401C34 push eax
00401C35 call function2
00401C3A add esp,14h

可见,对于参数个数固定情况下,它类似于stdcall,不定时则类似cdecl

naked call
这是一个很少见的调用约定,一般程序设计者建议不要使用。编译器不会给这种函数增
加初始化和清理代码,更特殊的是,你不能用return返回返回值,只能用插入汇编返回
结果。这一般用于实模式驱动程序设计,假设定义一个求和的加法程序,可以定义为:

__declspec(naked) int add(int a,int b)
{
__asm mov eax,a
__asm add eax,b
__asm ret
}

注意,这个函数没有显式的return返回值,返回通过修改eax寄存器实现,而且连退出函
数的ret指令都必须显式插入。上面代码被翻译成汇编以后变成:

mov eax,[ebp+8]
add eax,[ebp+12]
ret 8

注意这个修饰是和__stdcall及cdecl结合使用的,前面是它和cdecl结合使用的代码,对
于和stdcall结合的代码,则变成:

__declspec(naked) int __stdcall function(int a,int b)
{
__asm mov eax,a
__asm add eax,b
__asm ret 8 //注意后面的8
}

至于这种函数被调用,则和普通的cdecl及stdcall调用函数一致。

函数调用约定导致的常见问题
如果定义的约定和使用的约定不一致,则将导致堆栈被破坏,导致严重问题,下面是两
种常见的问题:

函数原型声明和函数体定义不一致
DLL导入函数时声明了不同的函数约定
以后者为例,假设我们在dll种声明了一种函数为:

__declspec(dllexport) int func(int a,int b);//注意,这里没有stdcall,使用的是
cdecl
使用时代码为:

typedef int (*WINAPI DLLFUNC)func(int a,int b);
hLib = LoadLibrary(…);
DLLFUNC func = (DLLFUNC)GetProcAddress(…)//这里修改了调用约定
result = func(1,2);//导致错误

由于调用者没有理解WINAPI的含义错误的增加了这个修饰,上述代码必然导致堆栈被破
坏,MFC在编译时插入的checkesp函数将告诉你,堆栈被破坏了。

【转】Duff’s Device

Posted by Ryan @ 12:51 pm, 07月 20th, 2011

http://hi.baidu.com/nxdl/blog/item/b81856365d338ad3a3cc2bd9.html

前几天在网上看见了一段代码,叫做“Duff’s Device”,后经验证它曾出现在Bjarne的TC++PL里面: 

 void send( int * to, int * from, int count)
          //     Duff设施,有帮助的注释被有意删去了 
 {
          int n = (count + 7 ) / 8 ;
          switch (count % 8 ) {
          case 0 :    do { * to ++ = * from ++ ;
          case 7 :          * to ++ = * from ++ ;
          case 6 :          * to ++ = * from ++ ;
          case 5 :          * to ++ = * from ++ ;
          case 4 :          * to ++ = * from ++ ;
          case 3 :          * to ++ = * from ++ ;
          case 2 :          * to ++ = * from ++ ;
          case 1 :          * to ++ = * from ++ ;
                  } while ( – n >    0 );
          } 
 }   

代码的结构显得非常巧妙,把一个switch语句和一个do-while语句糅合在了一起。而在我看过的所有关于C和C++的书中,这样的代码都 是毫无道理的。然而,无论是在VS2005还是在GCC4.1.2下,这段代码都能正确地通过编译。加上适当的main函数,它都可以正常运行。我百思不 得其解。上网去查,也没查到好答案。

怎么办?先看看它的汇编代码吧,也许可以通过它的汇编代码看出它的意思。

gcc -S send.cpp

粗略地一看,汇编代码都已经上百行了,而且里面还有一个跳转表,十几个标号。一般情况下,几十行的汇编代码都已经不太好看懂了,要把这几百行汇编完全看懂,估计需要花很多时间。

既然直接来太麻烦,那就用简便一点的方法吧:

 #include < iostream > 
 using namespace std;
 
 int main()
 {
      int n = 0 ;
      switch (n) { 
      case 0 :  do {cout << ” 0 ” << endl;
      case 1 :      cout << ” 1 ” << endl;
      case 2 :       cout << ” 2 ” << endl;
      case 3 :       cout << ” 3 ” << endl; 
              } while ( – n > 0 ); 
      } 
 } 
实验结果 
n的值 程序输出 
0       0
        1
        2
        3 
————-
1       1
        2
        3 
————
2       2
        3
        0
        1
        2
        3 
————-
3       3
        0
        1
        2
        3
        0
        1
        2
        3 
————-
其他 (无输出) 

    这下终于弄清楚了。原来,那段代码的主体还是do-while循环,但这个循环的入口点并不一定是在do那里,而是由这个switch语句根据n,把循环的 入口定在了几个case标号那里。也就是说,程序的执行流程是:程序一开始顺序执行,当它执行到了switch的时候,就会根据n的值,直接跳转到 case n那里(从此,这个swicth语句就再也没有用了)。程序继续顺序执行,再当它执行到while那里时,就会判断循环条件。若为真,则while循环开 始,程序跳转到do那里开始执行循环(这时候由于已经没有了switch,所以后面的标号就变成普通标号了,即在没有goto语句的情况下就可以忽略掉这 些标号了);为假,则退出循环,即程序中止。

    忙活了几个小时,终于明白这段代码是怎么回事了。回想一下,自己以前也曾写过类似C的语法但比C语法简单很多的解释器,用的是递归子程序法。而如果用递归下降法来分析这段代码,是肯定会有问题的。

至于它是怎么正确编译并运行的,这需要去研究一下C编译器,这个以后再说。现在,还是再来看看达夫设备吧。其实,这个send函数的签名就已经很具有提示性了:把from数组中的元素拷贝count个到to里面去。于是有人会说,这个工作简单,不就这样吗:

 void my_send( int * to, int * from, int count)
 {
      for ( int i = 0 ; i != count; ++ i) {
          * to ++ = * from ++ ;
      } 
 }

这段代码的确很简洁,也是正确的,而且生成的机器码也比send函数短很多。但是却忽略了一个因素:执行效率。计算一下就可以知 道,my_send函数里面的循环条件,即i和count的比较运算的次数,是达夫设备的8倍!在做整数赋值这种耗时很少的工作时,这种耗时相对较高的比 较工作是会大大地影响函数整体的效率的。达夫设备则是一种非常巧妙的解决办法(当然,它利用到了编译器的一些实现上的工作),而且如果把8换成更大的数的 话,效率就还可以提高!

它的思路是这样的:把原数组以8个int为单位分成若干个小组,复制的时候以小组为单位复制,即一次复制8个 int。也就是说,在my_send函数中以一次比较运算的代价换来1个int的复制,而在达夫设备中,却能以一次比较运算的代价换来8个int的复制。 而switch语句则是用来处理分组时剩下的不到8个的int(这些剩余的不是数组最后的,而是数组最开始的),很巧妙。

总结:像达夫设 备这样的代码,从语言的角度来看,我个人觉得不值得我们借鉴。因为这毕竟不是“正常”的代码,至少C/C++标准不会保证这样的代码一定不会出错。另外, 这种代码估计有很多人根本都没见过,如果自己写的代码别人看不懂,这也会是一件很让人头疼的事。然而,从算法的角度来看,我觉得达夫设备是个很高效、很值 得我们去学习的东西。把一次消耗相对比较高的操作“分摊“到了多次消耗相对比较低的操作上面,就像vector<T>中实现可变长度的数组的 思想那样,节省了大量的机器资源,也大大提高了程序的效率。这是值得我们学习的。

void duff_memcpy( char* to, char* from, size_t count )

{

   size_t n = (count+7)/8;

   switch( count%8 ) 

{

   case 0: do{ *to++ = *from++;

   case 7: *to++ = *from++;

   case 6: *to++ = *from++;

   case 5: *to++ = *from++;

   case 4: *to++ = *from++;

   case 3: *to++ = *from++;

   case 2: *to++ = *from++;

   case 1: *to++ = *from++;

   }while(–n>0);

   }

duff’s device,是用Tom Duff的名字来命名的。很有名的一个东西,用来优化拷贝的,据说和Rob Pike此牛还有点儿关系~!不过注意,原始的duff’s device中的to可是不变的,因为它指向一个映射到内存的寄存器。

这是个很棒的迂回循环展开法, 由 Tom Duff 在 Lucasfilm 时所设计。它的 “传统” 形态, 是用来复制多个字节: 
    register n = (count + 7) / 8;   /* count > 0 assumed */
    switch (count % 8)
    {
    case 0:    do { *to = *from++;
    case 7:     *to = *from++;
    case 6:     *to = *from++;
    case 5:     *to = *from++;
    case 4:     *to = *from++;
    case 3:     *to = *from++;
    case 2:     *to = *from++;
    case 1:     *to = *from++;
          } while (–n > 0);
    }

这里 count 个字节从 from 指向的数组复制到 to 指向的内存地址 (这是个内存映射的输出寄存器, 这也是为什么它没有被增加)。它把 swtich 语句和复制 8 个字节的循环交织在一起, 从而解决了剩余字节的处理问题 (当 count 不是 8 的倍数时)。相信不相信, 象这样的把 case 标志放在嵌套在 swtich 语句内的模块中是合法的。当他公布这个技巧给 C 的开发者和世界时, Duff 注意到 C 的 swtich 语法, 特别是 “跌落” 行为, 一直是被争议的, 而 “这段代码在争论中形成了某种论据, 但我不清楚是赞成还是反对”。

转 atoi的快速算法

Posted by Ryan @ 11:37 am, 07月 20th, 2011

原文见陈硕的blog:http://blog.csdn.net/solstice/article/details/5139302

这个算法很巧妙,代码如下:

const char* convert(char buf[], int val)
{
    static char digits[19] = {‘9′, ‘8′, ‘7′, ‘6′, ‘5′, ‘4′, ‘3′, ‘2′, ‘1′, ‘0′, ‘1′, ‘2′, ‘3′, ‘4′, ‘5′, ‘6′, ‘7′, ‘8′, ‘9′};

    static const char* zero = digits + 9;

    int i = val;
    char* p = buf;

    do {
        int lsd = i % 10;
        std::cout << i << ” % 10 = ” << lsd << std::endl;
        i /= 10;
        *p++ = zero[lsd];
    } while (i != 0);

    if (val < 0)
    {
        *p++ = ‘-’;
    }

    *p = ”;

    std::reverse(buf, p);

    return buf;
}

我们真正需要什么?

Posted by Ryan @ 12:56 pm, 06月 6th, 2011

        古人说:三十而立。猛然间发现自己已经三十了,好像什么都没“立”起来。每天忙着替别人的帝国添砖加瓦,而岁月就在此间流逝,渐渐的磨光了所有的棱角,麻木起来。衡量人生的也只是钱以及它的附属:车、房等等,所以你必须为它忙碌,牺牲掉健康和亲情换一点可怜的工资。人,不再是独立而自由的生灵,变成了千遍一律的机器,没有生气。我想这很悲哀。

        当每天收到互联网成千上万的信息时,我们以为自己过得很充实,以为这世上的事可以无所不知,事实却是我们根本无暇思考,更不用说深沉的思考。当我们高谈阔论,显摆着自己的财富、幸福、经历时,我们以为很自豪很骄傲,可是我们从未想到这是否是我们想要的。人生,不是用来体验这些肤浅的快感。

         人生是上天恩赐的一次探索之旅,唯有坚定执着的信念才能勇往直前,自我了悟,而不应沉迷于表面的色相。老子讲:“五色令人目盲,五音令人耳聋,五味令人口爽,驰骋畋猎令人心发狂,难得之货令人行妨。是以圣人,为腹不为目,故去彼取此。”佛教也讲无眼耳口鼻舌身意。古今至理,先人已经讲的很透彻了。

SAX和DOM

Posted by Ryan @ 4:36 pm, 04月 16th, 2011

当你需要处理XML文档时,你的首要选择是使用DOM(文档对象模型)还是使用SAX(用于XML的简单API),即当前使用的两个主要的XML API。你可以使用任何一种(或者在同一时间使用两种)来处理XML文档,然而DOM将文档载入到内存中处理,而SAX则相反,它可以检测一个即将到来的 XML流,由此并不需要所有的XML代码同时载入到内存中。
选择DOM与SAX,与在一个数据库中的表单与视图之前选择一样:选择适合于当前实际情况的方法。如果你只是想简单地查看XML文档而不处理它,那么请选择使用SAX。
SAX与DOM之间有一些显著区别,包括:
         DOM是复杂对象处理的首选,比如当XML比较复杂的时候,或者当你需要随机处理文档中数据的时候。SAX从文档的开始通过每一节点移动,以定位一个特定的节点。
DOM为载入到内存的文档节点建立类型描述。最终,这些描述呈现了可容易横向移动、潜在巨大、树型结构。如果XML很冗长,DOM就会显示出无法控制的胀大。例如,一个300KB的XML文档可以导致RAM或者虚拟内存中的3,000,000KB的DOM树型结构。通过比较就会发现,一个SAX文档根本就没有被解构,它也没有隐藏在内存空间中(当然当XML流被读入时,会有部分文档暂时隐藏在内存中)。SAX就是一种“更轻巧的”技术 ──它可以给你的系统带来更轻的负担。SAX相当于观看一场马拉松比赛,而DOM就好比邀请所有的比赛选手到家里参加晚餐。
所以,你如何选择 SAX和DOM?如果你处理复杂的东西,比如高级XSLT转换,或者Xpath过滤,请选择使用DOM。如果你建立或者更改XML文档,你也可以选择 DOM。
相反,你可以使用SAX来查询或者阅读XML文档。SAX可以快速扫描一个大型的XML文档,当它找到查询标准时就会立即停止,然后再处理之。
在某些情况下,在一个方案中,最佳的选择是使用DOM和SAX处理不同的部分。例如,你可以使用DOM将XML载入到内存并改变它,然后通过从DOM树中发送一个SAX流而转移最后的结果。
SAX概念

   SAX是Simple API for XML的缩写,它并不是由W3C官方所提出的标准,可以说是“民间”的事实标准。实际上,它是一种社区性质的讨论产物。虽然如此,在XML中对SAX的应用丝毫不比DOM少,几乎所有的XML解析器都会支持它。

与DOM比较而言,SAX是一种轻量型的方法。我们知道,在处理DOM的时候,我们需要读入整个的XML文档,然后在内存中创建DOM树,生成 DOM树上的每个Node对象。当文档比较小的时候,这不会造成什么问题,但是一旦文档大起来,处理DOM就会变得相当费时费力。特别是其对于内存的需求,也将是成倍的增长,以至于在某些应用中使用DOM是一件很不划算的事(比如在applet中)。这时候,一个较好的替代解决方法就是SAX。

   SAX在概念上与DOM完全不同。首先,不同于DOM的文档驱动,它是事件驱动的,也就是说,它并不需要读入整个文档,而文档的读入过程也就是SAX的解析过程。所谓事件驱动,是指一种基于回调(callback)机制的程序运行方法。(如果你对Java新的代理事件模型比较清楚的话,就会很容易理解这种机制了)

   在XMLReader接受XML文档,在读入XML文档的过程中就进行解析,也就是说读入文档的过程和解析的过程是同时进行的,这和DOM区别很大。解析开始之前,需要向XMLReader注册一个ContentHandler,也就是相当于一个事件监听器,在ContentHandler中定义了很多方法,比如startDocument(),它定制了当在解析过程中,遇到文档开始时应该处理的事情。当XMLReader读到合适的内容,就会抛出相应的事件,并把这个事件的处理权代理给ContentHandler,调用其相应的方法进行响应

facebook背后的软件

Posted by Ryan @ 10:10 am, 01月 7th, 2011

Facebook的数据规模使得很多传统的解决方案根本不适用,或者无法分解来处理。保持一个拥有5亿用户的系统一直稳定可靠的运行,并不是一件很容易的事情。这篇文章介绍了一下Facebook使用的软件。

  Facebook的扩展性挑战

  在我们讨论细节之前,这里有一些Facebook已经做的软件规模:

  > Facebook每月页面浏览量为5700亿(据Google Ad Planner)。

  > Facebook的照片量比其他所有图片网站加起来还多(包括Flickr等网站)。

  > 每个月超过30亿张照片被上传。

  > Facebook的系统服务每秒处理120万张照片 。 这不包括CDN服务中处理的照片。

  > 每月超过25亿条的内容 (状态更新,评论等)被共享。

  > Facebook有超过30,000服务器 (这个数字是去年的!)

  Facebook扩展所依赖的软件

  Facebook在某些程度上说仍然是LAMP的站点,但它比普通的LAMP大得多,以纳入其他元素和很多服务,并修改现行的做法。

  例如:

  >Facebook也使用PHP,但它已经为它建立一个编译器,以便它可以分为本地代码打开了Web服务器,从而提高性能。

  >Facebook也使用Linux,但它特别为网络吞吐量做了优化。

  >Facebook也使用MySQL,但主要是作为一个Key-value的持久性存储,Jions和服务器逻辑操作在Web服务器上操作。因为在那里更容易执行。

  >还有是自编写的系统,如Haystack,一个高度可扩展的对象存储,用来存储Facebook的照片。还有Scribe,一个日志系统,可以运行在Facebook的巨大规模上的日志系统。

  OK。现在 我们介绍一下全球最大的社会网络网站的所使用的软件吧。

  Memcached

  memcached的是现在互联网最有名的软件之一了。 这是一个分布式内存缓存系统,用来作为Web服务器和MySQL服务器之间的缓存层(因为数据库访问比较慢)。 多年以来,Facebook已经提出了一些优化Memcached和一些周边软件的办法。如压缩network stack。

  Facebook的每时每刻都有数10TB的数据缓存在Memcached的数千台服务器上。 它可能是世界上最大的Memcached的集群了。

  HipHop for PHP

  PHP作为一种脚本语言,和本地程序相比是运行缓慢的。 HipHop可以将PHP转换成C++代码,然后再进行编译,可以获得更好的性能。 因为Facebook严重依赖PHP,这使得其可以让Web服务器运行的更有效率。

  一个工程师小团队在Facebook(一开始只有三人)花了18个月时间开发HipHop,现在已经是可用状态。

  Haystack

  Haystack是Facebook的高性能照片存储/检索系统(严格来说,是一个对象存储,因此它并不一定要存储照片)。 它有许多工作要做;有超过20亿张上传的照片,并且每一个被保存在四个不同的分辨率,因此有超过800亿张照片。

  它不仅是对能够处理的上亿的照片,运行表现也是至关重要的。 正如我们前面提到的,Facebook的服务约120万张照片每秒 ,这个数字不包括CDN上的。 这是一个惊人的数字。

  BigPipe

  BigPipe是Facebook开发的一个动态的网页服务系统。 Facebook使用它来按section(称为“pagelets”)处理每个网页,以获取最佳性能。

  例如,在聊天窗口是分开的,新闻Feed也是分开的,等等。 这些pagelets可以在一个页面表现的时候同时使用,这是该页面表现的时候获取进来的。即使某些工程的一部分关闭或中端,用户也可以获得一部分网页。

  Cassandra

  Cassandra是一个不会单点失败的分布式存储系统。 这是为NoSQL运动的一个重要组成部分,并已公开的源代码(它甚至成为一个Apache项目)。Facebook在搜索功能中使用它。

  除了Facebook,还有一些人也用它,例如Digg的。 不过最近Twitter放弃了cassandra。

  Scribe

  Scribe是一个灵活的日志系统,Facebook在他的内部大量使用。 它的能够处理在Facebook的大规模日志记录,并自动处理新的日志记录类别,Facebook有数百个日志类别(categories)。

  Hadoop and Hive

  Hadoop的是一个开源的map-reduce实现,使得它可以在进行大数据上进行运算。 Facebook的使用这个进行数据分析(而我们都知道,Facebook已经大量的数据)。 Hive就是发源于Facebook,使得对于Hadoop使用的SQL查询成为可能,从而是其更容易对非程序员使用。

  Hadoop和Hive是开源的(Apache项目),有为数众多的追随者,例如雅虎和Twitter。

  Thrift

  Facebook使用的几种不同的语言和不同的services。 PHP是最终用于前端,Erlang是用于聊天,Java和C ++也使用于多种场所,也许还有其他语言。Thrift是一个内部开发的跨语言的框架,联系语言,使他们可以在一起合作,从而使他们之间可以交互。 这使得Facebook可以更容易为继续保持其跨语言的发展。

  Facebook已经让Thrift开源。更多的语言支持已被添加到Thrift。

  Varnish

  Varnish是一个HTTP加速器,可以作为一个负载平衡器,并缓存的内容,然后可以以闪电般的速度送达。

  Facebook使用的arnish来处理照片和个人资料图片,处理每天数十亿的要求。 和其他的东西一样,Varnish是开源的。

  保持Facebook 顺畅运行的其他东西。

  我们已经提到的软件,组成了Facebook的系统,并帮助运行在大规模上。 但是,处理这么大的系统是一个复杂的任务,因此我们将列出一些其他的东西,他们保持了Facebook的平稳运行。

  渐进发布和暗启动

  Facebook有一个他们所谓的守门人制度(Gatekeeper),允许他们可以给不同的用户运行两套不同的系统。 这让Facebook渐进的发布新的功能,A / B测试,只为Facebook雇员发布等的某些特性。

  Gatekeeper也可以让Facebook实现“暗启动”,这是在用户使用一些功能之前,就激活某些功能(因为用户没有察觉,所以称之为暗启动)。 这将作为一个现实世界的压力测试,在正式启动前,帮助揭露一些功能障碍和其他问题。 暗启动通常是在正式启动前两个星期。

  Profiling的直播系统

  Facebook的仔细监控其系统,有趣的是它也负责监察每一个PHP函数在生产环境的性能。 检测各个PHP的环境的配置运行情况。使用开源工具,XHProf。

  渐进的利用关闭功能来提升性能

  如果Facebook运行时出现性能问题,有一个办法,就是逐步禁用不太重要的功能,以增强Facebook的大量核心功能表现。

  我们没有提及的事情

  我们没有提到硬件相关的事情,但这也是提高可伸缩性的重要一环。例如,就像其他大型站点,Facebook利用CDN来处理静态内容。Facebook还有一个the huge data center,可以帮助他扩展更多的服务。

  Facebook的开源情节

  不仅是Facebook使用(和帮助),如Linux,Memcached的,MySQL和Hadoop的开源软件,以及许多其他情况下,也贡献许多了其内部开发的软件。

  Facebook亦开源了Tornado,一个高性能的网络服务器框架,由FriendFeed团队开发。

  关于开放源码软件清单,可以在Facebook’s Open Source page找到。

[转]终端会话和孤儿进程组

Posted by Ryan @ 2:02 pm, 10月 8th, 2010

终端的问题涉及几个概念,那就是进程组,会话,作业,下面会分别进行介绍。会话包含了一系列的进程,这些进程按照不同的执行内容会组织成若干进程组,一个会话内的所有进程都必须是该会话首长进程的后代,这样就保证了这些进程都是由该会话首长进程直接或者间接开启的,只有这样的才能保证这些进程确实是在会话首长进程耳目视线之内的,同时,孤儿进程组不再受到会话首长进程的控制。
作业:
只有一个终端,但是有很多事情要同时做,或者起码分时做,不能先做完一件事再做另一件,怎么办?毕竟启动一个进程后该进程就会独占终端啊,毕竟shell会将它设置为前台进程组进程啊。这就是作业的功能,只需要在一个命令后加一个&符号就可以了,比如我要执行x,那么就敲入:
x &
shell的结果是:
[1] 1234
此处1234是进程的pid,而1则是作业的id,这样这个x就不占用终端了,shell可以启动其它的进程或者作业了,比如又启动了作业2:
[2] 4321
此时想起作业1需要使用一下终端来输入一些信息了,那么就使用:fg %1将作业1置于前台(作业1中目前只有一个进程),置于前台的作业如何重新放到后台呢?只需要用SIGSTOP信号停止前台使用终端的进程即可,然后该进程就放开终端的占用了
进程组:一个作业就是一个进程组,单独的进程可以独占一个进程组也可以加入同一会话的别的进程组,必须要满足的条件是,同一进程组的所有进程都要是一个会话的后代。所谓的进程组是为了组织作业或者组织同一类任务的。
控制终端:
一个会话的建立者有权力申请一个控制终端,在该控制终端中可以接受标准输入,可以发送shell理解的控制快捷键,可以创建作业并且使用会话头进程提供的作业控制功能。控制终端只能由会话头进程创建,并且控制终端是独占的,只要有一个进程将一个终端当成了控制终端,别的进程不管它是谁都不能这么做了,tty_open中的最后有下面几行代码
if (!noctty &&
    current->signal->leader &&
    !current->signal->tty &&
    tty->session == 0) {
    task_lock(current);
    current->signal->tty = tty;
    task_unlock(current);
    current->signal->tty_old_pgrp = 0;
    tty->session = current->signal->session;  //设置session
    tty->pgrp = process_group(current);
}
可见别的进程是无权申请控制终端的。
     这个控制终端平时给谁用呢?最不容被怀疑的会话首长申请了终端,因为如果连他都值得怀疑的话,后面的属于他的孩子进程们都值得怀疑了,首长申请的终端就是给这些孩子们用的,首长将这些孩子们分成了若干的进程组,指定一个组为前台进程组,只有这个前台进程组的进程才能使用控制终端。bash一般会作为会话首长存在,bash将为一个执行的命令都创建一个进程组,它在接受一个命令准备执行的时候会将该进程设置为前台进程组,它在接受了命令行后加&的命令时,会创建一个作业,并且将它设定为后台进程组,那么此时前台是谁呢,是bash自己哦。后台进程不能使用终端,如果使用&执行了内部带有诸如getchar之类函数的进程,那么其将会收到SIGTTIN信号,不过可以使用fg命令将这类进程提到前台。
控制进程:
很显然,首先控制进程是一个会话的首长进程,另外即使是会话首长也只能通过终端来控制别的进程,所谓的控制就是发送信号而不是操作内存之类的,这也是进程间通信的一种方式。因此所谓的控制进程就是申请到控制终端的进程。
孤儿进程组:
有孤儿进程,对应的也有孤儿进程组的概念。为何引入这个概念以及这个概念的引入需要OS的实现者作些什么呢?先看两个前提,首先,posix用一个session的概念来描述一次用户的登录以及该用户在此次登录后的操作,然后用作业的概念描述不同操作的内容,最后才用进程的概念描述不同操作中某一个具体的工作;其次,unix最初将所有的进程组织成了树的形式,这样就便于追踪每个进程也便于管理(想想看,人类政治社会也是一个类似树形结构:君主专制,两院制等)。有了上述两个前提事情就很明白了,一切都是为了便于管理,一切都是为了登录用户的安全,即此次登录用户的作业是不能被下个登录用户所控制的,即使它们的用户名一致也是不行的,因此所谓的孤儿进程组简单点说就是脱离了创造它的session控制的,离开其session眼线的进程组,unix中怎样控制进程,怎样证明是否在自己的眼线内,那就是树形结构了,只要处于以自己为根的子树的进程就是自己眼线内的进程,这个进程就是受到保护的,有权操作的,而在别的树枝上的进程原则上是触动不得的(又想说说windows的远程线程创建了,可是说的话还要接着说其复杂的令牌机制,否则windows粉丝不服气,所以不说了罢),unix中建立进程使用fork,自然地这么一“叉子”就形成了自己的一个树枝,当然在自己眼线了,一般对于登录用户而言一个会话起始于一次login之后的shell,只要该用户不logout,在该终端的shell上执行的所有的非守护进程都是该shell的后代进程,因此它们组成一个会话,全部在shell的眼线中,一个会话终止于会话首长的death。现在考虑一下终端上的shell退出后的情景,按照规定,该终端上所有的进程都过继给了别的进程,大多数情况是init进程,然后紧接着另外一个用户登录了这个终端或者知道前一个登录用户密钥的另一个有不好念头的人登录了该终端,当然为其启动的shell创建了一个新的session,由于之前登录的用户已退出,现在登录的用户由于之前用户的进程组都成了孤儿进程组,所以它再有恶意也不能控制它们了,那些孤儿进程组中的成员要么继续安全的运行,要么被shell退出时发出的SIGHUP信号杀死。
     POSIX的规定是铁的纪律,而unix或者linux的不管是内核还是shell的实现则是一种遵守纪律的方式,铁的纪律要求作业控制要以session为基本,就是说不能操作别的session内的进程组,所以类似fg和bg等命令就不能操作孤儿进程,因此如果由于后台进程组由于读写终端被SIGSTOP信号停了,而后它又成了孤儿进程组的成员,那怎么办?别的session的作业控制命令又不能操作它,即使ps -xj找到了它然后手工发送了SIGCONT,那么它还是没法使用终端,这是POSIX的另一个纪律要求的,只有唯一和终端关联的session中的前台进程组的进程可以使用终端,因此只要有一个shell退出了,最好的办法就是将其session内的所有的进程都干掉,因此SIGHUP的原意就是如此,但是完全可以忽略这个信号或者自己定义对该信号的反应。POSIX的基本限制就是session的ID是不能设置的,因为它是受保护的基本单位,但是进程组的ID是可以设置的,毕竟它只是区分了不能的作业,最后进程的PID也是不能设置的,因为它是进程的内秉属性,形成树形进程结构的关键属性。
     POSIX对孤儿进程组的定义:组中没有一个进程的父进程和自己属于同一个会话但是不同进程组的。
守护进程:
守护进程需要做几件事:
1.fork一个子进程:由于bash在执行程序的时候会在fork和exec之间将该程序设置为前台进程组进程,这里的fork之后不进行如此设置,那么子进程就会成为后台进程,并且没有独占一个进程组,子进程属于父进程的进程组。
2.调用setsid开启一个新的会话,开启一个新的进程组,该进程成为一个新的会话的首长。
3.再次fork一个子进程,这样可以避免第一次fork时的子进程重新申请控制终端,毕竟它是会话首长。
4.关闭所有文件描述符,特别关闭0,1,2等和终端相关的描述符,因为已经没有终端了。
5….

本文来自CSDN博客,转载请标明出处:http://blog.csdn.net/dog250/archive/2010/08/14/5812293.aspx

(转贴)net use使用方法

Posted by Ryan @ 10:02 am, 09月 8th, 2010

NET USE 用于将计算机与共享的资源相连接,或者切断计算机与共享资源的连接。当不带选项使用本命令时,它会列出计算机的连接。

这个命令的使用格式如下:

NET USE
[devicename | *] [\computername\sharename[\volume] [passwo

rd | *]]
[/USER:[domainname\]username]
[/USER:[dotted domain name\]username]
[/USER:[username@dotted domain name]
[/SMARTCARD]
[/SAVECRED]
[[/DELETE] | [/PERSISTENT:{YES | NO}]]

DeviceName:指派名称以便连接到资源或指定断开的设备。有两种类型的设备名: 磁盘驱动器号(即 D: 到 Z:} 和打印机(即 LPT1:到 LPT3:}。如果键入星号而不是特定设备名,则系统会指派下一个可用的设备名。这个名称以后可以作为访问共享资源的名称进行引用。

\computername:指控制共享资源的计算机的名字。如果计算机名中包含有空字符,就要将双反斜线 (\) 和计算机名一起用引号 (” “)括起来。计算机名可以有1 到 15 个 字符。\volume :指定一个服务器上的NetWare卷。用户必须安装 Netware 的客户服务 (Windows 工作站) 或者 Netware 的网关服务(Windows 服务器) 并使之与 NetWare 服务器相连。

Password:指定访问共享资源所需的密码。输入星号 (*) 产生一个密码提示在密码提示行处键入密码时不显示密码。

/user:在其后指定建立连接时使用的不同于目前登录用户的用户名。

DomainName:指定不同于目前登录域的其他域。如果省略则net use使用当前登录的域。

注意,/user:后的登录用户和域可以有三种不同的表示形式,分别为domainname\username,dotted domain name\username和username@dotted domain name,其中dotted domain name提指域名的全称,如office.yesky.com,也即域名加域后缀的完全形式。

/SAVECRED:指定保留用户名和密码。除非命令提示输入用户名和密码。否则此开关被忽略,

/SMARTCARD:指定连接使用在智能卡上的凭据。

/delete:取消指定的网络连接。如果使用星号 (*) 指定连接,则所有网络连接均将取消。

/persistent:{yes | no}:控制持久网络连接的使用。默认值为最后一次使用的设置。非设备连接不会持久。Yes 将按其建立时的原样保存所有连接,并在下次登录时还原它们。No 则不保存已建立的连接或后续连接。现存的连接在下一次登录时还原。使用 /delete 删除持久连接。

Net use命令还有另两种使用格式,分别如下:

NET USE {devicename | *} [password | *] /HOME

NET USE [/PERSISTENT:{YES | NO}]

其中第一种命令格式将用户连到其域的主目录并将主目录映射为设备名DeviceName。后一种格式用来修改持久连接的使用。

下面是两个例子:

要连接用户标识符 Dan 就好像是通过 Accounts 域创建的连接:

net use d:\server\share /user:Accounts\Dan

要断开 \Financial\Public 目录:

net use f:\financial\public /delete

(zt)linux内存管理

Posted by Ryan @ 10:16 am, 10月 24th, 2009

摘要:本章首先以应用程序开发者的角度审视Linux的进程内存管理,在此基础上逐步深入到内核中讨论系统物理内存管理和内核内存的使用方法。力求从外到内、水到渠成地引导网友分析Linux的内存管理与使用。在本章最后,我们给出一个内存映射的实例,帮助网友们理解内核内存管理与用户内存管理之间的关系,希望大家最终能驾驭Linux内存管理。

前言

内存管理一向是所有操作系统书籍不惜笔墨重点讨论的内容,无论市面上或是网上都充斥着大量涉及内存管理的教材和资料。因此,我们这里所要写的Linux内存管理采取避重就轻的策略,从理论层面就不去班门弄斧,贻笑大方了。我们最想做的和可能做到的是从开发者的角度谈谈对内存管理的理解,最终目的是把我们在内核开发中使用内存的经验和对Linux内存管理的认识与大家共享。

当然,这其中我们也会涉及到一些诸如段页等内存管理的基本理论,但我们的目的不是为了强调理论,而是为了指导理解开发中的实践,所以仅仅点到为止,不做深究。

遵循“理论来源于实践”的“教条”,我们先不必一下子就钻入内核里去看系统内 存到底是如何管理,那样往往会让你陷入似懂非懂的窘境(我当年就犯了这个错误!)。所以最好的方式是先从外部(用户编程范畴)来观察进程如何使用内存,等 到大家对内存的使用有了较直观的认识后,再深入到内核中去学习内存如何被管理等理论知识。最后再通过一个实例编程将所讲内容融会贯通。

进程与内存

进程如何使用内存?

毫无疑问,所有进程(执行的程序)都必须占用一定数量的内存,它或是用来存放从磁盘载入的程序代码,或是存放取自用户输入的数据等等。不过进程对这些内存的管理方式因内存用途不一而不尽相同,有些内存是事先静态分配和统一回收的,而有些却是按需要动态分配和回收的。

对任何一个普通进程来讲,它都会涉及到5种不同的数据段。稍有编程知识的朋友都能想到这几个数据段中包含有“程序代码段”、“程序数据段”、“程序堆栈段”等。不错,这几种数据段都在其中,但除了以上几种数据段之外,进程还另外包含两种数据段。下面我们来简单归纳一下进程对应的内存空间中所包含的5种不同的数据区。

代码段:代码段是用来存放可执行文件的操作指令,也就是说是它是可执行程序在内存中的镜像。代码段需要防止在运行时被非法修改,所以只准许读取操作,而不允许写入(修改)操作——它是不可写的。

数据段:数据段用来存放可执行文件中已初始化全局变量,换句话说就是存放程序静态分配[1]的变量和全局变量。

BSS[2]BSS段包含了程序中未初始化的全局变量,在内存中 bss段全部置零。

堆(heap:堆是用于存放进程运行中被动态分配的内存段,它的大小并不固定,可动态扩张或缩减。当进程调用malloc等函数分配内存时,新分配的内存就被动态添加到堆上(堆被扩张);当利用free等函数释放内存时,被释放的内存从堆中被剔除(堆被缩减)

是用户存放程序临时创建的局部变量,也就是说我们函数括弧“{}”中定义的变量(但不包括static声明的变量,static意味着在数据段中存放变量)。除此以外,在函数被调用时,其参数也会被压入发起调用的进程中,并且待到调用结束后,函数的返回值也会被存放回中。由于的先进先出特点,所以特别方便用来保存/恢复调用现场。从这个意义上讲,我们可以把堆栈看成一个寄存、交换临时数据的内存区。

进程如何组织这些区域?

上述几种内存区域中数据段、BSS和堆通常是被连续存储的——内存位置上是连续的,而代码段和往往会被独立存放。有趣的是,堆和两个区域关系很“暧昧”,他们一个向下“长”(i386体系结构中向下、堆向上),一个向上“长”,相对而生。但你不必担心他们会碰头,因为他们之间间隔很大(到底大到多少,你可以从下面的例子程序计算一下),绝少有机会能碰到一起。

下图简要描述了进程内存区域的分布:

“事实胜于雄辩”,我们用一个小例子(原形取自《User-Level Memory Management)来展示上面所讲的各种内存区的差别与位置。

#include<stdio.h>

#include<malloc.h>

#include<unistd.h>

int bss_var;

int data_var0=1;

int main(int argc,char **argv)

{

  printf("below are addresses of types of process’s mem\n");

  printf("Text location:\n");

  printf("\tAddress of main(Code Segment):%p\n",main);

  printf("____________________________\n");

  int stack_var0=2;

  printf("Stack Location:\n");

  printf("\tInitial end of stack:%p\n",&stack_var0);

  int stack_var1=3;

  printf("\tnew end of stack:%p\n",&stack_var1);

  printf("____________________________\n");

  printf("Data Location:\n");

  printf("\tAddress of data_var(Data Segment):%p\n",&data_var0);

  static int data_var1=4;

  printf("\tNew end of data_var(Data Segment):%p\n",&data_var1);

  printf("____________________________\n");

  printf("BSS Location:\n");

  printf("\tAddress of bss_var:%p\n",&bss_var);

  printf("____________________________\n");

  char *b = sbrk((ptrdiff_t)0);

  printf("Heap Location:\n");

  printf("\tInitial end of heap:%p\n",b);

  brk(b+4);

  b=sbrk((ptrdiff_t)0);

  printf("\tNew end of heap:%p\n",b);

return 0;

 }

它的结果如下

below are addresses of types of process’s mem

Text location:

   Address of main(Code Segment):0×8048388

____________________________

Stack Location:

   Initial end of stack:0xbffffab4

   new end of stack:0xbffffab0

____________________________

Data Location:

   Address of data_var(Data Segment):0×8049758

   New end of data_var(Data Segment):0×804975c

____________________________

BSS Location:

   Address of bss_var:0×8049864

____________________________

Heap Location:

   Initial end of heap:0×8049868

   New end of heap:0×804986c

利用size命令也可以看到程序的各段大小,比如执行size example会得到

text data bss dec hex filename

1654 280   8 1942 796 example

但这些数据是程序编译的静态统计,而上面显示的是进程运行时的动态值,但两者是对应的。

通过前面的例子,我们对进程使用的逻辑内存分布已先睹为快。这部分我们就继续进入操作系统内核看看,进程对内存具体是如何进行分配和管理的。

从用户向内核看,所使用的内存表象形式会依次经历“逻辑地址”——“线性地址”——“物理地址”几种形式(关于几种地址的解释在前面已经讲述了)。逻辑地址经段机制转化成线性地址;线性地址又经过页机制转化为物理地址。(但是我们要知道Linux系统虽然保留了段机制,但是将所有程序的段地址都定死为0-4G,所以虽然逻辑地址和线性地址是两种不同的地址空间,但在Linux中逻辑地址就等于线性地址,它们的值是一样的)。沿着这条线索,我们所研究的主要问题也就集中在下面几个问题。

1.     进程空间地址如何管理?

2.     进程地址如何映射到物理内存?

3.     物理内存如何被管理?

以及由上述问题引发的一些子问题。如系统虚拟地址分布内存分配接口;连续内存分配与非连续内存分配等。

 

进程内存空间

Linux操作系统采用虚拟内存管理技术,使得每个进程都有各自互不干涉的进程地址空间。该空间是块大小为4G的线性虚拟空间,用户所看到和接触到的都是该虚拟地址,无法看到实际的物理内存地址。利用这种虚拟地址不但能起到保护操作系统的效果(用户不能直接访问物理内存),而且更重要的是,用户程序可使用比实际物理内存更大的地址空间(具体的原因请看硬件基础部分)。

在讨论进程空间细节前,这里先要澄清下面几个问题:

l         第一、4G的进程地址空间被人为的分为两个部分——用户空间与内核空间。用户空间从03G0xC0000000),内核空间占据3G4G。用户进程通常情况下只能访问用户空间的虚拟地址,不能访问内核空间虚拟地址。只有用户进程进行系统调用(代表用户进程在内核态执行)等时刻可以访问到内核空间。

l         第二、用户空间对应进程,所以每当进程切换,用户空间就会跟着变化;而内核空间是由内核负责映射,它并不会跟着进程改变,是固定的。内核空间地址有自己对应的页表init_mm.pgd,用户进程各自有不同的页表。

l         第三、每个进程的用户空间都是完全独立、互不相干的。不信的话,你可以把上面的程序同时运行10次(当然为了同时运行,让它们在返回前一同睡眠100秒吧),你会看到10个进程占用的线性地址一模一样。

 

进程内存管理

进程内存管理的对象是进程线性地址空间上的内存镜像这些内存镜像其实就是进程使用的虚拟内存区域(memory region)。进程虚拟空间是个3264位的“平坦”(独立的连续区间)地址空间(空间的具体大小取决于体系结构)。要统一管理这么大的平坦空间可绝非易事,为了方便管理,虚拟空间被划分为许多大小可变的(但必须是4096的倍数)内存区域,这些区域在进程线性地址中像停车位一样有序排列。这些区域的划分原则是“将访问属性一致的地址空间存放在一起”,所谓访问属性在这里无非指的是“可读、可写、可执行等”。

如果你要查看某个进程占用的内存区域,可以使用命令cat /proc/<pid>/maps获得(pid是进程号,你可以运行上面我们给出的例子——./example &;pid便会打印到屏幕),你可以发现很多类似于下面的数字信息。

由于程序example使用了动态库,所以除了example本身使用的内存区域外,还会包含那些动态库使用的内存区域(区域顺序是:代码段、数据段、bss段)。

我们下面只抽出和example有关的信息,除了前两行代表的代码段和数据段外,最后一行是进程使用的空间。

——————————————————————————-

08048000 – 08049000 r-xp 00000000 03:03 439029                               /home/mm/src/example

08049000 – 0804a000 rw-p 00000000 03:03 439029                               /home/mm/src/example

……………

bfffe000 – c0000000 rwxp ffff000 00:00 0

———————————————————————————————————————-

每行数据格式如下:

(内存区域)开始-结束 访问权限  偏移  主设备号:次设备号 i节点  文件。

注意,你一定会发现进程空间只包含三个内存区域,似乎没有上面所提到的堆、bss等,其实并非如此,程序内存段和进程地址空间中的内存区域是种模糊对应,也就是说,堆、bss、数据段(初始化过的)都在进程空间中由数据段内存区域表示。

Linux内核中对应进程内存区域的数据结构是: vm_area_struct, 内核将每个内存区域作为一个单独的内存对象管理,相应的操作也都一致。采用面向对象方法使VMA结构体可以代表多种类型的内存区域--比如内存映射文件或进程的用户空间栈等,对这些区域的操作也都不尽相同。

vm_area_strcut结构比较复杂,关于它的详细结构请参阅相关资料。我们这里只对它的组织方法做一点补充说明。vm_area_struct是描述进程地址空间的基本管理单元,对于一个进程来说往往需要多个内存区域来描述它的虚拟空间,如何关联这些不同的内存区域呢?大家可能都会想到使用链表,的确vm_area_struct结 构确实是以链表形式链接,不过为了方便查找,内核又以红黑树(以前的内核使用平衡树)的形式组织内存区域,以便降低搜索耗时。并存的两种组织形式,并非冗 余:链表用于需要遍历全部节点的时候用,而红黑树适用于在地址空间中定位特定内存区域的时候。内核为了内存区域上的各种不同操作都能获得高性能,所以同时 使用了这两种数据结构。

下图反映了进程地址空间的管理模型:

进程的地址空间对应的描述结构是“内存描述符结构,它表示进程的全部地址空间,——包含了和进程地址空间有关的全部信息,其中当然包含进程的内存区域。

进程内存的分配与回收

创建进程fork()、程序载入execve()、映射文件mmap()、动态内存分配malloc()/brk()等进程相关操作都需要分配内存给进程。不过这时进程申请和获得的还不是实际内存,而是虚拟内存,准确的说是“内存区域”。进程对内存区域的分配最终都会归结到do_mmap()函数上来(brk调用被单独以系统调用实现,不用do_mmap()),

内核使用do_mmap()函数创建一个新的线性地址区间。但是说该函数创建了一个新VMA并不非常准确,因为如果创建的地址区间和一个已经存在的地址区间相邻,并且它们具有相同的访问权限的话,那么两个区间将合并为一个。如果不能合并,那么就确实需要创建一个新的VMA了。但无论哪种情况, do_mmap()函数都会将一个地址区间加入到进程的地址空间中--无论是扩展已存在的内存区域还是创建一个新的区域。

同样,释放一个内存区域应使用函数do_ummap()它会销毁对应的内存区域。

如何由虚变实!

    从上面已经看到进程所能直接操作的地址都为虚拟地址。当进程需要内存时,从内核获得的仅仅是虚拟的内存区域,而不是实际的物理地址,进程并没有获得物理内存(物理页面——页的概念请大家参考硬件基础一章),获得的仅仅是对一个新的线性地址区间的使用权。实际的物理内存只有当进程真的去访问新获取的虚拟地址时,才会由“请求页机制”产生“缺页”异常,从而进入分配实际页面的例程。

该异常是虚拟内存机制赖以存在的基本保证——它会告诉内核去真正为进程分配物理页,并建立对应的页表,这之后虚拟地址才实实在在地映射到了系统的物理内存上。(当然,如果页被换出到磁盘,也会产生缺页异常,不过这时不用再建立页表了)

这种请求页机制把页面的分配推迟到不能再推迟为止,并不急于把所有的事情都一次做完(这种思想有点像设计模式中的代理模式(proxy))。之所以能这么做是利用了内存访问的“局部性原理”,请求页带来的好处是节约了空闲内存,提高了系统的吞吐率。要想更清楚地了解请求页机制,可以看看《深入理解linux内核》一书。

这里我们需要说明在内存区域结构上的nopage操作。当访问的进程虚拟内存并未真正分配页面时,该操作便被调用来分配实际的物理页,并为该页建立页表项。在最后的例子中我们会演示如何使用该方法。

 

 

系统物理内存管理 

虽 然应用程序操作的对象是映射到物理内存之上的虚拟内存,但是处理器直接操作的却是物理内存。所以当应用程序访问一个虚拟地址时,首先必须将虚拟地址转化成 物理地址,然后处理器才能解析地址访问请求。地址的转换工作需要通过查询页表才能完成,概括地讲,地址转换需要将虚拟地址分段,使每段虚地址都作为一个索 引指向页表,而页表项则指向下一级别的页表或者指向最终的物理页面。

每个进程都有自己的页表。进程描述符的pgd域指向的就是进程的页全局目录。下面我们借用《linux设备驱动程序》中的一幅图大致看看进程地址空间到物理页之间的转换关系。

 

 

     上面的过程说起来简单,做起来难呀。因为在虚拟地址映射到页之前必须先分配物理页——也就是说必须先从内核中获取空闲页,并建立页表。下面我们介绍一下内核管理物理内存的机制。

 

物理内存管理(页管理)

Linux内核管理物理内存是通过分页机制实现的,它将整个内存划分成无数个4k(i386体系结构中)大小的页,从而分配和回收内存的基本单位便是内存页了。利用分页管理有助于灵活分配内存地址,因为分配时不必要求必须有大块的连续内存[3],系统可以东一页、西一页的凑出所需要的内存供进程使用。虽然如此,但是实际上系统使用内存时还是倾向于分配连续的内存块,因为分配连续内存时,页表不需要更改,因此能降低TLB的刷新率(频繁刷新会在很大程度上降低访问速度)。

鉴于上述需求,内核分配物理页面时为了尽量减少不连续情况,采用了“伙伴”关系来管理空闲页面。伙伴关系分配算法大家应该不陌生——几乎所有操作系统方面的书都会提到,我们不去详细说它了,如果不明白可以参看有关资料。这里只需要大家明白Linux中空闲页面的组织和管理利用了伙伴关系,因此空闲页面分配时也需要遵循伙伴关系,最小单位只能是2的幂倍页面大小。内核中分配空闲页面的基本函数是get_free_page/get_free_pages,它们或是分配单页或是分配指定的页面(248…512页)。

 注意:get_free_page是在内核中分配内存,不同于malloc在用户空间中分配,malloc利用堆动态分配,实际上是调用brk()系统调用,该调用的作用是扩大或缩小进程堆空间(它会修改进程的brk域)。如果现有的内存区域不够容纳堆空间,则会以页面大小的倍数为单位,扩张或收缩对应的内存区域,但brk值并非以页面大小为倍数修改,而是按实际请求修改。因此Malloc在用户空间分配内存可以以字节为单位分配,但内核在内部仍然会是以页为单位分配的。

   另外,需要提及的是,物理页在系统中由页结构struct page描述,系统中所有的页面都存储在数组mem_map[]中,可以通过该数组找到系统中的每一页(空闲或非空闲)。而其中的空闲页面则可由上述提到的以伙伴关系组织的空闲页链表(free_area[MAX_ORDER]索引。

 

文本框: 伙伴关系维护

内核内存使用

Slab

    所 谓尺有所长,寸有所短。以页为最小单位分配内存对于内核管理系统中的物理内存来说的确比较方便,但内核自身最常使用的内存却往往是很小(远远小于一页)的 内存块——比如存放文件描述符、进程描述符、虚拟内存区域描述符等行为所需的内存都不足一页。这些用来存放描述符的内存相比页面而言,就好比是面包屑与面 包。一个整页中可以聚集多个这些小块内存;而且这些小块内存块也和面包屑一样频繁地生成/销毁。

  为了满足内核对这种小内存块的需要,Linux系统采用了一种被称为slab分配器的技术。Slab分配器的实现相当复杂,但原理不难,其核心思想就是“存储池[4]的运用。内存片段(小块内存)被看作对象,当被使用完后,并不直接释放而是被缓存到“存储池”里,留做下次使用,这无疑避免了频繁创建与销毁对象所带来的额外负载。

Slab技术不但避免了内存内部分片(下文将解释)带来的不便(引入Slab分配器的主要目的是为了减少对伙伴系统分配算法的调用次数——频繁分配和回收必然会导致内存碎片——难以找到大块连续的可用内存,而且可以很好地利用硬件缓存提高访问速度。

    Slab并非是脱离伙伴关系而独立存在的一种内存分配方式,slab仍然是建立在页面基础之上,换句话说,Slab将页面(来自于伙伴关系管理的空闲页面链表)撕碎成众多小内存块以供分配,slab中的对象分配和销毁使用kmem_cache_allockmem_cache_free

Kmalloc

Slab分配器不仅仅只用来存放内核专用的结构体,它还被用来处理内核对小块内存的请求。当然鉴于Slab分配器的特点,一般来说内核程序中对小于一页的小块内存的请求才通过Slab分配器提供的接口Kmalloc来完成(虽然它可分配32 131072字节的内存)。从内核内存分配的角度来讲,kmalloc可被看成是get_free_pages)的一个有效补充,内存分配粒度更灵活了。

有兴趣的话,可以到/proc/slabinfo中找到内核执行现场使用的各种slab信息统计,其中你会看到系统中所有slab的使用信息。从信息中可以看到系统中除了专用结构体使用的slab外,还存在大量为Kmalloc而准备的Slab(其中有些为dma准备的)。

 

 

内核非连续内存分配(Vmalloc

 

伙伴关系也好、slab技 术也好,从内存管理理论角度而言目的基本是一致的,它们都是为了防止“分片”,不过分片又分为外部分片和内部分片之说,所谓内部分片是说系统为了满足一小 段内存区(连续)的需要,不得不分配了一大区域连续内存给它,从而造成了空间浪费;外部分片是指系统虽有足够的内存,但却是分散的碎片,无法满足对大块“ 连续内存”的需求。无论何种分片都是系统有效利用内存的障碍。slab分 配器使得一个页面内包含的众多小块内存可独立被分配使用,避免了内部分片,节约了空闲内存。伙伴关系把内存块按大小分组管理,一定程度上减轻了外部分片的 危害,因为页框分配不在盲目,而是按照大小依次有序进行,不过伙伴关系只是减轻了外部分片,但并未彻底消除。你自己比划一下多次分配页面后,空闲内存的剩 余情况吧。

所以避免外部分片的最终思路还是落到了如何利用不连续的内存块组合成“看起来很大的内存块”——这里的情况很类似于用户空间分配虚拟内存,内存逻辑上连续,其实映射到并不一定连续的物理内存上。Linux内核借用了这个技术,允许内核程序在内核地址空间中分配虚拟地址,同样也利用页表(内核页表)将虚拟地址映射到分散的内存页上。以此完美地解决了内核内存使用中的外部分片问题。内核提供vmalloc函数分配内核虚拟内存,该函数不同于kmalloc,它可以分配较Kmalloc大得多的内存空间(可远大于128K,但必须是页大小的倍数),但相比Kmalloc来说,Vmalloc需要对内核虚拟地址进行重映射,必须更新内核页表,因此分配效率上要低一些(用空间换时间)

与用户进程相似,内核也有一个名为init_mmmm_strcut结构来描述内核地址空间,其中页表项pdg=swapper_pg_dir包含了系统内核空间(3G-4G)的映射关系。因此vmalloc分配内核虚拟地址必须更新内核页表,而kmallocget_free_page由于分配的连续内存,所以不需要更新内核页表。

文本框: 伙伴关系维护文本框: vmalloc文本框: Kmalloc

vmalloc分配的内核虚拟内存与kmalloc/get_free_page分配的内核虚拟内存位于不同的区间,不会重叠。因为内核虚拟空间被分区管理,各司其职。进程空间地址分布从0到3G(其实是到PAGE_OFFSET, 0×86中它等于0xC0000000),从3Gvmalloc_start这段地址是物理内存映射区域(该区域中包含了内核镜像、物理页面表mem_map等等)比如我使用的系统内存是64M(可以用free看到),那么(3G——3G+64M)这片内存就应该映射到物理内存,而vmalloc_start位置应在3G+64M附近(说"附近"因为是在物理内存映射区与vmalloc_start期间还会存在一个8M大小的gap来防止跃界),vmalloc_end的位置接近4G(说"接近"是因为最后位置系统会保留一片128k大小的区域用于专用页面映射,还有可能会有高端内存映射区,这些都是细节,这里我们不做纠缠)

 

 

上图是内存分布的模糊轮廓

 

   get_free_pageKmalloc函数所分配的连续内存都陷于物理映射区域,所以它们返回的内核虚拟地址和实际物理地址仅仅是相差一个偏移量(PAGE_OFFSET),你可以很方便的将其转化为物理内存地址,同时内核也提供了virt_to_phys()函数将内核虚拟空间中的物理映射区地址转化为物理地址。要知道,物理内存映射区中的地址与内核页表是有序对应的,系统中的每个物理页面都可以找到它对应的内核虚拟地址(在物理内存映射区中的)。

vmalloc分配的地址则限于vmalloc_startvmalloc_end之间。每一块vmalloc分配的内核虚拟内存都对应一个vm_struct结构体(可别和vm_area_struct搞混,那可是进程虚拟内存区域的结构),不同的内核虚拟地址被4k大小的空闲区间隔,以防止越界——见下图)。与进程虚拟地址的特性一样,这些虚拟地址与物理内存没有简单的位移关系,必须通过内核页表才可转换为物理地址或物理页。它们有可能尚未被映射,在发生缺页时才真正分配物理页面。

 

这里给出一个小程序帮助大家认清上面几种分配函数所对应的区域。

#include<linux/module.h>

#include<linux/slab.h>

#include<linux/vmalloc.h>

unsigned char *pagemem;

unsigned char *kmallocmem;

unsigned char *vmallocmem;

int init_module(void)

{

 pagemem = get_free_page(0);

 printk("<1>pagemem=%s",pagemem);

 kmallocmem = kmalloc(100,0);

 printk("<1>kmallocmem=%s",kmallocmem);

 vmallocmem = vmalloc(1000000);

 printk("<1>vmallocmem=%s",vmallocmem);

}

void cleanup_module(void)

{

 free_page(pagemem);

 kfree(kmallocmem);

 vfree(vmallocmem);

}

 

实例

内存映射(mmap)Linux操作系统的一个很大特色,它可以将系统内存映射到一个文件(设备)上,以便可以通过访问文件内容来达到访问内存的目的。这样做的最大好处是提高了内存访问速度,并且可以利用文件系统的接口编程(设备在Linux中 作为特殊文件处理)访问内存,降低了开发难度。许多设备驱动程序便是利用内存映射功能将用户空间的一段地址关联到设备内存上,无论何时,只要内存在分配的 地址范围内进行读写,实际上就是对设备内存的访问。同时对设备文件的访问也等同于对内存区域的访问,也就是说,通过文件操作接口可以访问内存。Linux中的X服务器就是一个利用内存映射达到直接高速访问视频卡内存的例子。

熟悉文件操作的朋友一定会知道file_operations结构中有mmap方法,在用户执行mmap系统调用时,便会调用该方法来通过文件访问内存——不过在调用文件系统mmap方法前,内核还需要处理分配内存区域(vma_struct)、建立页表等工作。对于具体映射细节不作介绍了,需要强调的是,建立页表可以采用remap_page_range方法一次建立起所有映射区的页表,或利用vma_structnopage方法在缺页时现场一页一页的建立页表。第一种方法相比第二种方法简单方便、速度快, 但是灵活性不高。一次调用所有页表便定型了,不适用于那些需要现场建立页表的场合——比如映射区需要扩展或下面我们例子中的情况。

 

我们这里的实例希望利用内存映射,将系统内核中的一部分虚拟内存映射到用户空间,以供应用程序读取——你可利用它进行内核空间到用户空间的大规模信息传输。因此我们将试图写一个虚拟字符设备驱动程序,通过它将系统内核空间映射到用户空间——将内核虚拟内存映射到用户虚拟地址。从上一节已经看到Linux内核空间中包含两种虚拟地址:一种是物理和逻辑都连续的物理内存映射虚拟地址;另一种是逻辑连续但非物理连续的vmalloc分配的内存虚拟地址。我们的例子程序将演示把vmalloc分配的内核虚拟地址映射到用户地址空间的全过程。

程序里主要应解决两个问题:

第一是如何将vmalloc分配的内核虚拟内存正确地转化成物理地址?

因为内存映射先要获得被映射的物理地址,然后才能将其映射到要求的用户虚拟地址上。我们已经看到内核物理内存映射区域中的地址可以被内核函数virt_to_phys转换成实际的物理内存地址,但对于vmalloc分配的内核虚拟地址无法直接转化成物理地址,所以我们必须对这部分虚拟内存格外“照顾”——先将其转化成内核物理内存映射区域中的地址,然后在用virt_to_phys变为物理地址。

转化工作需要进行如下步骤:

a)         找到vmalloc虚拟内存对应的页表,并寻找到对应的页表项。

b)        获取页表项对应的页面指针

c)        通过页面得到对应的内核物理内存映射区域地址

如下图所示:

第二是当访问vmalloc分配区时,如果发现虚拟内存尚未被映射到物理页,则需要处理“缺页异常”。因此需要我们实现内存区域中的nopaga操作,以能返回被映射的物理页面指针,在我们的实例中就是返回上面过程中的内核物理内存映射区域中的地址由于vmalloc分配的虚拟地址与物理地址的对应关系并非分配时就可确定,必须在缺页现场建立页表,因此这里不能使用remap_page_range方法,只能用vmanopage方法一页一页的建立。

 

 

程序组成

map_driver.c,它是以模块形式加载的虚拟字符驱动程序。该驱动负责将一定长的内核虚拟地址(vmalloc分配的)映射到设备文件上。其中主要的函数有——vaddress_to_kaddress()负责对vmalloc分配的地址进行页表解析,以找到对应的内核物理映射地址(kmalloc分配的地址);map_nopage()负责在进程访问一个当前并不存在的VMA页时,寻找该地址对应的物理页,并返回该页的指针。

test.c 它利用上述驱动模块对应的设备文件在用户空间读取读取内核内存。结果可以看到内核虚拟地址的内容(ok!),被显示在了屏幕上。

 

执行步骤

编译map_driver.cmap_driver.o模块,具体参数见Makefile

加载模块 insmod map_driver.o

生成对应的设备文件

1 /proc/devices下找到map_driver对应的设备命和设备号:grep mapdrv /proc/devices

2 建立设备文件mknod  mapfile c 254 0  (在我的系统里设备号为254

    利用maptest读取mapfile文件,将取自内核的信息打印到屏幕上。

 

全部程序下载 mmap.tar (感谢Martin Frey,该程序的主体出自他的灵感)

 

(ZT)将32位代码向64位平台移植的注意事项

Posted by Ryan @ 10:14 am, 10月 24th, 2009

        新近的64位平台在二进制上与32位应用程序兼容,这意味着可以非常简单地移植现有的程序。许多目前在32位平台上运行良好的程序也许不必移植,除非程序有以下要求:
·需要多于4GB的内存。
·使用的文件大小常大于2GB。
·密集浮点运算,需要利用64位架构的优势。
·能从64位平台的优化数学库中受益。
否则,只需简单地重新编译一下,就已经足够了。大多数编写良好的程序不费吹灰之力就可移植到64位平台之上,在此假定你的程序编写良好,并熟悉本文将要讨论的问题。
ILP32和LP64数据模型
32位环境涉及"ILP32"数据模型,是因为C数据类型为32位的int、long、指针。而64位环境使用不同的数据模型,此时的long和指针已为64位,故称作"LP64"数据模型。
现今所有64位的类Unix平台均使用LP64数据模型,而64位Windows使用LLP64数据模型,除了指针是64位,其他基本类型都没有变。我们在此主要探讨ILP32到LP64的移植问题,表1显示了ILP32与LP64数据模型的差异。
向 64位移植代码时的所有问题差不多都可以总结出一个简单的规律:千万不要认为int、long、指针的长度一样。任何违反这条规律的代码,当运行在 LP64数据模型下时,都会出现不同的问题,而且很难找出原因所在。例1中有许多违反这条规律的地方,其在移植到64位平台上时都需要重写。
例1:

1 int *myfunc(int i)
2 {
3  return(&i);
4 }
5
6 int main(void)
7 {
8  int myint;
9  long mylong;
10 int *myptr;
11
12  char *name = (char * ) getlogin();
13
14  printf("Enter a number %s: ", name);
15  (void) scanf("%d", &mylong);
16  myint = mylong;
17  myptr = myfunc(mylong);
18  printf("mylong: %d pointer: %x \n", mylong, myptr);
19  myint = (int)mylong;
20  exit(0);
21
22 }


第 一步是要求编译器捕捉到移植时的问题,因所用编译器的不同,选项可能也有所不同,但对IBM XL编译器系列,可用的选项有-qwarn64 -qinfo=pro,为了得到64位可执行文件,可使用选项-q64(如果使用GCC,选项应为-m64,表2中列出了其他可用的GCC选项)。图1是 编译例1中代码时的情况。

将32位代码向64位平台移植的注意事项
编译例1中代码时的情况

缺少原型的截断
如果一个函数被调用时没有指定函数原型,返回值将是32位的int。不使用原型的代码可能会发生意料之外的数据截断,由此导致一个分割错误。编译器捕捉到了例1中第12行的这个错误。
char *name = (char *) getlogin();
编译器假定函数返回一个int值,并截短结果指针。这行代码在ILP32数据模型下工作正常,因为此时的int和指针是同样长度,换到LP64模型中,就不一定正确了,甚至于类型转换都不能避免这个错误,因为getlogin()在返回之后已经被截断了。
要修正这个问题,需包括头文件<unistd.h>,其中有getlogin()的函数原型。
格式指定符
如果对64位long、指针使用了32位格式指定符,将导致程序错误。编译器捕捉到了例1中第15行的这个错误。
(void) scanf("%d", &mylong);
注意,scanf将向变量mylong中插入一个32位的值,而剩下的4字节就不管了。要修正这个问题,请在scanf中使用%ld指定符。
第18行也演示了在printf中的一个类似的问题:
printf("mylong: %d pointer: %x \n", mylong, myptr);
要修正此处的错误,mylong应使用%ld,对myptr使用 %p而不是%x。
赋值截断
有关编译器发现赋值截断的一个例子在第16行中:
myint = mylong;
这在ILP32模型下不会有任何问题,因为此时的int、long都是32位,而在LP64中,当把mylong赋值给myint时,如果数值大于32位整数的最大值时,数值将被截短。
被截断的参数
编译器发现的下一个错误在第17行中,虽然myfunc函数只接受一个int参数,但调用时却用了一个long,参数在传递时会悄无声息地被截断。
转换截断
转换截断发生在把long转换成int时,比如说例1中的第19行:

myint = (int) mylong;

导致转换截断的原因是int与long非同样长度。这些类型的转换通常在代码中以如下形式出现:

int length = (int) strlen(str);

strlen返 回size_t(它在LP64中是unsigned long),当赋值给一个int时,截断是必然发生的。而通常,截断只会在str的长度大于2GB时才会发生,这种情况在程序中一般不会出现。虽然如此, 也应该尽量使用适当的多态类型(如size_t、uintptr_t等等),而不要去管它最下面的基类型是什么。
一些其他的细小问题
编译器可捕捉到移植方面的各种问题,但不能总指望编译器为你找出一切错误。
那些以十六进制或二进制表示的常量,通常都是32位的。例如,无符号32位常量0xFFFFFFFF通常用来测试是否为-1:

#define INVALID_POINTER_VALUE 0xFFFFFFFF

然而,在64位系统中,这个值不是-1,而是4294967295;在64位系统中,-1正确的值应为0xFFFFFFFFFFFFFFFF。要避免这个问题,在声明常量时,使用const,并且带上signed或unsigned。

const signed int INVALID_POINTER_VALUE = 0xFFFFFFFF;

这行代码将会在32位和64位系统上都运行正常。
其他有关于对常量硬编码的问题,都是基于对ILP32数据模型的不当认识,如下:

int **p; p = (int**)malloc(4 * NO_ELEMENTS);

这行代码假定指针的长度为4字节,而这在LP64中是不正确的,此时是8字节。正确的方法应使用sizeof():

int **p; p = (int**)malloc( sizeof(*p) * NO_ELEMENTS);

注意对sizeof()的不正确用法,例如:

sizeof(int) = = sizeof(int *);

这在LP64中是错误的。
符号扩展
要避免有符号数与无符号数的算术运算。在把int与long数值作对比时,此时产生的数据提升在LP64和ILP32中是有差异的。因为是符号位扩展,所以这个问题很难被发现,只有保证两端的操作数均为signed或均为unsigned,才能从根本上防止此问题的发生。
例2:

long k;
int i = -2;
unsigned int j = 1;
k = i + j;
printf("Answer: %ld\n", k);

你 无法期望例2中的答案是-1,然而,当你在LP64环境中编译此程序时,答案会是4294967295。原因在于表达式(i+j)是一个 unsigned int表达式,但把它赋值给k时,符号位没有被扩展。要解决这个问题,两端的操作数只要均为signed或均为unsigned就可。像如下所示:

k = i + (int) j

联合体问题(Union)
当联合本中混有不同长度的数据类型时,可能会导致问题。如例3是一个常见的开源代码包,可在ILP32却不可在LP64环境下运行。代码假定长度为2的unsigned short数组,占用了与long同样的空间,可这在LP64平台上却不正确。
例3:

typedef struct {
 unsigned short bom;
 unsigned short cnt;
 union {
unsigned long bytes;
unsigned short len[2];
 } size;
} _ucheader_t;


要在LP64上运行,代码中的unsigned long应改为unsigned int。要在所有代码中仔细检查联合体,以确认所有的数据成员在LP64中都为同等长度。
字节序问题(Endian)
因 64位平台的差异,在移植32位程序时,可能会失败,原因可归咎于机器上字节序的不同。Intel、IBM PC等CISC芯片使用的是Little-endian,而Apple之类的RISC芯片使用的是Big-endian;小尾字节序(Little- endian)通常会隐藏移植过程中的截断bug。
例4:

long k;
int *ptr;
int main(void)
{
 k = 2 ;
 ptr = &k;
 printf("k has the value %ld, value pointed to by ptr is %ld\n", k, *ptr);
 return 0;
}


例4是一个有此问题的明显例子,一个声明指向int的指针,却不经意间指向了 long。在ILP32上,这段代码打印出2,因为int与long长度一样。但到了LP64上,因为int与long的长度不一,而导致指针被截断。不 管怎么说,在小尾字节序的系统中,代码依旧会给出k的正确答案2,但在大尾字节序(Big-endian)系统中,k的值却是0。

将32位代码向64位平台移植的注意事项(3)
找出64位移植问题的可用的GCC鄙夷选项

表3说明了为什么在不同的字节序系统中,会因截断问题而产生不同的答案。在小尾字节序 中,被截断的高位地址中全为0,所以答案仍为2;而在大尾字节序中,被截断的高位地址中包含值2,这样就导致结果为0,所以在两种情况下,截断都是一种 bug。但要意识到,小尾字节序会隐藏小数值的截断错误,而这个错误只有在移植到大尾字节序系统上时才可能被发现。

移植到64位平台之后的性能降低
当代码移植到64位平台之后,也许发现性能实际上降低了。原因与在LP64中的指针长度和数据大小有关,并由此引发的缓存命中率降低、数据结构膨胀、数据对齐等问题。
由于64位环境中指针所占用的字节更大,致使原来运行良好的32位代码出现不同程度的缓存问题,具体表现为执行效率降低。可使用工具来分析缓存命中率的变化,以确认性能降低是否由此引起。
在 迁移到LP64之后,数据结构的大小可能会改变,此时程序可能会需要更多的内存和磁盘空间。例如,图2中的结构在ILP32中只需要16字节,但在 LP64中,却需要32字节,整整增长了100%。这缘于此时的long已是64位,编译器为了对齐需要而加入了额外的填充数据。
通过改变结构中数据排列的先后顺序,能将此问题所带来的影响降到最小,并能减少所需的存储空间。如果把两个32位int值放在一起,会因为少了填充数据,存储空间也随之减少,现在存储整个结构只需要24字节。
在重排数据结构之前,在根据数据使用的频度仔细衡量,以免因降低缓存命中率而带来性能上的损失。
如何生成64位代码
在 一些情况中,32位和64位程序在源代码级别的接口上很难区分。不少头文件中,都是通过一些测试宏来区分它们,不幸的是,这些特定的宏依赖于特定的平台、 特定的编译器或特定的编译器版本。举例来说,GCC 3.4或之后的版本都定义了__LP64__,以便为所有的64位平台通过选项-m64编译产生64位代码。然而,GCC 3.4之前的版本却是特定于平台和操作系统的。
也许你的编译器使用了不同于 __LP64__的宏,例如IBM XL的编译器当用-q64编译程序时,使用了__64bit__宏,而另一些平台使用_LP64,具体情况可用__WORDSIZE来测试一下。请查看相 关编译器文档,以便找出最适合的宏。例5可适用于多种平台和编译器:
例5:

#if defined (__LP64__) || defined (__64BIT__) || defined (_LP64) || (__WORDSIZE == 64)
printf("I am LP64\n");
#else
printf("I am ILP32 \n");
#endif

共享数据
在移植到64位平台时的一个典型问题是,如何在32位和64位程序之间读取和共享数据。例如一个32位程序可能把结构体作为二进制文件存储在磁盘上,现在你要在64位代码中读取这些文件,很可能会因LP64环境中结构大小的不同而导致问题。
对 那些必须同时运行在32位和64位平台上的新程序而言,建议不要使用可能会因LP64和ILP32而改变长度的数据类型(如long),如果实在要用,可 使用头文件<inttypes.h>中的定宽整数,这样不管是通过文件还是网络,都可在32位和64位的二进制层面共享数据。
例6:

#include <stdio.h>
#include <inttypes.h>
struct on_disk
{
 /* ILP32|LP64共享时,这个应该使用int32_t */
 long foo;
};
int main()
{
 FILE *file;
 struct on_disk data;
 #ifdef WRITE
file=fopen("test","w");
data.foo = 65535;
fwrite(&data, sizeof(struct on_disk), 1, file);
 #else
file = fopen("test","r");
fread(&data, sizeof(struct on_disk), 1, file);
printf("data: %ld\n", data.foo);
 #endif
 fclose(file);
}

来 看一下例6,在理想的情况下,这个程序在32位和64位平台上都可正常运行,并且可以读取对方的数据。但实际上却不行,因为long在ILP32和 LP64之中长度会变化。结构on_disk里的变量foo应该声明为int32_t,这个定宽类型可保证在当前ILP32或移植到的LP64数据模型 下,都生成相同大小的数据。
混合Fortran和C的问题
许多科学运算程序从C/C++中调用 Fortran的功能,Fortran从它本身来说并不存在移植到64位平台的问题,因为Fortran的数据类型有明确的比特大小。然而,如果混合 Fortran和C语言,问题就来了,如下:例7中C语言程序调用例8中Fortran语言的子例程。
例7:

void FOO(long *l);
main ()
{
 long l = 5000;
 FOO(&l);
}

例8:

subroutine foo( i )
integer i
write(*,*) ‘In Fortran’
write(*,*) i
return
end subroutine foo

例9:

% gcc -m64 -c cfoo.c
% /opt/absoft/bin/f90 -m64 cfoo.o foo.f90 -o out
% ./out
In Fortran
0

当 链接这两个文件后,程序将打印出变量i的值为"5000"。而在LP64中,程序打印出"0",因为在LP64模式下,子例程foo通过地址传递一个 64位的参数,而实际上,Fortran子例程想要的是一个32位的参数。如果要改正这个错误,在声明Fortran子例程变量i时,把它声明为 INTEGER*8,此时和C语言中的long为一样长度。
结论
64位平台是解决大型复杂科学及商业问题的希望,大多数编写良好的程序可轻松地移植到新平台上,但要注意ILP32和LP64数据模型的差异,以保证有一个平滑的移植过程。