从位平台移植到位平台的解决方案样本

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

一、概述

1.移植的原因

由于高性能服务器、数据库管理系统、电脑辅助设计工

具，以及数字内容创作工具等应用方案均需要处理大量数

据及占用存储器大量地址，因此为了满足这类应用方案的

需要,64位技术便应运而生。

大约从九十年代后期起，就已经有64位机器问世,从去年

到今年Jntel体系结构的芯片也开始出64位了.在UNIX环境

下，已有几种操作系统支持64位环境了，据说微软也准备将

Windows升级为64位操作系统。能够预料，将来32位平台将

不再是主流，唱主角的将是64位平台。至I」时，客户环境也将全

是64位平台。

因此，由于下面这样一些原因,使得某些应用程序从32位

移植到64位：

(1).工程、科学、商业…需要地址空间大于32位

.大数据集:需处理的数据大于32位所能处理的极限;(大文件

或数据库的内存映射是一种常见技术一经过把文件或数据

库保存在内存，以避免经常的磁盘I/O操作.)

.计算需要

1.程序复杂性;若是32位系统,32位程序，则虽然也能处

理需大地址空间的应用,但程序将变得复杂；

2.应用程序的吞吐量;SMP系统与并行编程不断用来处

理科学计算与其它问题;这意味着，在32位系统上，多至

12个高速处理器共享不超过4GB的内存;64位系统则

能为每个进程提供必要的内存与I/O资源，使得SMP

能很好地进行扩展,并能提供科学，工程，商业领域所需

的批量计算；

3.典型的64位应用一决策支持、数据仓库、数据挖掘、

基于因特网的应用、

电子商务应用、Web服务器、多媒体服务器、数字

密集的应用、一般数据库、大阵列操作应用.

(2).现存32位系统…资源短缺限制了总体性能与吞吐量的

提高

现存32位多用户系统性能不是受限于CPU,而是受限于

I/O带宽;而由分页引起的I/O又主要是由于内存不足于存储

整个文件;如果有足够的内存可用,那么将显著减少分页，从

而显著地改进系统性能.

.高压力环境下的32位应用程序:基于因特网的应用、电

子商务应用、Web服务器、多媒体服务器、一般服务

器、实时系统.(这些应用可从OS提供的大内存获得性能

提高，因为OS会自动地为每个32位应用提供更多的内存

与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位时，由于AIXV4.3本身对

32位程序与64位程序的支持，因此绝大部分的系统调用与C

语言程序结构都不用改变，只要在源程序中遵守系统调月接

□与相应的数据类型;可是，还是有一些由于数据类型长度的

改变而引起的兼容性问题.因此从32位程序移植为64位程序

一般必须经过下列步骤：

(1).源程序的兼容性检查;这一步主要检查由于数据类型

长度改变而引起的兼容性问题；

(2).将从第(1)步检查出的兼容性源程序进行修改；

(3).修改makefile文件;

二、32位平台与64位平台

1.平台的定义

计算机系统是由硬件与软件两部分组成的。所谓平台也

就是指硬件与相应的系统软件(包括操作系统、编译器和与

开发环境有关的应用程序(如数据库))。

64位硬件体系结构是指：

⑴.能处理64位数据即CPU能够将64位数据作为基本单

元进行处理(只需一次操作就可处理)，"字长”是64位的，即存

储单元是64位的.(说明:32位平台的存储单元是32位的)这导

致结构成员的一种以8字节为边界的填充，即第一个成员即使

不足一个8字节的基本存储单元，那么仍占用一个基本存储单

元，而整个结构占用的存储空间也是8字节的倍数.

(2).能产生64位地址包括有效地址和物理地址.注意:虚妫

世概念并不是由处理器体系结构说明的,它是由AIX的

VMM(虚地址存储管理器)说明的.它规定了应用程序可访问

的内存空间的大小.一般来说，届继能够与有效地址或物理

地址不同.

相应地,32位硬件体系结构是指⑴,能将32位数据作为基本数

据单元进行处理;(2).最多只能产生32位地址(包括有效地址

和物理地址).

下列操作可从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位的,而且其操作系

统、编译器等也能支持64位程序.因而,64位平台能充分利

用其64位硬件的性能，使得一些应用程序能从中得到性能的

改进.

2.现有AIX64位平台的特点

i.RS/600064位机器

AIXV4.3和RS/6000S70模型)RS/6000(RS64A)是64位体系结

