下载文档原格式
鲲鹏服务应用移植方案介绍目录鲲鹏移植支持服务方案2鲲鹏应用移植概述1鲲鹏移植支持服务亮点3典型案例4新业态驱动多样性计算的发展全栈全场景•AI •IOT•5G+•自动驾驶•智能手机•文本•图片•语音•视频•文本处理•大数据分析•科学计算•视频处理数据计算多种计算架构的组合是最优的解决路径CPUARMx86异构FPGAGPU新业态+计算多样性带来新的挑战•重核架构•高性能•通用性强•封闭平台•多核架构•高并发•均衡功耗•开放平台•众核架构•浮点计算•图像处理•门阵列架构•逻辑运算快•灵活、可编程NPU•ASIC芯片•功耗&时延低•深度学习行业软件支持ARM需要进行应用移植与验证分类鲲鹏920（ARM，Hi1620芯片）Intel5118（X86，中移动C2模型）影响分析处理能力48Core，主频2.6G/3G12Core ，主频2.3GHz及以上单服务器性能优于X86 C2服务器指令集ARM RISC X86 CISC 上层应用软件基于ARM指令集重新编译及代码适配指令集位数64位64位/32位32位程序调整为64位字节序大/小端（默认小端）小端无影响NUMA单CPU 2个单CPU 1个无影响适配调优代码适配/共源码及调优重新编译软件重新编译/出软件包集成验证功能/性能和兼容性测试应用移植方法论：不同开发语言应用程序移植流程Java, Python, Nodejs 等解释性语言C/C++/Go等编译型语言Windows开发语言整体迁移鲲鹏计算平台语言支持跨平台，运行环境OK即可开源软件自研软件商用闭源软件获取源代码重新编译选择可替代的其他软件商业合作社区协同X86 + 鲲鹏混合部署方案暂时不支持Kunpeng适配C/C++/Go等编译型语言X86平台应用移植方法论：商业闭源数据库和中间件迁移策略商业闭源商业鲲鹏兼容数据库开源鲲鹏兼容数据库数据库商业闭源商业鲲鹏兼容中间件开源鲲鹏兼容中间件中间件鲲鹏服务伙伴华为TOP迁移合作伙伴，丰富的鲲鹏云迁移经验华为严选CSSP伙伴，专业数据库中间件服务商跨平台软件移植面临的挑战基于传统平台的应用软件基于创新架构平台的应用软件能否迁移？技术可行性如何迁移？功能可用性性能达标？调优定位•人工分析投入大、周期长•反复编译调试、准确率低•移植专业技能要求高•反复定位试错、准确率低•依赖经验，人工定位•调优能力弱，优化效果不佳目录鲲鹏移植支持服务方案2鲲鹏应用移植概述1鲲鹏移植支持服务亮点3典型案例4迁移过程概述——五个阶段完成软件迁移阶段一技术分析阶段二编译迁移阶段三功能验证阶段四性能调优阶段五规模商用软件迁移的五个阶段软件移植•软件栈分析（应用软件、OS、数据库、中间件组件等）•编程语言/代码、依赖库分析•全量功能验证•交付工具适配•产品关键性能指标测试和调优•全面性能测试和调优•可靠性、可服务性验证和配置工具开发•上市资料刷新•重写汇编代码•修改编译选项•代码编译（含依赖库替换）迁移环境管理工作•准备调试编译环境（准备测试样机服务器/OpenLab线上服务器）•搭建编译调试环境（OS/编译器/CI工程等）•部署测试工具•搭建功能测试环境•部署生产系统•灰度/割接上线•成立项目组•制定迁移计划•协调相关人力/物料资源•例行监控与沟通汇报•例行监控与沟通汇报•例行监控与沟通汇报•项目总结关闭鲲鹏移植支持服务：服务内容\协助将客户业务系统成功迁移到华为鲲鹏云，对过程中出现的问题，提供专业的技术支持服务。
TaiShan服务器代码移植参考手册文档版本01发布日期2019-08-03前言概述本文提供将软件从x86 Linux平台移植到ARM Linux平台的移植指导，以及移植过程中遇到的相关问题处理方法，包括编译环境准备、编译脚本和源码修改两部分内容。
读者对象本文档主要适用于执行软件移植的研发工程师和技术支持工程师。
符号约定在本文中可能出现下列标志，它们所代表的含义如下。
用于警示紧急的危险情形，若不避免，将会导致人员死亡或严重的人身伤害。
用于警示潜在的危险情形，若不避免，可能会导致人员死亡或严重的人身伤害。
用于警示潜在的危险情形，若不避免，可能会导致中度或轻微的人身伤害。
用于传递设备或环境安全警示信息，若不避免，可能会导致设备损坏、数据丢失、设备性能降低或其它不可预知的结果。
“注意”不涉及人身伤害。
用于突出重要“说明”不是安全警示信息，不涉及人身、设备及环境伤害。
修改记录目录前言 (ii)1 简介 (1)1.1 编程语言简介 (1)1.2 基于编译型语言开发的应用程序 (3)1.3 基于解释型语言开发的应用程序 (3)2 准备工作 (4)3 移植相关问题处理 (5)3.1 编译脚本移植类问题 (5)3.1.1 -m64编译选项 (5)3.1.2 char数据类型的符号 (5)3.2 源码修改类问题 (6)3.2.1 代码中汇编指令需要重写 (6)3.2.2 替换x86 CRC32汇编指令 (6)3.2.3 替换x86 bswap汇编指令 (8)3.2.4 替换x86 rep汇编指令 (8)3.2.5 快速移植内联SSE/SSE2应用 (9)3.2.6 弱内存序导致程序执行结果和预期不一致 (9)3.2.7 对结构体中的变量进行原子操作时程序异常coredump (10)3.2.8 核数目硬编码 (11)3.2.9 双精度浮点型转整型时数据溢出，与X86平台表现不一致 (12)4 编译优化项 (14)4.1 gcc编译器优化浮点运算精度 (14)4.2 增加编译选项匹配Kunpeng处理器架构，提升性能 (15)4.3 增加编译选项匹配Kunpeng处理器流水线，提升性能 (15)1 简介1.1 编程语言简介1.2 基于编译型语言开发的应用程序1.3 基于解释型语言开发的应用程序1.1 编程语言简介按照翻译方式的不同，高级语言通常可以分为两类：一类是编译翻译，一类是解释翻译，分别对应着编译型语言和解释型语言。
长城计算机计算机的发展史2011-06-11长城计算机计算机的发展史长城计算机计算机的发展史计算机发展的几个阶段ENIAC诞生后短短的几十年间，计算机的发展突飞猛进。
主要电子器件相继使用了真空电子管，晶体管，中、小规模集成电路和大规模、超大规模集成电路，引起计算机的几次更新换代。
每一次更新换代都使计算机的体积和耗电量大大减小，功能大大增强，应用领域进一步拓宽。
特别是体积小、价格低、功能强的微型计算机的出现，使得计算机迅速普及，进入了办公室和家庭，在办公室自动化和多媒体应用方面发挥了很大的作用。
目前，计算机的应用已扩展到社会的各个领域。
可将计算机的发展过程分成以下几个阶段：1.第一代计算机(1946年~1957年)主要元器件是电子管。
2.第二代计算机(1958年~1964年)用晶体管代替了电子管。
3.第三代计算机(1965年~1970年)以中、小规模集成电路取代了晶体管。
4.第四代计算机(1971年至今)采用大规模集成电路和超大规模集成电路。
5.第五代计算机智能计算机1956年，夏培肃完成了第一台电子计算机运算器和控制器的设计工作，同时编写了中国第一本电子计算机原理讲义。
1957年，哈尔滨工业大学研制成功中国第一台模拟式电子计算机。
1958年，中国第一台计算机--103型通用数字电子计算机研制成功，运行速度每秒1500次。
1959年，中国研制成功104型电子计算机，运算速度每秒1万次。
1960年，中国第一台大型通用电子计算机--107型通用电子数字计算机研制成功。
1963年，中国第一台大型晶体管电子计算机--109机研制成功。
1964年，441B全晶体管计算机研制成功。
1965年，中国第一台百万次集成电路计算机"DJS-Ⅱ"型操作系统编制完成。
1967年，新型晶体管大型通用数字计算机诞生。
1969年，北京大学承接研制百万次集成电路数字电子计算机--150机。
1970年，中国第一台具有多道程序分时操作系统和标准汇编语言的计算机--441B-Ⅲ型全晶体管计算机研制成功。
AMD 64-bit CPU架构跃然舞台你真的需要一个64-bit的CPU吗?在我们开始进入讨论AMD的x86-64结构以及与其竞争的其他方案比较之前，我们首先要说明一下我们是否需要64-bit的处理器。
微处理器的―进化‖原则相当简单。
技术进步导致原先在高端企业级上的产品不久之后就转到了普通用户的桌面系统上，就是说，企业级的产品需求永远是高于普通桌面PC的等级的。
现在64-bit的CPU刚被应用在了高端机上，也就证明了，目前64-bit CPU并非是每个人都需要的。
64位处理器针对的主要对象是目前对32位系统感觉受限制的用户。
最容易得到的证明就是不少硬件设计人员都由衷地感到：―啊！我们确实需要一块itanium来设计我们的下一代芯片！‖现在的CPU设计已经到了令人难以置信的复杂，让AMD和Intel的工程师从运用64位处理器中提高的工作效率可以说是令人匪夷所思。
同样的，一些用来设计汽车，卫星以及一些其他的非常复杂的产品的MCAD软件（机械计算机辅助设计软件）也将通过64位系统得到不少的性能提升。
另外，超大规模的数据库软件也会从64位结构获得不少好处，原因是他们将从64位的大内存寻址区域获得不少优势。
可见其企业级应用是相当广泛的。
例如，安全和加密技术这样需要64位内存寻址功能的程序，可以不用将数据分为几个部分来进行操作，这样带来的效率提高是相当明显的。
AMD和Intel列举了大量64位系统的优势，并且将天气预报系统作为了最好的例证。
生死相搏：x86-64 vs IA-64现在的AMD处于一种相当特殊的位置：一方面，AMD是相当弱小的，根本不可能阻挡Intel在各方面的优势以及成功，但另一方面，它又是相当有实力的，它开发的CPU足以与Intel产品在主流市场相抗衡，同时又发布了与Intel的IA-64完全不同的64 bit架构，这样的竞争是不同寻常的，因为这个竞争将把用户带到另一个CPU的战国时代，使用不同CPU的计算机之间程序不通用，使得用户必须决定究竟采用什么样的系统才是他们需要的，两个体系的大碰撞，最终意味着其中一个必须从PC舞台上消失。
Linux 64 位体系结构不幸的是，C 编程语言并没有提供一种机制来添加新的基本数据类型。
因此，提供 64 位的寻址和整数运算能力必须要修改现有数据类型的绑定或映射，或者向 C 语言中添加新的数据类型。
表 1. 32 位和 64 位数据模型ILP32 LP64 LLP64 ILP64char 8 8 8 8short 16 16 16 16int 32 32 32 64long 32 64 32 64long long 64 64 64 64指针32 64 64 64这 3 个 64 位模型（LP64、LLP64 和 ILP64）之间的区别在于非浮点数据类型。
当一个或多个 C 数据类型的宽度从一种模型变换成另外一种模型时，应用程序可能会受到很多方面的影响。
这些影响主要可以分为两类：∙数据对象的大小。
编译器按照自然边界对数据类型进行对齐；换而言之，32 位的数据类型在 64 位系统上要按照 32 位边界进行对齐，而 64 位的数据类型在 64 位系统上则要按照 64 位边界进行对齐。
这意味着诸如结构或联合之类的数据对象的大小在 32 位和 64 位系统上是不同的。
∙基本数据类型的大小。
通常关于基本数据类型之间关系的假设在 64 位数据模型上都已经无效了。
依赖于这些关系的应用程序在 64 位平台上编译也会失败。
例如，sizeof (int) = sizeof (long) = sizeof (pointer) 的假设对于 ILP32 数据模型有效，但是对于其他数据模型就无效了。
总之，编译器要按照自然边界对数据类型进行对齐，这意味着编译器会进行“填充”，从而强制进行这种方式的对齐，就像是在 C 结构和联合中所做的一样。
结构或联合的成员是根据最宽的成员进行对齐的。
清单 1 对这个结构进行了解释。
清单 1. C 结构struct test {int i1;double d;int i2;long l;}表 2 给出了这个结构中每个成员的大小，以及这个结构在 32 位系统和 64 位系统上的大小。
随着软件对计算机主存的需求的扩张，32位平台的4G主存寻址空间逐渐成为机器性能的瓶颈，长期来看，解决这一矛盾的最优方案是使用支持更大主存空间的软件运行平台。
就当前来所，PC机上支持更大地址空间的硬件平台就是x64了，当然除了硬件外还需要64位的操作系统和运行时库的支持，才能运行64位的应用程序，本文将主要讲解windows环境下的软件如何升级至x64版本。
1. 准备工作为了保证升级过程顺利进行，需要一些资源。
1.1 目标平台为了运行和测试64位的软件，需要相应的支撑平台。
硬件：需要支持64位运算的处理器如amd64构架或Intel 64构架。
操作系统：64位操作系统，这里只讨论windows平台，微软从windows xp以后所有的操作系统都有相应的64位版本，本文以Windows XP 64bit Edition为例。
目标操作系统可以安装在物理机器上，也可以使用虚拟机安装，当然硬件都必须支持64位才可以，另使用虚拟机安装64位系统时，需要处理器支持虚拟化技术。
运行时库：需要64位运行时库，这可以从编译环境获得。
1.2 编译器这里需要到目标平台的编译器，即x64编译器，编译器本身不一定是64位的；除编译器外，对应的开发库和头文件也是必须的，为了方便，最好使用集成开发环境，如visual Studio，自vs2005后开始有64位编译器（vs本身是32位的），但默认不会安装，如果已安装vs2008(或2005/2010)，则通过重新运行安装程序添加删除功能，添加x64编译器即可，如下图：2. 配置x64编译选项2.1 增加x64目标平台打开需要移植的项目，在解决方案管理器中，项目节点单击右键选择属性，打开项目属性对话框，并打开配置管理器，如下图：在“活动解决方案平台”下拉列表中选择新建，打开“新建解决方案平台”对话框：在新的平台中选择x64，并从现有win32平台复制且创建新的项目平台，单击确定，即完成平台的创建。
从 32 位平台移植到 64 位平台的解决方案概述移植的原因由于高性能服务器、数据库管理系统、电脑辅助设计工具，以及数字内容创作 工具等应用方案均需要处理大量数据及占用存储器大量地址，因此为了满足这类 应用方案的需要， 64 位技术便应运而生。
大约从九十年代后期起 ,就已经有 64位机器问世 , 从去年到今年 ,Intel 体系结 构的芯片也开始出 64 位了 . 在 UNIX 环境下 , 已有几种操作系统支持 64 位环境了 , 据说微软也准备将 Windows 升级为64位操作系统。
可以预料，将来32位平台将不 再是主流 , 唱主角的将是 64 位平台。
到时 , 客户环境也将全是 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位应用程序：基于因特网的应用、电子商务应用、 W eb 服务器、多媒体服务器、一般服务器、实时系统 .(这些应用可从 OS 提供的大内 存获得性能提高，因为OS 会自动地为每个32位应用提供更多的内存与 I/O 资 源.因此,64位系统能运行更多的并发的 ,大的 32位应用程序 . 移植原则移植后的程序既可作为 64位机器上的 32位程序运行 , 又可作为 64位机器上的 64 位程序运行 ; 只要觉得有需要 , 就可将 32 位程序重编译为 64 位程序 ; 在64位平台上 ,不管是作为 32位程序还是作为 64位程序运行 ,其性能至少不 应比 32 位程序在32 位平台上运行的性能差 ;32 位进程与 64 位进程可同时在 64 位平台上运行 .1. 2.3.移植步骤将现有32位程序移植到64位时,由于AIX本身对32位程序与64位程序的支持, 所以绝大部分的系统调用与 C 语言程序结构都不用改变, 只要在源程序中遵守系统调用接口与相应的数据类型;但是,还是有一些由于数据类型长度的改变而引起的兼容性问题.因此从32位程序移植为64位程序一般必须经过下列步骤:(1). 源程序的兼容性检查;这一步主要检查由于数据类型长度改变而引起的兼容性问题;(2). 将从第(1) 步检查出的兼容性源程序进行修改;(3). 修改makefile 文件;二、32 位平台与64 位平台1.平台的定义计算机系统是由硬件与软件两部分组成的。
所谓平台也就是指硬件与相应的系统软件(包括操作系统、编译器和与开发环境有关的应用程序(如数据库)) 。
64 位硬件体系结构是指:(1).能处理64位数据.---即CPU可以将64位数据作为基本单元进行处理(只需一次操作就可处理), ”字长”是64 位的，即存储单元是64 位的.( 说明:32 位平台的存储单元是32位的)这导致结构成员的一种以8字节为边界的填充,即第一个成员即使不足一个8字节的基本存储单元,那么仍占用一个基本存储单元,而整个结构占用的存储空间也是8 字节的倍数.(2). 能产生64 位地址. -包括有效地址和物理地址.注意:虚地址概念并不是由处理器体系结构说明的，它是由AIX的VMM虚地址存储管理器)说明的.它规定了应用程序可访问的内存空间的大小. 一般来说, 虚地址可以与有效地址或物理地址不同. 相应地,32 位硬件体系结构是指(1). 能将32位数据作为基本数据单元进行处理;(2). 最多只能产生32 位地址( 包括有效地址和物理地址).下列操作可从64 位寄存器中得到好处:(1).64 位长的串;(2).64 位寄存器上的移位操作;(3).64 位的整数和指针运算;(4). 串或大数据的拷贝.硬件部分主要是指其字长 ---- C PU 能作为基本数据单元处理的二进制数据的位数。
如32位机器其CPU能在一条指令内处理32位数据，它不能在一条指令内处理64位数据,它必须将64位数据分为两个32 位数据进行处理;而64位机器其CPU 则能在一条指令内处理64 位数据, 它不需象32 位机器一样, 将64 位数据拆分为两个32 位数据进行处理。
32 位平台是指其硬件体系结构是32 位的, 而且其操作系统、编译器等系统软件也只能支持32 位程序.64 位平台是指其硬件体系结构是64 位的, 而且其操作系统、编译器等也能支持64位程序.因而,64 位平台能充分利用其64位硬件的性能,使得一些应用程序能从中得到性能的改善.2.现有AIX64 位平台的特点i.RS/6000 64 位机器AIX 和RS/6000 S70模型)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 位指令集来模拟或仿真 ;AIX 64 位体系结构的好处(1)64 位数据类型某些应用程序可从64位整型硬件的性能和更高的精度获益; 不过主要的可能还是由非64位应用程序用64 位整型运算操纵64 位指针.(2) 存取大文件--- 数据仓库、科学和多媒体应用经常需要非常大的文件和文件系统, 它们很容易由64 位数据类型处理;巨大的地址空间---有些应用程序既需要用大内存(2 34=16GB),也需要访问海量虚拟存储(280), 许多科学应用就可以简单地编程, 并能比较高效地执行. 数据段和堆栈都是巨大的, 存储映射也会得到显著改善.支持64 位程序的操作系统①提升了 4GB的系统内存限制.4GB(2 32)是对32位PowerPC'平台的限制；.AIX支持＞4GB的内存；.AIX 在RS/6000 S70服务器上支持 16GB内存；. 当内存足够时 ,AIX 会自动扩展至大内存 ;.32位程序仍受限于＜4GB的内存；.在S70上,可有多个32位程序每个都有至多 4GB的内存；.换句话说，一个大的32位的应用程序可充分利用任何＞4GB的内存；.64 位程序可存取 260B 的内存 .. 应用程序地址空间可大于 4GB. 在 S70 且安装 AIX 的系统上被编译为 64 位的程序 ;. 对超出 32 位寻址范围的应用程序 .②不必为担心性能而重新编译. 在64位平台上 ,将 32位程序重新编译为 32位时,其性能会无任何差别 ,因为这会任何编译器的改进 ;.32 位重新编译为 64 位时 , 会看到些微的性能差别 ;. 默认编译模式是产生 32 位可执行程序 .③AIX核心是32位，在64位平台上有附加的64位扩展；. 为支持完全 64 位功能 , 核心不一定要求是 64 位的 ;.32 位核心维持对 32 位的兼容性和健壮性 ;. 核心扩展提供了 64 位程序所要求的功能 ;. 新的应用程序二进制接口 (ABI);. 提供了对设备驱动程序的二进制兼容性 ;.VMM支持64位进程地址空间；. 只要有必要 , 某些系统调用可修改为 64 位参数 (如文件和内存操作 );. 对某些设备驱动程序有一些前提或限制 .④32位与64位进程的完全互操作性1.进程 --- 进程. 可共享文件 . 内存 ,IPC 资源 (但要注意某些共享内存的分配方式 --- 字节边界问题 ), 也可相互发信号 ;. 可相互 exec() 调用 ;.32 位与 64 位进程可设置非本类进程的限制 ;2.32 位与64 位系统结构. 编译器仍是32 位的;. 编译器既可在32 位平台, 也可在64 位平台上运行;. 既可产生32 位, 也可产生64 位可执行文件.. 头文件已被修改过, 以支持两种环境;. 增强了功能的共享库的体系结构.. 两种环境下都用同样的路径;. 只维护单一的源程序,makefile 文件, . 管理共享库的工具默认为32 位的.⑤32位与64位核心支持.AIX 既支持32位的虚地址空间又支持64 位的虚地址空间;.包含VMM与进程调度和其他功能；.32 位进程与64 位进程对系统设备都有同等访问权利;. 默认行为都是32 位兼容的；. 进程调用设备驱动程序一般被核心分隔.⑥能在32 位机器上运行64 位程序吗?. 显然不能；. 不过, 在32 位机器上编译与链接64 位程序是可能的( 假如相关的库等等已安).⑦AIX命令与工具.绝大多数AIX命令与工具仍是32位的；. 需支持64 位的绝大多数工具也仍是32 位的；. 所有命令与工具将继续支持32 位；.编译器与连接程序支持64位的(注意:这并不意味着二者是64位的).ii. 原有32 程序与新的64 位程序的二进制兼容性原有 32 位程序可不用重编译 , 即可在 AIX 中继续作为 32 位程序运行 .(1). 在 AIX 中,32 位程序完全的二进制兼容性；.现存 32位程序毋须修改或重新编译 ,就可在 64位平台上运行；.32 位模式下 ,百分之百的兼容性；即在 64平台上编译的 32位程序与 32位平台上编译的 32 位程序都可在 64 位平台上共存运行；.32 位程序无任何性能下降 ,即32位程序不管是在 32位平台上运行 ,还是在 64位平台上运行 , 其性能无可分辨的差别 ..(2). 64 位与 32 位的共存.AIX 在 64 位平台中提供两种应用环境；这两种应用环境是互补而非竟争的环境；64位环境是向上兼容的 AIX的附加，比AIX低的版本不支持 64位程序；并不强迫所有应用都是 64 位的 .32位与64位进程的完全共存，在64位平台上既可运行 32位进程，又可运行64位进程,两种进程各有自己的运行环境；3.64位编程i.标准有关64位编程有两个标准，UNIX98标准与LP64协议.前者说明UNIX系统调用与C 标准库函数的标准接口，各库函数接口并不隐含数据类型是32位的, 而是依协议IPL32确定其类型；后者说明64位编程C语言类型.1.数据类型标准LP64类型从上表可看出：LP64模式中，char,short,int 这三种数据类型与32位程序相应的数据类型完全一样；而long型与指针则变成64位,相应地在32位程序中,long 与指针是32位的丄P64是一个一般的64位程序数据类型标准；不过,AIX 用的是IPL32+long long int; 见下表：(1) Depend on the setting of the long double option. By default, the size is 8.⑵ ANSI fixed-size types.(3) Should not be used; use ANSI types instead.说明其中粗体部分表明在32位与64位程序中长度有异,AIX为使其C++与Microsoft 兼容,使用了__int8/16/32/64 数据类型，在UNIX环境下一般应使用ANXI C数据类型，这包括在头文件<>中.很明显,64位程序与32位程序最大的不同就是:long与指针两种数据类型的长度不同，当然那些由long间接定义的数据类型其长度也跟着不同.在32位程序中,in t ,lo ng ,po in ter 三种数据类型的长度是一样的；三者相互赋值不会有影响；但在64位程序中，int 长度只有4B,而Iong,pointer 长度却有8B,而且有些由long typedef的数据类型也是8B,从而在int与long或pointer之间赋值就会导致错误，特别是有些由long typedef 的数据类型常常用作函数参数,如果相应参数在程序中被定义为int, 无疑会导致兼容性问题•2..结构分配问题我们知道，在32位程序中，结构数据有一种字边界填充的定位问题：即一个结构的第一个成员一定位于字边界上，即使该成员实际占用空间并不需要一个字长的存储空间，也会分配一个字长的存储空间，剩余空间由编译器填充；并且整个结构所占空间也应位于字长边界上;如struct struc32{int I;long j;char c;};这个结构长度是12B,即sizeof(struc32)=12; 其最后一个成员虽只有一个字节，但也分配4个字节；同样地，在64位程序中，也存在结构填充问题；只不过不是以字为边界，而是以双字为边界；如struct struc64{int I;long j;char *p;}；在32位程序中，这个结构的长度是12B,在64位程序中，其长度是24B;第一个成员只占4B,但编译器也给它分配8B空间.值得注意的是：在64位程序下，某些结构只成员一样，但成员位置不同时，其长度也会不同；如struct li{long la;int ia;} li；struct lii{long la;int ia;int ib;} lii;struct ili{int ia;long la;int ib;} ili;注意ili 与lii 两个结构变量: 在64 位程序中,sizeof(struct lii)=16;sizeof(structili)=24;在64 位程序中, 对结构成员的恰当排列, 有可能减少程序所占空间.ii.OBJ文件格式1.定义在32位程序中，经过编译器编译生成的.0文件，一般是COFF格式(Common ObjectFormat File), 但AIX 为支持64 位程序,其.o 文件格式为XCOFF(extended CommorObjectFormat File);它组合了COFF格式与模块格式内容表(TOC)两部分；后者提供了.o文件的动态连接与单元代替.XCOFF文件格式的主要优点就是它能提供对共享库和其他外部.o文件的动态解析引用.而一般地,COFF格式文件只能静态引用.XCOFF格式文件定义了.o文件与可执行文件的机器内存映象的排列方式，它是由语言处理器(ASM与编译器)生成的，绑定器将单个的.o文件组装形成可执行文件，装载程序将XCOFF格式的可执行文件读进内存，形成程序的内存映象，符号调试器读这个XCOFF的可执行文件，以提供程序内存映象中的变量与函数的符号引用这种文件格式只能由AIX 及以上版本才能生成及装载; 当在64 位模式下编译时，编译器生成64位指令并产生64位XCOFF格式.o文件，此时绑定器只绑定64 位.0文件以生成64位可执行文件.注意，在绑定到一起的.o文件中，不管是静态绑定还是动态绑定，都只能是同一格式的.o文件，即32位的.o文件与64位的.o文件的混合绑定是不允许的.(所谓64位模式，是指生成64位指令，产生64位XCOFF格式文件)AIX将XCOFF［乍为32位与64位程序的.o文件格式，从而有XC0FF3与XCOFF64 之分，在RS/6000 32位平台或64位平台上，AIX 的编译器默认为32位模式，即经编译所得的目标文件是32位的；不过，AIX的cc编译器在调用连接程序ld生成可执行程序时，ld 将只是把同类的.o 文件(包括库文件)连接成可执行程序，即要么是XCOFF32格式的.o文件，要么是XCOFF6餡式的.o文件.AIX的cc的这个特性要求：如果库是XCOFF32格式的文件，那么所有用到这个库的可执行程序就只能编译为32 位的；如果共享库的某个可执行程序要编译为64 位的，那么与这个共享库有关的所有可执行程序都要编译为64位的；不允许共享库某个32位库的可执行程序编译为32位的，而另一个共享该库的可执行程序却编译为64 位的.不过，在AIX中，有少数几个命令既支持32位XCOFF格式同时又支持64位XCOFF格式(即混合模式)，这些命令有ar，dump，.nm，lorder，ranlib，size，strip.它们都用-X 标志(-X32，-X64，-X32_64) 来说明.o 文件格式.ar 支持两种x(X) 标志.-x表示从档案库中抽出所指定的文件并放到当前目录；而-X标志则指定编译iii.编译一般来说，AIXAIX编译器cc有许多编译选项，这里只简单介绍一些与64位有关的编译选项•(1).-q64 选项：有这个编译开关时，所编译生成的.0或可执行程序将是64位的；否则，默认为32位的；(2).-qwarn64 选项:这个编译选项既可在32位模式下使用，也可在64位模式下使用；使用这个可用来检查源程序中64位的兼容性，它对与64位不兼容的代码给出警告;在从32位移植到64位时，这个编译选项是非常有用的；(3).-除了编译选项外，在32位模式与64位模式间转换，还有以下方法：环境变量OBJECT_MODE(=32 64 32_64)--- 分别表示32位模式、64位模式编译;32_64表示既可接受32位模式，也可接受64位模式，不过在这种模式下,AIX 连接程序与装载程序不会将这种目标程序连接成可执行程序配置文件/etc/在AIX下是/etc/,它定义了编译器的许多编译选项；命令行参数这三种方式中，以环境变量最优先，其次是配置文件，最后是命令行参数.ar命令用于生成库，即将.o文件放到一个库中，由于.o文件有两种模式，即32位与64位，默认情况下，ar处理32位.o文件，用-X(32,64,32_64)选项可使其处理64 位.0文件，即生成64位库；如果对同一个makefile文件,先在32位模式下运行产生一个32位库，然后又想运行make 产生一个64位库时，这个64位库将不会被更新.因为make只认时间戳，而不区分.o文件格式是32位还是64位.而且如果将同名的一个32位和64位.o 文件加到同一个库时，会出现问题.4.32位程序与64位程序在RS/6000 AIX 中的二进制兼容性这实际上是指32位程序与64位程序在64位平台上的二进制兼容性，因为64位程序只能在64位平台上运行，不能在32位平台上运行.一般来说，用在任何32位处理器或64位处理器上的AIX编译的64位程序在64位处理器模式上不用重新编译就可运行；用在任何32位处理器或64位处理器上的AIX编译的32位程序在两种模式下都不用重新编译就可运行.下表列出了对32位程序与64位程序的兼容性问题.*序不须重新编译，就可在AIX的基于同样的或更新的同一系统的处理器上.不过,不包括下列情况：(1).AIX共享库的非共享编译；(2).AIX V4参考手册公开说明的不可迁移的部分；(3).文档未说明的AIX的内部特性；(4).X11R5服务器扩展(仅适用于AIX ；(5).用POWER或 PowerPC编译特性编译的程序又不是运行在POWEF或PowerPC平台上；(6).用AIX高版本编译的程序在低版本的 AIX上可能会运行不正常.从而,须运行在所有平台上的程序必须用编译器的公共选项.用POWER技术编译的程序必须运行在POWER平台上；用PowerPC技术编译的程序必须运行在PowerPC平台.5.64位编程的补充及注意事项(结构以字长为边界的填充)(1). 最好在常数后面加止后缀在64 位程序中, 常数一般被编译器默认为long 型,就象在32位程序中，常数被编译器默认为int型一样.可在常数后面加上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 longtypedef 的数据类型;(5). 含指针或long 或unsigned long 数据成员的结构的长度的改变这种改变一般都可由运算子sizeof 自动算出;但如果用”硬编码” (具体数字)也可能造成兼容性问题;(6)对long 或unsigned long 数据的移位或逻辑操作(&或|) 的长度位的设定三、移植步骤1. 移植步骤( 一). 移植步骤.将应用程序从32位移植到64位，一般有下列一些步骤，这些步骤并不意味着功能调整或扩展，只不过是如同32位程序一样的行为在64位模式下的解释，在这个过程之后要用扩展性能，你可能得修改源程序::(1). 程序和数据分析检查所有类型以决定这些数据类型应该是32位还是64位;对系统定义类型，其长度对系统调用/ 库调用是合适的; 对用户定义类型，32 位类型应该定义为int or unsigned int 或在64 位模式下仍是32 位的系统定义类型; 而用户定义的64 位类型应该定义为long or unsigned long 或系统定义的64 位的类型;(2). 修改数据类型将那些需要改变的数据类型改变为你所选择的类型，此时，要检查所有的算术运算以确保数据值的扩展和截短都是正确的; 确保没有作出任何指针适合int 类型.(3). 校验其他程序输出的使用确保所有被处理的数据在32位范围内;若不可能，则其他使用这些数据的程序必须移植到64 位或至少能意识到64 位.(4). 移去存储相关移去在下列情况下的存储相关性:程序正文段，数据段，程序堆，程序堆栈,errno,tok_of_stack 结构，共享库数据，共享库正文，和访管指令表；(5). 不好的地址用法当传递一个无效的地址给一个系统调用时，64 位进程将收到信号SIGSEGV(segmentation violation) 而不是EFAULT类型的错误号(14无效的地址);任何依赖于系统调用来保护无效地址的地方都应该删除.(6). 调试与测试测试程序以确定程序与在32 位平台上的行为完全一样;若有差别，则调试程序.返回第一步在选定数据类型时，如果你要求某些数据类型长度在32位与64位模式下保持一致，比如都是32 位, 那么有如下三个数据类型:__long32_t,__ulong32_t,ptr64,前两个在头文件/usr/include/ 中定义, 后者在头文件/usr/include/sys/ 中定义;在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 型用__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 中是unsigned long.(2). 未加后缀的常数象95 (UINT_MAX)这样的数在32位模式下,编译器认为是signed long 类型的；但在64 位模式下, 会被当作signed long 类型, 占8B, 这会使得某些操作, 如sizeof(95) 返回8;纠正措施是，将95写为95U,此时，编译器会将它作为unsigned int 类型的数.在64 位模式下, 若是16 进制的无后缀常数, 则常常会被当作64位的; 在移植程序时, 要记住这一点. 所有可能影响常数赋值的常数都应该明确地加上后缀, 对所有数字用后缀或类型可使程序不致出现非期望的行为.(3). 指针,int在32位模式下,in t,l ong 和指针可相互赋值；在32位扩展模式(XCOFF)中,int ,long 可赋值给指针，而将指针赋值给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). 在做移位或位操作时, 消除任何对long 位数的假定；(iv). 消除 C int( 包括从int 导出的类型)可传递给一个未声明的long 或指针参数的假定；(v). 消除任何未声明的函数会返回long 或指针的假定.2.源程序64 位兼容性检查将32 位程序移植为64 位程序时, 其主要问题集中在程序中使用含指针和/ 或int类型的数据成员, 以及由long typedef 的其他数据类型, 和一些含long typedef 类型参数的系统调用,在程序中这些参数如果被定义为int 类型,就一定会出现兼容性问题, 还有一些返回指针的系统调用或用户自定义函数, 若其返回值在程序中被赋值给int 类型的变量也会造成兼容性问题. 因此, 在开始编译为64位程序之前, 对源程序进行兼容性检查是非常必要的.i.lint - t选项检查兼容性用lint - t “源程序”可检查有问题的赋值，从32位移植到64位时,用这个命令可检查以下一些兼容性问题:(1). 函数未声明原型函数原型可使编译器和lint 标志出未匹配的参数;(2). 将long 或指针赋值给int。
