从32位平台移植到64位平台的解决方案报告书

《从32位平台移植到64位平台的解决方案报告书》由会员分享，可在线阅读，更多相关《从32位平台移植到64位平台的解决方案报告书（15页珍藏版）》请在装配图网上搜索。

1、 从32位平台移植到64位平台的解决方案一、 概述1. 移植的原因由于高性能效劳器、数据库管理系统、电脑辅助设计工具，以及数字内容创作工具等应用方案均需要处理大量数据及占用存储器大量地址，因此为了满足这类应用方案的需要，64位技术便应运而生。大约从九十年代后期起,就已经有64位机器问世,从去年到今年,Intel体系构造的芯片也开场出64位了.在UNIX环境下,已有几种操作系统支持64位环境了,据说微软也准备将Windows升级为64位操作系统。可以预料,将来32位平台将不再是主流,唱主角的将是64位平台。到时,客户环境也将全是64位平台。因此,由于下面这样一些原因,使得某些应用程序从32位移植

2、到64位:(1).工程、科学、商业-需要地址空间大于32位.大数据集:需处理的数据大于32位所能处理的极限;(大文件或数据库的内存映射是一种常用技术-通过把文件或数据库保存在内存,以防止经常的磁盘I/O操作.).计算需要1. 程序复杂性;假设是32位系统,32位程序,那么虽然也能处理需大地址空间的应用,但程序将变得复杂;2. 应用程序的吞吐量;SMP系统与并行编程不断用来处理科学计算与其他问题;这意味着,在32位系统上,多至12个高速处理器共享不超过4GB的内存;64位系统那么能为每个进程提供必要的内存与I/O资源,使得SMP能很好地进展扩展,并能提供科学,工程,商业领域所需的批量计算;3.