构,CPU的通用寄存器是64位的,一些控制寄存器也是64位的，它能

够一次移动或操作64位数据，而不需要象在32位处理器那样，必须

由程序员或编译器分两次完成.

PowerPC是64位体系结构

.64位环境是32位环境的超集—即64位指令集是32位

指令集的超集换句话说,32位指令集是64位指令集的子集；

.32位环境与64位环境是局部的;---即一个32位进程其环

境只对这个进程有效，一个64位进程的环境只对这个64位进程

有效;同时运行的32位进程与64位进程可有不同的运行环境；

.不论哪种方式,都无任何模拟或仿真「-即32位进程执

行32位指令集,64位进程执行64位指令集;而不是说,64位指令

集是经过32位指令集来模拟或仿真；

AIXV4.364位体系结构的好处

⑴64位数据类型某些应用程序可从64位整型硬件的性能和

更高的精度获益;不过主要的可能还是由非64位应用程序用

64位整型运算操纵64位指针.

⑵存取大文件一数据仓库、科学和多媒体应用经常需要非常

大的文件和文件系统，它们很容易由64位数据类型处理；

巨大的地址空间一有些应用程序既需要用大内存

(23G16GB),也需要访问海量虚拟存储Q8。),许多科学应月就

能够简单地编程,并能比较高效地执行.数据段和堆栈都是巨

大的，存储映射也会得到显著改进.

ii.AIXV4.3支持64位程序的操作系统

①提升了4GB的系统内存限制

.4GBQ32)是对32位PowerPC、平台的限制；

.AIXV4.3支持＞4GB的内存；

.AIXV4.3在RS/6000S70服务器上支持16GB内存；

.当内存足够时,AIX会自动扩展至大内存；

.32位程序仍受限于〈4GB的内存；

.在S70上，可有多个32位程序每个都有至多4GB的内存:

.换句话说，一个大的32位的应用程序可充分利用任

色J〉4GB的内存；

.64位程序可存取260B的内存.

.应用程序地址空间可大于4GB

.在S70且安装AIXV4.3的系统上被编译为64位的程序;

.对超出32位寻址范围的应用程序.

②不必为担心性能而重新编译

.在64位平台上，将32位程序重新编译为32位时,其性能

会无任何差别，因为这会任何编译器的改进；

・32位重新编译为64位时，会看到些微的性能差别；

.默认编译模式是产生32位可执行程序.

@AIXV4.3核心是32位，在64位平台上有附加的64位扩展;

.为支持完全64位功能，核心不一定要求是64位的；

.32位核心维持对32位的兼容性和健壮性；

.核心扩展提供了64位程序所要求的功能；

.新的应用程序二进制接口681）;

提供了对设备3仅动程序的二进制兼容性；

.VMM支持64位进程地址空间；

.只要有必要，某些系统调用可修改为64位参数（如文件和

内存操作）；

.对某些设备驱动程序有一些前提或限制.

④32位与64位进程的完全互操作性

I.进程一进程

.可共享文件.内存,IPC资源(但要注意某些共享内存的

分配万式一字节边界问题)，也可相互发信号；

.可相互exec()调用;

.32位与64位进程可设置非本类进程的限制；

2.32位与64位系统结构

.编译器仍是32位的；

.编译器既可在32位平台，也可在64位平台上运行;

.既可产生32位，也可产生64位可执行文件.

.头文件已被修改过，以支持两种环境；

.增强了功能的共享库的体系结构.

.两种环境下都用同样的路径；

.只维护单一的源程序,makefile文件，

,管理共享库的工具默认为32位的.

⑤32位与64位核心支持

.AIXV4.3既支持32位的虚地址空间又支持64位的虚

地址空间；

,包含VMM与进程调度和其它功能；

.32位进程与64位进程对系统设备都有同等访问权

利；

.默认行为都是32位兼容的;

.进程调用设备驱动程序一般被核心分隔.

⑥能在32位机器上运行64位程序吗？

.显然不能；

.不过，在32位机器上编译与链接64位程序是可能的（假如

相关的库等等已安装）.

⑦AIX命令与工具

.绝大多数AIX命令与工具仍是32位的；

.需支持64位的绝大多数工具也仍是32位的；

.所有命令与工具将继续支持32位；

.编译器与连接程序支持64位的（注意:这并不意味着二者

是64位的）.

H.原有32程序与新的64位程序的二进制兼容性

