64位编程模型：为什么要使用LP64（二）

原文出自这里

评价标准

上一部分中描述的关于编程模型的选择可以由各个操作系统厂商自己决定，或者在各个操作系统厂商之间制定共同的标准。我们认为在开放式系统社区，64位系统的实现方式上如果有一个单一的标准，将有助于开发者提供更好的应用程序。这样的话可以在应用程序移植到64位环境的过程中避免很多问题，从而促进新技术的更快发展。并且现在正是一个制定统一标准的好机会，因为目前已经有64位产品的厂商（Digital和SGI）都是使用的同一个模型（LP64）,其他厂商还没有来得及推出使用其它编程模型的操作系统。

下面我们会给出关于评估标准的建议，并且尝试使用这些标注来评估了LP64和ILP64。在我们看来，LLP64并不是一个令人满意的值得被推广使用的模型，因为它需要大量修改现有的标准。

可移植性

编程模型的一个重要测试是——对于现有的开放式系统平台上大量代码库的支持能力。目前这些应用程序的开发者已经为此投入了大量资源，也将会由他们来决定接下来在64位环境下应该选择哪种编程模型。总之，应用程序开发人员必须能够很容易写出兼容现有的和新的应用环境的代码。

在可移植性方面，Digital和SGI已经将应用程序移植到基于LP64下积累了一定的经验。其中Digital的UNIX产品要求所有的应用程序都工作在LP64运行环境上。SGI的产品提供了一个同时支持ILP32和LP64的兼容环境，不过目前已经出货的SGI系统上的许多应用都已经使用的是LP64了。

Digital和SGI的经验都印证了相同的事实——Digital的经验表明ISV和客户可以将大量的代码移植到64位环境下，同时保证与其它32位终端的数据交互。SGI的经验表明，代码可以被优化成32和64位同时兼容的，而且能够在高耦合度的系统进程中进行数据交互。

尽管我们开始看到一些应用程序需要越来越大的虚拟地址空间，但是还没有对于64位整型数据的需求。现在大多数64位程序在修改之前都只能运行在32位系统中（通常是一些不同的UNIX版本），实际上它们都没有使用到64位的整型数。在这种情况下，64位整型数中的高32位数据空间都被浪费掉了。以后使用更大标量数据的应用程序将会使用long类型。

其它的程序语言将仍旧会继续使用32位整型数据。例如，FORTRAN-77要求INTEGER类型必须和REAL类型长度相同，并且是DOUBLE PRECISION（双精度数）长度的一半。这一点上，再加上用户的使用习惯，意味着即使是在64位硬件上，FORTRAN-77的实现必须将INTEGER定义为32位类型。有相当一部分应用程序同时使用C语言和FORTRAN——或者是相互调用，或者通过文件共享，而且这类应用是最早移植到64位环境的程序之一。经验表明，与FORTRAN代码相比，这样的应用程序中常常是更容易在C代码中修改数据大小和类型，而且我们也希望在应用程序的C代码中，无论int类型有多长，都有一个32位的整型数可以使用。

几乎所有的应用程序从32位系统迁移到64位系统时都会有些小改动，特别是如果代码中有关于int和指针数据长度相对大小的假定。我们也注意到关于int，char，short和float数据类型相对大小的假定不会再LP64上产生任何问题（因为这些数据类型的定义同32位系统中的定义完全相同），但是ILP64就会出问题。我们的经验表明，无论是LP64还是ILP64都不能提供完美的32位系统移植方案，但是不考虑其它因素的情况下，LP64使用更短的数据类型提供了更好的性能。

32位系统和64位系统的数据交互

多年来我们都认为计算机行业出货最多的是基于32位编程模型的系统。过去几十年中终端用户使用计算机系统积累了大量的数据，然而这是一项重要的投资。任何解决方案都必须易于持续性地使用这些数据。

不幸的是，ILP64并不能使用原有的数据结构来描述32位数据，它引入了一个不可移植的__int32类型来处理32位数据。如果不使用#ifdef结构区分，它可能会在开发同时兼容32位和64位代码的时候出外问题。但是将大量代码移植到LP64下就没有这个问题，即使是管理现有的数据集，甚至是在应用程序没有输出信息的情况下都可以完美移植。

大多数程序中现有的int类型在64位环境下仍然可以使用32位数据，只有少量的int类型数据需要与指针和long类型保持长度一致。在LP64下只有很少的代码需要修改。

在ILP64下，大多数的int型数据需要更改为__int32。但是__int32和32位下的int并不一样，它更像short类型，所有的操作必须转换成int（64位有符号整型）然后再进行64位运算。

所以，ILP64下的__int32和ILP32下的int类型并不一样，同LP64的int也不相同。不难看出，这些差异会导致细微的难以发现的错误。