3、典型的64位应用-决策支持、数据仓库、数据挖掘、基于因特网的应用、电子商务应用、Web效劳器、多媒体效劳器、数字密集的应用、一般数据库、大阵列操作应用.(2). 现存32位系统-资源短缺限制了总体性能与吞吐量的提高现存32位多用户系统性能不是受限于CPU,而是受限于I/O带宽;而由分页引起的I/O又主要是由于内存缺乏于存储整个文件;如果有足够的内存可用,那么将显著减少分页,从而显著地改善系统性能.高压力环境下的32位应用程序:基于因特网的应用、电子商务应用、Web效劳器、多媒体效劳器、一般效劳器、实时系统.(这些应用可从OS提供的大内存获得性能提高,因为OS会自动地为每个32位应用提供更多的内

4、存与I/O资源.因此,64位系统能运行更多的并发的,大的32位应用程序.2. 移植原那么i. 移植后的程序既可作为64位机器上的32位程序运行,又可作为64位机器上的64位程序运行;只要觉得有需要,就可将32位程序重编译为64位程序;ii. 在64位平台上,不管是作为32位程序还是作为64位程序运行,其性能至少不应比32位程序在32位平台上运行的性能差;iii. 32位进程与64位进程可同时在64位平台上运行.3. 移植步骤将现有32位程序移植到64位时,由于AIX V4.3本身对32位程序与64位程序的支持,所以绝大局部的系统调用与C语言程序构造都不用改变,只要在源程序中遵守系统调用接口与相

5、应的数据类型;但是,还是有一些由于数据类型长度的改变而引起的兼容性问题.因此从32位程序移植为64位程序一般必须经过以下步骤:(1).源程序的兼容性检查;这一步主要检查由于数据类型长度改变而引起的兼容性问题;(2).将从第(1)步检查出的兼容性源程序进展修改;(3).修改makefile文件;二、 32位平台与64位平台1. 平台的定义计算机系统是由硬件与软件两局部组成的。所谓平台也就是指硬件与相应的系统软件(包括操作系统、编译器和与开发环境有关的应用程序(如数据库)。64位硬件体系构造是指:(1).能处理64位数据.-即CPU可以将64位数据作为根本单元进展处理(只需一次操作就可处理),字长

6、是64位的，即存储单元是64位的.(说明:32位平台的存储单元是32位的)这导致构造成员的一种以8字节为边界的填充,即第一个成员即使缺乏一个8字节的根本存储单元,那么仍占用一个根本存储单元,而整个构造占用的存储空间也是8字节的倍数.(2).能产生64位地址.-包括有效地址和物理地址.注意:虚地址概念并不是由处理器体系构造说明的,它是由AIX的VMM(虚地址存储管理器)说明的.它规定了应用程序可访问的内存空间的大小.一般来说,虚地址可以与有效地址或物理地址不同.相应地,32位硬件体系构造是指(1).能将32位数据作为根本数据单元进展处理;(2).最多只能产生32位地址(包括有效地址和物理地址).

7、以下操作可从64位存放器中得到好处:(1).64位长的串;(2).64位存放器上的移位操作;(3).64位的整数和指针运算;(4).串或大数据的拷贝.硬件局部主要是指其字长-CPU能作为根本数据单元处理的二进制数据的位数。如32位机器其CPU能在一条指令内处理32位数据,它不能在一条指令内处理64位数据,它必须将64位数据分为两个32位数据进展处理;而64位机器其CPU那么能在一条指令内处理64位数据,它不需象32位机器一样,将64位数据拆分为两个32位数据进展处理。32位平台是指其硬件体系构造是32位的,而且其操作系统、编译器等系统软件也只能支持32位程序.64位平台是指其硬件体系构造是64

8、位的,而且其操作系统、编译器等也能支持64位程序.因而,64位平台能充分利用其64位硬件的性能,使得一些应用程序能从中得到性能的改善.2. 现有AIX64位平台的特点i. RS/6000 64位机器 AIX V4.3 和RS/6000 S70模型)RS/6000(RS64A)是64位体系构造,CPU的通用存放器是64位的,一些控制存放器也是64位的,它可以一次移动或操作64位数据,而不需要象在32位处理器那样,必须由程序员或编译器分两次完成.PowerPC是64位体系构造.64位环境是32位环境的超集;-即64位指令集是32位指令集的超集,换句话说,32位指令集是64位指令集的子集;.32位环

9、境与64位环境是局部的;-即一个32位进程其环境只对这个进程有效,一个64位进程的环境只对这个64位进程有效;同时运行的32位进程与64位进程可有不同的运行环境;.不管哪种方式,都无任何模拟或仿真.-即32位进程执行32位指令集,64位进程执行64位指令集;而不是说,64位指令集是通过32位指令集来模拟或仿真;AIX V4.3 64位体系构造的好处(1) 64位数据类型 某些应用程序可从64位整型硬件的性能和更高的精度获益;不过主要的可能还是由非64位应用程序用64位整型运算操纵64位指针.(2) 存取大文件-数据仓库、科学和多媒体应用经常需要非常大的文件和文件系统,它们很容易由64位数据类型

10、处理;巨大的地址空间-有些应用程序既需要用大内存(234=16GB),也需要访问海量虚拟存储(280),许多科学应用就可以简单地编程,并能比拟高效地执行.数据段和堆栈都是巨大的,存储映射也会得到显著改善.ii.AIX V4.3支持64位程序的操作系统提升了4GB的系统内存限制.4GB(232)是对32位PowerPC平台的限制;.AIX V4.3支持4GB的内存;.AIX V4.3在RS/6000 S70效劳器上支持16GB内存;.当内存足够时,AIX 会自动扩展至大内存;.32位程序仍受限于4GB的内存;.64位程序可存取260B的内存.应用程序地址空间可大于4GB.在S70且安装AIX V

11、4.3的系统上被编译为64位的程序;.对超出32位寻址X围的应用程序.不必为担忧性能而重新编译.在64位平台上,将32位程序重新编译为32位时,其性能会无任何差异,因为这会任何编译器的改良;.32位重新编译为64位时,会看到些微的性能差异;.默认编译模式是产生32位可执行程序.AIX V4.3核心是32位,在64位平台上有附加的64位扩展;.为支持完全64位功能,核心不一定要求是64位的;.32位核心维持对32位的兼容性和强健性;.核心扩展提供了64位程序所要求的功能;.新的应用程序二进制接口(ABI);.提供了对设备驱动程序的二进制兼容性;.VMM支持64位进程地址空间;.只要有必要,某些系

12、统调用可修改为64位参数(如文件和内存操作);.对某些设备驱动程序有一些前提或限制.32位与64位进程的完全互操作性1. 进程-进程.可共享文件.内存,IPC资源(但要注意某些共享内存的分配方式-字节边界问题),也可相互发信号;.可相互exec()调用;.32位与64位进程可设置非本类进程的限制;2. 32位与64位系统构造.编译器仍是32位的;.编译器既可在32位平台,也可在64位平台上运行;.既可产生32位,也可产生64位可执行文件.头文件已被修改正,以支持两种环境;.增强了功能的共享库的体系构造.两种环境下都用同样的路径;.只维护单一的源程序,makefile文件,.管理共享库的工具默认

13、为32位的.32位与64位核心支持.AIX V4.3既支持32位的虚地址空间又支持64位的虚地址空间;.包含VMM与进程调度和其他功能;.32位进程与64位进程对系统设备都有同等访问权利;.默认行为都是32位兼容的;.进程调用设备驱动程序一般被核心分隔.能在32位机器上运行64位程序吗?.显然不能;.不过,在32位机器上编译与64位程序是可能的(假设相关的库等等已安装).AIX 命令与工具.绝大多数AIX命令与工具仍是32位的;.需支持64位的绝大多数工具也仍是32位的;.所有命令与工具将继续支持32位;.编译器与连接程序支持64位的(注意:这并不意味着二者是64位的).ii. 原有32程序与

14、新的64位程序的二进制兼容性原有32位程序可不用重编译,即可在AIX V4.3中继续作为32位程序运行.(1).在AIX V4.3中,32位程序完全的二进制兼容性;.现存32位程序毋须修改或重新编译,就可在64位平台上运行;.32位模式下,百分之百的兼容性;即在64平台上编译的32位程序与32位平台上编译的32位程序都可在64位平台上共存运行;.32位程序无任何性能下降,即32位程序不管是在32位平台上运行,还是在64位平台上运行,其性能无可分辨的差异.(2). 64位与32位的共存.AIX V4.3在64位平台中提供两种应用环境;这两种应用环境是互补而非竟争的环境;64位环境是向上兼容的AI

15、X的附加,比AIX V4.3低的版本不支持64位程序;并不强迫所有应用都是64位的.仅仅只有一种AIX产品既适应于32位平台,又适应于64位平台;32位与64位进程的完全共存,在64位平台上既可运行32位进程,又可运行64位进程,两种进程各有自己的运行环境;3. 64位编程i. 标准有关64位编程有两个标准,UNIX98标准与LP64协议.前者说明UNIX系统调用与C标准库函数的标准接口,各库函数接口并不隐含数据类型是32位的,而是依协议IPL32确定其类型;后者说明64位编程C语言类型.1. 数据类型标准LP64类型从上表可看出:LP64模式中,char,short,int这三种数据类型与3

16、2位程序相应的数据类型完全一样;而long型与指针那么变成64位,相应地在32位程序中,long 与指针是32位的.LP64是一个一般的64位程序数据类型标准;不过,AIX用的是IPL32+long long int;见下表:Table 6. ILP32, LP64 and C for AIX piler Model Type SizeDatatypeILP32 (size in bit)LP64 (size in bit)C for AIX (32-bit / 64-bit)char 8 8 Implementedshort 1616Implementedint 3232 Implement

17、edlong32 64 Implementedlong long Not DefinedNot Defined64 / 64pointer 3264Implementedfloat32 32 Implementeddouble 6464 Implementedlong double Not Defined Not Defined64 or 128 / 64 or 128 (1)int8_tuint8_tNot DefinedNot DefinedFixed-width type (2)8 bits (1 byte)int16_tuint16_tNot DefinedNot DefinedFix

18、ed-width type (2)16 bits (2 bytes)int32_tuint32_tNot Defined Not Defined Fixed-width type (2)32 bits (4 bytes)int64_tuint64_tNot DefinedNot DefinedFixed-width type (2)64 bits (8 bytes)_int8_uint8Not DefinedNot DefinedFixed-width type (3)1 byte_int16_uint16Not DefinedNot DefinedFixed-width type (3)2

19、bytes_int32_uint32Not DefinedNot DefinedFixed-width type (3)4 bytes_int64_unit64Not DefinedNot Defined Fixed-width type (3)8 bytes(1) Depend on the setting of the long double option. By default, the size is 8.(2) ANSI fixed-size types.(3) Should not be used; use ANSI types instead.说明:其中粗体局部说明在32位与64

20、位程序中长度有异,AIX为使其C+与Microsoft兼容,使用了_int8/16/32/64数据类型,在UNIX环境下一般应使用ANXI C数据类型,这包括在头文件中.很明显,64位程序与32位程序最大的不同就是:long与指针两种数据类型的长度不同,当然那些由long间接定义的数据类型其长度也跟着不同.在32位程序中,int ,long ,pointer三种数据类型的长度是一样的;三者相互赋值不会有影响;但在64位程序中,int长度只有4B,而long,pointer长度却有8B,而且有些由long typedef的数据类型也是8B,从而在int 与long或pointer之间赋值就会导致

21、错误,特别是有些由long typedef的数据类型常常用作函数参数,如果相应参数在程序中被定义为int,无疑会导致兼容性问题.2.构造分配问题我们知道,在32位程序中,构造数据有一种字边界填充的定位问题:即一个构造的第一个成员一定位于字边界上,即使该成员实际占用空间并不需要一个字长的存储空间,也会分配一个字长的存储空间,剩余空间由编译器填充;并且整个构造所占空间也应位于字长边界上;如struct struc32int I;long j;char c;这个构造长度是12B,即sizeof(struc32)=12;其最后一个成员虽只有一个字节,但也分配4个字节;同样地,在64位程序中,也存在构造

22、填充问题;只不过不是以字为边界,而是以双字为边界;如struct struc64int I;long j;char *p;在32位程序中,这个构造的长度是12B,在64位程序中,其长度是24B;第一个成员只占4B,但编译器也给它分配8B空间.值得注意的是:在64位程序下,某些构造只成员一样,但成员位置不同时,其长度也会不同;如struct lilong la;int ia; li;struct liilong la;int ia;int ib; lii;struct iliint ia;long la;int ib; ili;注意ili与lii两个构造变量:在64位程序中,sizeof(str

23、uct lii)=16;sizeof(struct ili)=24;在64位程序中,对构造成员的恰当排列,有可能减少程序所占空间.ii. OBJ文件格式1.定义 在32位程序中,经过编译器编译生成的.o文件,一般是COFF格式(mon Object Format File),但AIX V4.3为支持64位程序,其.o文件格式为XCOFF(extended mon Object Format File);它组合了COFF格式与模块格式内容表(TOC)两局部;后者提供了.o文件的动态连接与单元代替.XCOFF文件格式的主要优点就是它能提供对共享库和其他外部.o文件的动态解析引用.而一般地,COFF

24、格式文件只能静态引用.XCOFF格式文件定义了.o文件与可执行文件的机器内存映象的排列方式,它是由语言处理器(ASM与编译器)生成的,绑定器将单个的.o文件组装形成可执行文件,装载程序将XCOFF格式的可执行文件读进内存,形成程序的内存映象,符号调试器读这个XCOFF的可执行文件,以提供程序内存映象中的变量与函数的符号引用.这种文件格式只能由AIX V4.3及以上版本才能生成及装载;当在64位模式下编译时,编译器生成64位指令并产生64位XCOFF格式.o文件,此时绑定器只绑定64位.o文件以生成64位可执行文件.注意,在绑定到一起的.o文件中,不管是静态绑定还是动态绑定,都只能是同一格式的.

25、o文件,即32位的.o文件与64位的.o文件的混合绑定是不允许的.(所谓64位模式,是指生成64位指令,产生64位XCOFF格式文件)AIX将XCOFF作为32位与64位程序的.o文件格式,从而有XCOFF32与XCOFF64之分,在RS/6000 32位平台或64位平台上,AIX的编译器默认为32位模式,即经编译所得的目标文件是32位的;不过,AIX的cc编译器在调用连接程序ld生成可执行程序时,ld将只是把同类的.o文件(包括库文件)连接成可执行程序,即要么是XCOFF32格式的.o文件,要么是XCOFF64格式的.o文件.AIX的cc的这个特性要求:如果库是XCOFF32格式的文件,那么

26、所有用到这个库的可执行程序就只能编译为32位的;如果共享库的某个可执行程序要编译为64位的,那么与这个共享库有关的所有可执行程序都要编译为64位的;不允许共享库某个32位库的可执行程序编译为32位的,而另一个共享该库的可执行程序却编译为64位的.不过,在AIX V4.3中,有少数几个命令既支持32位XCOFF格式同时又支持64位XCOFF格式(即混合模式),这些命令有ar,dump,.nm,lorder,ranlib,size,strip.它们都用-X标志(-X32,-X64,-X32_64)来说明.o文件格式.ar支持两种x(X)标志.-x表示从档案库中抽出所指定的文件并放到当前目录;而-X

27、标志那么指定iii. 编译1.cc编译 一般来说,AIXAIX编译器cc有许多编译选项,这里只简单介绍一些与64位有关的编译选项.(1).-q64选项:有这个编译开关时,所编译生成的.o或可执行程序将是64位的;否那么,默认为32位的;(2).-qwarn64选项:这个编译选项既可在32位模式下使用,也可在64位模式下使用;使用这个可用来检查源程序中64位的兼容性,它对与64位不兼容的代码给出警告;在从32位移植到64位时,这个编译选项是非常有用的;(3).-除了编译选项外,在32位模式与64位模式间转换,还有以下方法:环境变量 OBJECT_MODE(=32 64 32_64)-分别表示32

28、位模式、64位模式编译;32_64表示既可承受32位模式,也可承受64位模式,不过在这种模式下,AIX连接程序与装载程序不会将这种目标程序连接成可执行程序.配置文件 /etc/vac.cfg-在AIX V4.3下是/etc/vac.cfg43,它定义了编译器的许多编译选项;命令行参数这三种方式中,以环境变量最优先,其次是配置文件,最后是命令行参数.2.ar ar命令用于生成库,即将.o文件放到一个库中,由于.o文件有两种模式,即32位与64位,默认情况下,ar处理32位.o文件,用-X(32,64,32_64)选项可使其处理64位.o文件,即生成64位库;3.make 如果对同一个makefi

29、le文件,先在32位模式下运行产生一个32位库,然后又想运行make产生一个64位库时,这个64位库将不会被更新.因为make只认时间戳,而不区分.o文件格式是32位还是64位.而且如果将同名的一个32位和64位.o文件加到同一个库时,会出现问题.4. 32位程序与64位程序在RS/6000 AIX V4.3中的二进制兼容性这实际上是指32位程序与64位程序在64位平台上的二进制兼容性,因为64位程序只能在64位平台上运行,不能在32位平台上运行.一般来说,用在任何32位处理器或64位处理器上的AIX V4.3编译的64位程序在64位处理器模式上不用重新编译就可运行;用在任何32位处理器或64

30、位处理器上的AIX V4.3编译的32位程序在两种模式下都不用重新编译就可运行.下表列出了对32位程序与64位程序的兼容性问题.32位/64位兼容性32位应用程序64位应用程序32位平台二进制兼容*不能执行64位平台二进制兼容*64位唯一可运行的平台*注:二进制兼容是指:运行于AIX V4.1 与V4.2的基于RS/6000 POWER-, POWER2-, 和PowerPC-的应用程序不须重新编译,就可在AIX V4.3的基于同样的或更新的同一系统的处理器上.不过,不包括以下情况:(1).AIX共享库的非共享编译;(2).AIX V4参考手册公开说明的不可迁移的局部;(3).文档未说明的AI

31、X的内部特性;(4).X11R5效劳器扩展(仅适用于AIX V4.3);(5).用POWER2或PowerPC编译特性编译的程序又不是运行在POWER2或PowerPC平台上;(6).用AIX高版本编译的程序在低版本的AIX上可能会运行不正常.从而,须运行在所有平台上的程序必须用编译器的公共选项.用POWER2技术编译的程序必须运行在POWER2平台上;用PowerPC技术编译的程序必须运行在PowerPC平台.5. 64位编程的补充及考前须知(构造以字长为 边界的填充)(1).最好在常数后面加止后缀 在64位程序中,常数一般被编译器默认为long型,就象在32位程序中,常数被编译器默认为in

32、t型一样.可在常数后面加上U或L后缀,前者使编译器将后缀为U的常数作为unsigned int型的数;后者使编译器把后缀为L的常数作为unsigned long型的数;(2).声明所有的自定义函数 一般的cc编译器将无声明的函数的返回类型默认为int;在64位程序中,指针占用64位内存,因此返回指针的函数必须声明为64位,当然如同32位程序一样,可声明为指针;不过,将指针与int变量互相赋值绝对会造成兼容性问题;(3).从32位数扩展为64位数 这种扩展有可能使32位的负数变成64位的正数;(4).与操作系统有关的数据类型 size_t,ssize_t ,time_t等由int long ty

33、pedef的数据类型;(5).含指针或long或unsigned long数据成员的构造的长度的改变 这种改变一般都可由运算子sizeof自动算出;但如果用硬编码(具体数字)也可能造成兼容性问题;(6)对long或 unsigned long数据的移位或逻辑操作(&或|)的长度位的设定三、 移植步骤1. 移植步骤(一).移植步骤.将应用程序从32位移植到64位,一般有以下一些步骤,这些步骤并不意味着功能调整或扩展,只不过是如同32位程序一样的行为在64位模式下的解释,在这个过程之后,要用扩展性能,你可能得修改源程序:(1).程序和数据分析检查所有类型以决定这些数据类型应该是32位还是64位;对

34、系统定义类型,其长度对系统调用/库调用是适宜的;对用户定义类型,32位类型应该定义为int or unsigned int或在64位模式下仍是32位的系统定义类型;而用户定义的64位类型应该定义为long or unsigned long或系统定义的64位的类型;(2).修改数据类型将那些需要改变的数据类型改变为你所选择的类型,此时,要检查所有的算术运算以确保数据值的扩展和截短都是正确的;确保没有作出任何指针适合int类型.(3).校验其他程序输出的使用确保所有被处理的数据在32位X围内;假设不可能,那么其他使用这些数据的程序必须移植到64位或至少能意识到64位.(4).移去存储相关移去在以下

35、情况下的存储相关性:程序正文段,数据段,程序堆,程序堆栈,errno,tok_of_stack构造,共享库数据,共享库正文,和访管指令表;(5).不好的地址用法当传递一个无效的地址给一个系统调用时,64位进程将收到信号SIGSEGV(segmentation violation)而不是EFAULT类型的错误号(14 无效的地址);任何依赖于系统调用来保护无效地址的地方都应该删除.(6).调试与测试测试程序以确定程序与在32位平台上的行为完全一样;假设有差异,那么调试程序.返回第一步在选定数据类型时,如果你要求某些数据类型长度在32位与64位模式下保持一致,比方都是32位,那么有如下三个数据类型

36、:_long32_t,_ulong32_t,ptr64,前两个在头文件/usr/include/inttypes.h中定义,后者在头文件/usr/include/sys/types.h中定义;在32位模式下,_long32_t是long型,_ulong32_t是unsigned long型;在64位模式下,_long32_t是int型,_ulong32_t是uint型;它们在两个模式下都是4B的长度.而ptr64在32位模式下,是unsigned long long 型,在64位模式下,是指针型;在两种模式下,都是8B长度.当想在32位与64位模式下都想有完全一样的长度时,可将(1)long型

37、用_long32_t或其他32位数据类型代替;用_ulong32_t或其他32位数据类型取代ulong类型;(2)用int或其他32位数据类型取代指针;此时,程序在64位模式下对这个字段不能用指针;(二).程序和数据分析(1).long ,intlong与int类型是不可相互交换的,C的long类型(以及从它导出的类型)在64位模式下是64位的;在移植时,应考虑所有与long或unsigned long相关的类型,如size_t在AIX V4.3中是unsigned long.(2).未加后缀的常数象4294967295 (UINT_MAX)这样的数在32位模式下,编译器认为是signed l

38、ong类型的;但在64位模式下,会被当作signed long类型,占8B,这会使得某些操作,如sizeof(4294967295)返回8;纠正措施是,将4294967295写为4294967295U，此时,编译器会将它作为unsigned int类型的数.在64位模式下,假设是16进制的无后缀常数,那么常常会被当作64位的;在移植程序时,要记住这一点.所有可能影响常数赋值的常数都应该明确地加上后缀,对所有数字用后缀或类型可使程序不致出现非期望的行为.(3).指针,int在32位模式下,int,long和指针可相互赋值;在32位扩展模式(XCOFF)中,int ,long可赋值给指针,而将指针

39、赋值给int,long只会给出一个警告信息;在ANSI模式下,在int与指针间相互赋值将产生效劳级消息;在64位模式下,指针变成64位,在指针与int间赋值会引起段故障,而传递指针给一个参数为int的函数会引起截短.下面是一个不正确赋值的例子:int i;int *p;i = (int)p;用强制转换使问题更难发现;警告信息虽没有了,但问题仍存在.对指针和int赋值的问题,应采取以下方法解决:(i).消除程序中假定指针类型适合C的int类型(包括从int导出的类型)的语句;(ii).消除程序中假定long类型适合C的int类型(包括从int导出的类型)的语句;(iii).在做移位或位操作时,消

40、除任何对long位数的假定;(iv).消除C int(包括从int导出的类型)可传递给一个未声明的long或指针参数的假定;(v).消除任何未声明的函数会返回long或指针的假定.2. 源程序64位兼容性检查将32位程序移植为64位程序时,其主要问题集中在程序中使用含指针和/或int类型的数据成员,以及由long typedef的其他数据类型,和一些含long typedef类型参数的系统调用,在程序中这些参数如果被定义为int类型,就一定会出现兼容性问题,还有一些返回指针的系统调用或用户自定义函数,假设其返回值在程序中被赋值给int类型的变量也会造成兼容性问题.因此,在开场编译为64位程序之

41、前,对源程序进展兼容性检查是非常必要的.i. lint t 选项检查兼容性用lint t “源程序可检查有问题的赋值,从32位移植到64位时,用这个命令可检查以下一些兼容性问题:(1).函数未声明原型 函数原型可使编译器和lint标志出未匹配的参数;(2).将long或指针赋值给int这类赋值有可能引起截短,即使使用强制转换;(3).将int赋值给指针如果该指针被引用,有可能是无效的;(4)与long或指针有关的移位操作在64位程序中,由于指针长度已增加到64位,所以其结果将不再有效;(5).与long或指针有关的用比特与,或,异或运算符的掩码操作在64位程序中,掩码也不再足够.例:#incl

42、ude +2 void main(void) +3 int foo_i;+4 long foo_l;+5 int *foo_pt;+6+7 foo_l = boo(1);+8 foo_l = foo_l 1;+9 foo_l = 0xFFFFFFFF;+10 foo_l = (foo_l & 0xFFFFFFFF);+11 foo_l = LONG_MAX;+12 foo_l = (long)foo_i;+13 foo_i = (int) &foo_l;+14 foo_pt = (int *)foo_i;+15 +16 long boo(long boo_l) +17 return(boo_l

43、);+18 # lint -t sample.csample.c, line 7: warning: conversion from int may lose accuracysample.c, line 8: warning: Left Shift involving a longsample.c, line 10: warning: bitwise AND involving a longsample.c, line 12: warning: conversion from int may lose accuracysample.c, line 13: warning: conversio

44、n from PTR long may lose accuracysample.c, line 16: error: illegal redeclaration of boosample.c, line 17: warning: conversion from long may lose accuracy不过,用lint t也还有一些问题不能被发现:(1) 在32位程序与64位程序中共享数据必须有一样的长度(2) 使用long或指针的联合可能不再工作32位与64位模式,还有另外两个差异也可能会影响程序:(1).32位模式下,long long是放在两个通用存放器中,而在64位模式下,它是放在一

45、个通用存放器中;(2).32位模式下,传递一个浮点参数给一个未声明原型的函数时,这个浮点参数被放在一个浮点存放器和两个通用存放器中;而在64位模式下,这个浮点数被放在一个浮点存放器和一个通用存放器中.ii. cc qwarn64 编译选项检查兼容性-qwarn64编译选项,检查可能的long-to-int截短问题;这个编译选项既可在32位模式下用,也可在64位模式下用;在32位模式下,它就象一个预览工具一样,能帮助你发现从32位移植 到64位时的兼容性问题.它能显示数据转换会引起问题的语句.在64位编译模式下,它能检查以下公共性的问题:(1).由于明显或不明显的将long转换为int而引起的截

46、短;(2).由于明显或不明显的将int转换为long而引起的不期望的结果;(3).由于明显地用强制转换符将指针转换为int而引起的无效地址引用;(4).由于明显地用强制转换符将int转换为指针而引起的无效地址引用;(5).由于明显或不明显地把常数转换为long类型;(6).由于明显或不明显地通过强制转换将常数转换为指针引起的问题;(7).源程序中pragma选项arch与命令行选项冲突.例:对上述sample.ccc qwarn64 c sample.csample.c, line 9.12: 1506-743 (I) 64-bit portability: possible change o

47、fresult through conversion of int type into long type.sample.c, line 12.12: 1506-743 (I) 64-bit portability: possible change ofresult through conversion of int type into long type.sample.c, line 13.12: 1506-744 (I) 64-bit portability: possibletruncation of pointer through conversion of pointer type

48、into int type.sample.c, line 14.12: 1506-745 (I) 64-bit portability: possible incorrectpointer through conversion of int type into pointer.iii. 未能由上述工具发现的隐藏的兼容性问题用lint t命令未能发现由int转换为long或由long转换为int引起的兼容性问题;用-qwarn64编译器选项未能检查移位操作;将lint t和-qwarn64编译器选项结合起来可以进展更细致的兼容性检查.3. 目标文件兼容性问题i. AIX C语言编译器cc的特性i

49、i. 64位程序的编译(包括用户库)(1).一些以32位程序已被取代或过期的库不再提供应64位程序,所以这些库的API也从64位模式中消失;(2).64位程序数据重新转换为32位数据,传递给核心;以下图解释了这种情况传递指针调用传递指针对核心扩展的系统调用构建传递指针64位库64位应用程序32位应用程序64位库接口例程64位数据构造调用32位数据构造重映射表32位数据构造64位核心扩展接口例程系统调用目标-希望32位输入参数,32位数据构造32位核心32位库系统调用上图说明:(1).AIX V4.3核心是32位的,它增加了对64位支持的核心扩展;(2).64位进程调用系统API时,其数据必须经

50、64位库接口例程重新映射为32位数据,然后再传递给核心扩展接口,由核心扩展接口例程将调用传递给核心;(3).由于64位的.o文件只能由cc q64产生,所以makefile文件的.c.o:规那么必须加上-q64选项以生成64位的XCOFF格式的.o文件;(4).将编译好的.o文件加到库中时,ar命令默认32位的,为生成64位库,ar X64选项必须被使用;(5).由于make命令只认时间戳,不认.o文件格式,所以如果有两个同名的32位库与64库,在编译了32位库后,再编译64位库时,64位库不会被更新,相反,也是这样;iii. 32位程序与64位程序共同编译的问题4. 32位进程与64位进程的

51、互操作性问题i. AIX程序环境的局部性原理ii. 共存(exec(),fork()iii. 共享资源及限制. 信号与信号灯. 共享内存与消息队列5. 32位进程与64位进程通过网络通信的问题6. 64位程序中有关AIX线程属性的改变现存AIX线程应用基于工业标准POSIX 1003.c Draft7,AIX V4.3在32位模式下既支持Draft7又支持Draft10;但在64位模式下只支持Draft10.为把32位线程应用程序移植到64位,需转换到Draft10.默认线程是Draft10.在AIX V4.3中,线程平安的_r与非线程平安的库被结合到一个库中.比方,libc.a和libc_r

52、.a都作为符号引用,指向/usr/ccs/lib/libc.a;cc_r与xlc_r作为编译线程平安程序仍是可行的;下表说明了编译32位或64位线程程序时用到的各种线程库:/usr/lib/libpthreads.a32-bit/64-bit library providing UNIX98 and POSIX 1003.1c pthreads./usr/lib/libpthreads_pat.a32-bit only library providing POSIX 1003.1c Draft 7 pthreads./usr/lib/profiled/libpthreads.aProfiled

53、 32-bit/64-bit library providing UNIX98 and POSIX 1003.1c pthreads./usr/lib/profiled/libpthreads_pat.aProfiled 32-bit only library providing POSIX 1003.1c Draft 7 pthreads.除了线程库外,在64位程序中,线程的一些属性也有所改变;(1).不再有更多的隐含默认属性在64位模式下,线程的有些默认属性已被改变了.如Draft 10不再定义常量PTHREAD_MUTEX_DEFAULT,程序也不能引用以下变量:pthread_attr

54、_defaultpthread_condattr_defaultpthread_mutexattr_defaultpthread_set_mutexattr_default_np默认的detachable状态也变成了默认的joinable状态;所有线程都必须明确地初始化;例:pthread_attr_t attr; /* thread attribute */pthread_t tid; /* thrtead ID */pthread_attr_init(&attr); /* initialize an attribute */pthread_attr_setdetachstate(&attr

55、, PTHREAD_CREATE_DETACHED);pthread_create(&tid, &attr , thread_main, arg );/* Do something */pthread_attr_destroy(&attr);/* destory thread attribute */(2).参数类型线程的某些参数类型也被改变,具体请参看/usr/include/pthread.h.(3).删除了pthread_yield()系统调用在Draft 10中,pthread_yield()系统调用已被删除.四、 与数据库有关的问题五、 移植后的性能分析1. 一般性能分析2. 物理条件(或硬件环境)3. 建议15 / 15