原有32位程序可不用重编译，即可在AIXV4.3中继续作

为32位程序运行.

（1）.在AIXV4.3中,32位程序完全的二进制兼容性；

.现存32位程序毋须修改或重新编译，就可在64位平台上

运行；

.32位模式下,百分之百的兼容性;即在64平台上编译的

32位程序与32位平台上编译的32位程序都可在64位平

台上共存运行；

.32位程序无任何性能下降，即32位程序不论是在32位平

台上运行,还是在64位平台上运行，其性能无可分辨的差别.

.(2).64位与32位的共存

.AIXV4.3在64位平台中提供两种应用环境;这两种应

用环境是互补而非竞争的环境：64位环境是向上兼容的

AIX的附加，比AIXV4.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类型

Ctype32BFTPCLP64LLP64ILP64

char88888

shortint16161616

32163264

longim32323264

longlongint64□/a6464

pointer3216/326464

从上表可看出:LP64模式中,char.shomint这二种数据类型

与32位程序相应的数据类型完全一样;而long型与指针

则变成64位，相应地在32位程序中,long与指针是32位

的.LP64是一个一般的64位程序数据类型标准;不过,AIX

用的是IPL32+longlongint;见下表：

Table6.ILP32,LP64andCforAIXCompilerModelTypeSize

DatatypeILP32(sizeinbit)LP64(sizeinbit)CforAIX(32-bit/

64-bit)

char88Implemented

short1616Implemented

int3232Implemented

long3264Implemented

longlongNetDefinedNotDefined64/64

pointer3264Implemented

float3232Implemented

double6464Implemented

longdoubleNetDefinedNotDefined64or128/64or128(1)

int8_tNetDefinedNotDefinedFixed-widthtype(2)

uint8_t8bits(1byte)

int16_tNetDefinedNotDefinedFixed-widthtype(2)

uintl6_t16bits(2bytes)

int32_tNetDefinedNotDefinedFixed-widthtype：2)

uint32_t32bits(4bytes)

int64_tNetDefinedNotDefinedFixed-widthtype⑵

uint64_t64bits(8bytes)

_int8NetDefinedNotDefinedFixed-widthtype⑶

—uint81byte

_int16NetDefinedNotDefinedFixed-widthtype(3)

_uintl62bytes

」nt32NetDefinedNotDefinedFixed-widthtype⑶

_uint324bytes

_int64NetDefinedNotDefinedFixed-widthtype：3)

_unit648bytes

(1)Dependonthesettingofthebngdoubleoption.Bydefault,thesizes8.

(2)ANSIfixed-sizetypes.

(3)Shouldnotbeused;useANSItypesinstead.

说明:

其中粗体部分表明在32位与64位程序中长度有异.AIX为使

其C++与Microsoft兼容,使用了—int8/16/32/64数据类型，在

UNIX环境下一般应使用ANXIC数据类型，这包括在头又件

<inttypes.h>中.

很明显,64位程序与32位程序最大的不同就是:long与指针两

种数据类型的长度小同，当然那些由long间接定义的数据类型

其长度也跟着不同.在32位程序中,intJong.pointer三种数据类

型的长度是一样的;三者相互赋值不会有影响;但在64位程序

中,int长度只有4B,而long,pointer长度却有8B,而且有些由long

typedef的数据类型也是8B,从而在int与long或pointer之间赋

值就会导致错误,特别是有些由longtypedef的数据类型常常见

作函数参数，如果相应参数在程序中被定义为int,无疑会导致兼

容性问题.

2..结构分配问题

我们知道，在32位程序中，结构数据有一种字边界填充的定位问

题:即一个结构的第一个成员一定位于字边界上，即使该成员实际占

用空间并不需要一个字长的存储空间,也会分配一个字长的存储空

间，剩余空间由编译器填充;而且整个结构所占空间也应位于字长边

界上；

