test

Solaris（64 位）开发者指南

第 2 章 何时使用 64 位

对于应用程序开发者，Solaris 64 位和 32 位操作环境之间的主要区别在于所使用的 C 数据类型模型。64 位版本使用 LP64 模型，其中类型为 long 的数据和指针是 64 位。其他所有基础数据类型仍然与基于 ILP32 模型的 32 位实现中的数据类型相同。在 ILP32 模型中，类型为 int、long 的数据和指针是 32 位的。第 3 章，比较 32 位接口和 64 位接口中将对这些模型进行更详细地介绍。

只有极少数的应用程序真正要求进行转换。大多数应用程序都可以保留为 32 位应用程序，并且仍可以在 64 位操作系统上运行，而无需对代码进行任何更改或重新编译。实际上，不需要 64 位功能的 32 位应用程序应保留为 32 位，以便最大程度地提高可移植性。

对于具有以下特征的应用程序，可能需要进行转换：

对于具有以下特征的应用程序，可能需要进行转换：

对于某些特定的互操作性问题需要对代码进行更改。同样，如果应用程序使用大于 2 GB 的文件，请考虑将其转换为 64 位应用程序，而不要直接使用大文件 API。

这些项将在以下几节中进一步介绍。

主要功能

为了说明 Solaris 操作环境同时支持 32 位和 64 位，下图并排显示了两个栈。左边的系统仅支持在使用 32 位设备驱动程序的 32 位内核中运行 32 位库和应用程序。右边的系统所支持的 32 位应用程序和库与左边的系统相同。该系统还同时支持使用 64 位设备驱动程序的 64 位内核顶部的 64 位库和应用程序。

图 2–1 Solaris 操作环境体系结构

该图显示 Solaris 操作环境中对 32 位和 64 位的支持

64 位环境的主要功能包括支持以下各项：

大虚拟地址空间

在 64 位环境中，一个进程最多可以使用 64 位（即 18 EB）虚拟地址空间。该虚拟地址空间大约是 32 位进程当前所使用最大空间的 40 亿倍。

注 –

由于存在硬件限制，因此某些平台可能不支持完全 64 位的地址空间。

大文件

如果应用程序只需支持大文件，则该应用程序可以保留为 32 位并使用大文件接口。但是，如果可移植性并不是主要问题，请考虑将应用程序转换为 64 位程序。64 位程序可以通过一整套接口来充分利用 64 位功能。

64 位运算

很久以前在早期发行版的 32 位 Solaris 中便已提供了 64 位运算。但是，64 位实现现在使用完全 64 位计算机寄存器来进行整数运算和参数传递。通过 64 位实现，应用程序可充分利用 64 位 CPU 硬件的功能。

取消系统限制

本质上，64 位系统接口的性能要优于一些等效的 32 位接口。对于担心 32 位 time_t 用完时间时会出现 2038 年问题的应用程序编程人员来说，可以使用 64 位 time_t。尽管 2038 年看起来还很遥远，但是，对于需要执行与将来事件（如抵押）有关的计算的应用程序，则可能需要扩展的时间功能。

互操作性问题

下面列出了一些互操作性问题，关于要求使应用程序对于 64 位安全，或者对应用程序进行更改，使其与 32 位和 64 位应用程序均能够互操作：

内核内存读取器

由于内核是在内部使用 64 位数据结构的 LP64 对象，因此，使用 libkvm、/dev/mem 或 /dev/kmem 的现有 32 位应用程序将无法正常工作，必须将其转换为 64 位程序。

/proc 限制

使用 /proc 的 32 位程序可以查看 32 位进程，但是无法识别 64 位进程的所有属性。描述该进程的现有接口和数据结构不够大，因此无法包含所涉及的 64 位值。此类程序需要重新编译为 64 位程序，以便使其可同时用于 32 位进程和 64 位进程。对于调试器来说，这是一个最为典型的问题。

64 位库

32 位应用程序必须链接到 32 位库，64 位应用程序必须链接到 64 位库。除已过时的库以外，所有系统库均提供了 32 位和 64 位两种版本。

评估转换工作

确定要将应用程序转换为完全 64 位程序之后，一定要注意，对于许多应用程序，只需执行很少的操作即可完成此目标。其余各章将讨论如何评估应用程序以及转换过程中所涉及的工作。