如structstruc32{

inti;

•ongj;

charc;

这个结构长度是12B,即sizeof(struc32)=12;其最后一个成员虽只

有一个字节，但也分配4个字节；

同样地，在64位程序中，也存在结构填充问题;只不过不是以字为

边界,而是以双字为边界；

如structstruc64{

inti;

longj;

char*p;

)；

在32位程序中，这个结构的长度是12B,在64位程序中，其长度是

24B;第一个成员只占4B,但编译器也给它分配8B空间.

值得注意的是:在64位程序下,某些结构只成员一样，但成员位置

不同时，其长度也会不同；

如structli{

longla;

intia;

}li；

structlii{

longla;

intia;

intib;

}lii；

structili{

intia;

longla;

intib;

}ili；

注意ili与lii两个结构变量:在64位程序中,sizeof(struct

lii)=16;sizeof(structili)=24;

在64位程序中，对结构成员的恰当排列，有可能减少程序所占空

间.

讯OBJ文件格式

1.定义在32位程序中，经过编译器编译生成的。文件，一般

是COFF格式(CommonObjectFormatFile),但AIXV4.3为支

持64位程序，其。文件格式为XCOFF(extendedCommon

ObjectFormatFile);它组合了COFF格式与模块格式内容表

(TOC)两部分;后者提供了.o文件的动态连接与单元代

替.XCOFF文件格式的主要优点就是它能提供对共享库和其

它外部。文件的动态解析引用.而一般地,COFF格式文件只

能静态引用.

XCOFF格式文件定义了。文件与可执行文件的机器内存映

象的排列方式，它是由语言处理器(ASM与编译器)生成的，绑

定器将单个的.0文件组装形成可执行文件，装载程序将

XC0FF格式的可执行文件读进内存，形成程序的内存映象,

符号调试器读这个XCOFF的可执吁文件，以提供程序内存映

象中的变量与函数的符号引用.

这种文件格式只能由AIXV4.3及以上版本才能生成及装

载;当在64位模式下编译时，编译器生成64位指令并产生64

位XC0FF格式.o文件，此时绑定器只绑定64位.0文件以生

成64位可执行文件.注意，在绑定到一起的.。文件中，不论是

静态绑定还是动态绑定,都只能是同一格式的.。文件，即32位

的.。文件与64位的。文件的混合绑定是不允许的.（所谓64

位模式，是指生成64位指令，产生64位XCOFF格式文件）

AIX将XCOFF作为32位与64位程序的.o文件格式，从而

有XCOFF32与XCOFF64之分，在RS/600032位平台或64

位平台上,AIX的编译器默认为32位模式，即经编译所得的目

标文件是32位的;不过,AIX的cc编译器在调用连接程序Id

生成可执行程序时,M将只是把同类的。文件（包括库文件）连

接成可执行程序，即要么是XCOFF32格式的.0文件,要么是

XCOFF64格式的.o文件.

AIX的cc的这个特性要求:如果库是XCOFF32格式的文

件,那么所有用到这个库的可执行程序就只能编译为32位的;

如果共享库的某个可执行程序要编译为64位的，那么与这个

共享库有关的所有可执行程序都要编译为64位的;不允许共

享库某个32位库的可执行程序编译为32位的,而另一个共享

该库的可执行程序却编译为64位的.

不过，在AIXV4.3中，有少数几个命令既支持32位XCOFF

格式同时又支持64位XCOFF格式(即混合模式)，这些命令有

ar,dump,.nm,lorder,ranlib,size,strip.它者［4用-X标志

(-X32,.X64,-X32_64)来说明.o文件格式.ar支持两种x(X)标

志・・x表示从档案库中抽出所指定的文件并放到当前目录;而

-X标志则指定

iii.编译

1.CC编译一般来说,AIXAIX编译器CC有许多编译选项，这里

只简单介绍一些与64位有关的编译选项.

(l).・q64选项:有这个编译开关时,所编译生成的.。或可执行程

序将是64位的;否则,默认为32位的；

(2).-qwam64选项:这个编译选项既可在32位模式下使用，也

可在64位模式下使用;使用这个可用来检查源程序中64位的

兼容性，它对与64位不兼容的代码给出警告;在从32位移植

到64位时，这个编译选项是非常有用的；

(3)..除了编译选项外，在32位模式与64位模式间转换，还有以

下方法:

环境变量OBJECT_MODE(=326432_64)—分别表示

32位模式、64位模式编译;32_64表示既可接受32位模式,

也可接受64位模式，不过在这种模式下,AIX连接程序与装载

程序不会将这种目标程序连接成可执行程序.

配置文件/etc/vac.cfg--在AIXV4.3下是/etc/vac.cfg43,

它定义了编译器的许多编译选项；

命令行参数

这三种方式中，以环境变量最优先，其次是配置文件，最后

是命令行参数.

2.arar命令用于生成库，即将.。文件放到一个库中，由于.。

文件有两种模式，即32位与64位,默认情况下,ar处理32位.o

文件，用・X(32,64,32_64)选项可使其处理64位.0文件,即生成

64位库；

3.make如果对同一个makefile文件，先在32位模式下运行

产生一个32位库,然后又想运行make产生一个64位库时,

这个64位库将不会被更新.因为make只认时间戳,而不区

分.。文件格式是32位还是64位.而且如果将同名的一个32

位和64位.0文件加到同一个库时，会出现问题.

4.32位程序与64位程序在RS/6000AIXV4.3中的二进制兼容

性

这实际上是指32位程序与64位程序在64位平台上的二进制

兼容性，因为64位程序只能在64位平台上运行，不能在32位

平台上运行.一般来说，用在任何32位处理器或64位处理器上

的AIXV4.3编译的64位程序在64位处理器模式上不用重新

编译就可运行;用在任何32位处理器或64位处理器上的AIX

V4.3编译的32位程序在两种模式下都不用重新编译就可运

行.

下表列出了对32位程序与64位程序的兼容性问题.

32位/64位兼容性

32位应用程序64位应用程序

32位平台二进制兼容*不能执行

64位平台二进制兼容*64位唯一可运行的平台

*注:二进制兼容是指:运行于AIXV4.1与V4.2的基于RS/6000

POWER-,POWER2.，和PowerPC-的应用程序不须重新编译，就

可在AIXV4.3的基于同样的或更新的同一系统的处理器上.不

过，不包括下列情况：

(l).AIX共享库的非共享编译；

(2).AIXV4参考手册公开说明的不可迁移的部分；

(3).文档未说明的AIX的内部特性；

(4).X11R5服务器扩展(仅适用于AIXV4.3);

(5).用POWER2或PowerPC编译特性编译的程序又不是运行

在POWER2或PowerPC平台上；

(6).用AIX高版本编译的程序在低版本的AIX上可能会运行

不正常.

从而，须运行在所有平台上的程序必须用编译器的公共选项.用

POWER2技术编译的程序必须运行在POWER2平台上;用

PowerPC技术编译的程序必须运行在PowerPC平台.

5.64位编程的补充及注意事项(结构以字长为边界的填充)

⑴.最好在常数后面加止后缀£64位程序中，常数一般被

编译器默认为long型,就象在32位程序中，常数被编译器默认

为血型一样.可在常数后面加上U或L后缀，前者使编译器将

后缀为U的常数作为unsignedint型的数;后者使编译器把后

缀为L的常数作为unsignedlong型的数；

(2),声明所有的自定义函数一般的cc编译器将尢声明的

函数的返回类型默认为int;在64位程序中，指针占用64位内

存，因此返回指针的函数必须声明为64位，当然如同32位程

序一样，可声明为指针;不过，将指针与int变量互相赋值绝对

会造成兼容性问题；

(3).从32位数扩展为64位数这种扩展有可能使32位的负

数变成64位的正数；

(4).与操作系统有关的数据类型size_t,ssize_t,time_t等由

intlongtypedef的数据类型；

(5).含指针或long或unsignedlong数据成员的结构的长度的

改变这种改变一般都可由运算子sizeof自动算出;但如果

用“硬编码”(具体数字)也可能造成兼容性问题；

(6)对long或unsignedlong数据的移位或逻辑操作(&或|)的

长度位的设定

三、移植步骤

1.移植步骤

(一).移植步骤

.将应用程序从32位移植到64位,一般有下列一些步骤，这

些步骤并不意味着功能调整或扩展，只不过是如同32位程序一

样的行为在64位模式下的解释，在这个过程之后，要用扩展性能,

你可能得修改源程序:：

(1).程序和数据分析

检查所有类型以决定这些数据类型应该是32位还是64位;

对系统定义类型，其长度对系统调用/库调用是合适的;对用户定

义类型,32位类型应该定义为intorunsignedint或在64位模式下

仍是32位的系统定义类型;而用户定义的64位类型应该定义为

longorunsignedlong或系统定义的64位的类型；

⑵修改数据类型

将那些需要改变的数据类型改变为你所选择的类型,此时,

要检查所有的算术运算以确保数据值的扩展和截短都是正确的;

确保没有作出任何指针适合int类型.

(3),校验其它程序输出的使用

确保所有被处理的数据在32位范围内;若不可能，则其它使

用这些数据的程序必须移植到64位或至少能意识到64位.

(4).移去存储相关

移去在下列情况下的存储相关性:程序正文段,数据段，程序

堆，程序堆栈,ermo,tok_of_stack结构，共享库数据，共享库正文，和

访管指令表；

(5),不好的地址用法

当传递一个无效的地址给一个系统调用时,64位进程将收

到信号SIGSEGV(segmentationviolalion)而不是EFAULT类型的

错误号(14无效的地址);任何依赖于系统调用来保护无效地址

的地方都应该删除.

(6).调试与测试

测试程序以确定程序与在32位平台上的行为完全一样;若

有差别，则调试程序.返回第一步

在选定数据类型时，如果你要求某些数据类型长度在32位

与64位模式下保持一致，比如都是32位，那么有如下三个数据类

型：

_long32_t,_ulong32_t,ptr64,

前两个在头文件/usr/include/inttypes.h中定义，后者在头文

件/usr/include/sys/types.h中定义；

在32位模式下,_long32_t是long型,_ulong32_t是

unsignedlong型;在64位模式下,—long32_t是int型,—ulong32_t

是uint型;它们在两个模式下都是4B的长度.而ptr64在32位模

式下，是unsignedlonglong型，在64位模式下，是指针型;在两种

模式下，都是8B长度.

当想在32位与64位模式下都想有完全相同的长度时，可将

(l)long型用_long32_t或其它32位数据类型代替；用

_ulong32_t或其它32位数据类型取代ulong类型;(2)用int或其

它32位数据类型取代指针;此时,程序在64位模式下对这个字段

不能用指针；

(二).程序和数据分析

(l).long,int

long与int类型是不可相互交换的,C的long类型(以及从它导

出的类型)在64位模式下是64位的;在移植时,应考虑所有与

long或unsignedlong相关的类型，如size_t在AIXV4.3中是

unsignedlong.

(2).未加后缀的常数

象(UINT_MAX)这样的数在32位模式下,编译器认为是

signedlong类型的;但在64位模式下，会被当作signedlong类型,

占8B,这会使得某些操作，如sizeof()返回8;纠正措施是,将写为

U,此时，编译器会将它作为unsignedint类型的数.

在64位模式下，若是16进制的无后缀常数，则常常会被当作

64位的;在移植程序时，要记住这一点.所有可能影响常数赋值的

常数都应该明确地加上后缀，对所有数字用后缀或类型可使程

序不致出现非期望的行为.

⑶.指针,int

在32位模式下,int,long和指针可相互赋值;在32位扩展模式

(XCOFF)中,intJong可赋值给指针，而将指针赋值给int,long只

会给出一个警告信息;在ANSI模式下，在int与指针间相互赋值

将产生服务级消息；

在64位模式下，指针变成64位，在指针与int间赋值会引起段

故障，而传递指针给一个参数为血的函数会引起截短.

下面是一个不正确赋值的例子：

inti;

int*p;

i=(int)p;

用强制转换使问题更难发现;警告信息虽没有S,但问题仍存在.

对指针和血赋值的问题应采取下列办法解决：

⑴.消除程序中假定指针类型适合C的int类型(包括从int导

出的类型)的语句；

(ii).消除程序中假定long类型适合C的int类型(包括从int

导出的类型)的语句；

(亩).在做移位或位操作时，消除任何对long位数的假定；

(iv).消除Cint(包括从int导出的类型)可传递给一个未声明的

long或指针参数的假定；

(v).消除任何未声明的函数会返回long或指针的假定.

2.源程序64位兼容性检查

将32位程序移植为64位程序时，其主要问题集中在程序

中使用含指针和/或int类型的数据成员,以及由longtypedef

的其它数据类型，和一些含longtypedef类型参数的系统调用,

在程序中这些参数如果被定义为血类型，就一定会出现兼容

性问题，还有一些返回指针的系统调用或用户自定义函数，若

其返回值在程序中被赋值给int类型的变量也会造成兼容性

问题.因此，在开始编译为64位程序之前，对源程序进行兼容

性检查是非常必要的.

i.lint-t选项检查兼容性

用lint-t”源程序”可检查有问题的赋值，从32位移植到64位

时,用这个命令可检查以下一些兼容性问题：

(1),函数未声明原型

函数原型可使编译器和lint标志出未匹配的参数；

(2).将long或指针赋值给int

这类赋值有可能引起截短,即使使用强制转换；

(3).将int赋值给指针

如果该指针被引用，有可能是无效的；

(4)与long或指针有关的移位操作

在64位程序中，由于指针长度已增加到64位,因此其结果将

不再有效；

(5).与long或指针有关的用比特“与“，”或7异或”运算符的掩

码操作

在64位程序中，掩码也不再足够.

例：

#include<stdio.h>

+2voidmain(void){

+3intfoo_i;

+4longfoo_l;

+5int*foo_pt;

+6

+7foo_l=boo(l);

+8foo_l=foo_l«1;

+9foo_l=OxFFFFFFFF;

+10foo.l=(foo_l&OxFFFFFFFF);

+11fooj=LONG.MAX;

+12foo_l=(long)foo_i;

+13foo_i=(int)&foo_l;

+14foo_pt=(int

+15}

+16longboo(longboo_l){

+17return(boo」)；

+18}

#lint-tsample.c

"sample.c",line7:warning:conversionfrom"int"maylose

accuracy

"sample.c",line8:warning:LeftShiftinvolvinga“long”

“sample.c",line10:warning:bitwise"AND"involvinga"long"

"sample.c",line12:warning:conversionfrom"int"maylose

accuracy

"sample.c",line13:warning:conversionfrom"PTRlong"maylose

accuracy

"sample.c",line16:error:illegalredeclarationofboo

,line17:warning:conversionfrom"long"maylose

accuracy

不过，用lint-t也还有一些问题不能被发现：

⑴在32位程序与64位程序中共享数据必须有相同的长度

⑵使用long或指针的联合可能不再工作

32位与64位模式，还有另外两个差别也可能会影响程序：

⑴.32位模式下Jonglong是放在两个通用寄存器中，而在64

位模式下，它是放在一个通用寄存器中；

(2).32位模式下,传递一个浮点参数给一个未声明原型的函

数时，这个浮点参数被放在一个浮点寄存器和两个通用寄存

器中;而在64位模式下,这个浮点数被放在一个浮点寄存器

和一个通用寄存器中.

ii.cc-qwarn64编译选项检查兼容性

-qwarn64编译选项，检查可能的long-to-int截短问题;这个

编译选项既可在32位模式下用,也可在64位模式下用;在32

位模式下，它就象一个预览工具一样，能帮助你发现从32位移

植到64位时的兼容性问题.它能显示数据转换会引起问题

的语句.在64位编译模式下，它能检查下列公共性的问题：

(1).由于明显或不明显的将long转换为int而引起的截短;

(2)..由于明显或不明显的将int转换为long而引起的不期

望的结果;

(3).由于明显地用强制转换符腐指针转换为int而引起的

无效地址引用；

(4).由于明显地用强制转换符将int转换为指针而引起的

无效地址引用；

(5).由于明显或不明显地把常戮转换为long类型；

(6).由于明显或不明显地经过强制转换将常数转换为指

针引起的问题；

(7).源程序中pragma选项arch与命令行选项冲突.

例:对上述sample.c

cc-qwarn64-csample.c

"sample.c",line9.12:1506-743(I)64-bitportability:possible

changeofresultthroughconversionofinttypeintolongtype.

"sample.c",line12.12:1506-743(I)64-bitportability:possible

changeofresultthroughconversionofinttypeintolongtype.

"sample.c",line13.12:1506-744(I)64-bitportability:possible

truncationofpointerthroughconversionofpointertypeintoint

type.

"sample.c",line14.12:1506-745(I)64-bitportability:possible

incorrectpointerthroughconversionofinttypeintopointer.

iii.未能由上述工具发现的隐藏的兼容性问题

用lintT命令未能发现由int转换为10ng或由long转换为int

引起的兼容性问题；

用.qwarn64编译器选项未能检查移位操作;将lint-t和

-qwam64编译器选项结合起来能够进行更细致的兼容性检

查.

3.目标文件兼容性问题

i.AIXC语言编译器cc的特性

ii.64位程序的编译(包括用户库)

(1).一些以32位程序已被取代或过期的库不再提供给64位

程序,因此这些库的API也从64位模式中消失；

(2).64位程序数据重新转换为32位数据，传递给核心;下图解

释了这种情况

系统调用目

姿s

上图说明:

(l).AIXV4.3核心是32位的,它增加了对64位支持的核心

扩展；

(2).64位进程调用系统API时,其数据必须经64位库接口

例程重新映射为32位数据，然后再传递给核心扩展接口,

由核心扩展接口例程将调用传递