📄 64bit.html
字号:
<html><head><!-- Copyright 1997,1998, The Open Group, All Rights Reserved --><!-- Generated by The Open Group's RHTM tool v1.2.1 --><title>Data Size Neutrality and 64-bit Support </title><BODY BGCOLOR=#FFFFFFFF"><basefont size=3><h2>Data Size Neutrality and 64-bit Support</h2><p>The Single UNIX Specification, Version 2 provides enhanced support for 64-bit programming modelsby being n-bit clean and data size neutral.This article is a brief introduction to 64-bit programming models,data size neutrality, and application porting issues.<h3>Introduction</h3><p>When the UNIX operating system was first created in 1969 it wasdeveloped to run on a 16-bit computer architecture.The C language of the time supported 16-bit integer and pointer datatypes and also supported a 32-bit integer data type that could beemulated on hardware which did not support 32-bit arithmetic operations.<p>When 32-bit computer architectures, which supported 32-bitinteger arithmetic operators and 32-bit pointers, were introducedin the late 1970s, the UNIX operating system was quickly ported to this newclass of hardware platforms.The C language data model developed to support these 32-bit architecturesquickly evolved to consist of a 16-bit short-integer type,a 32-bit integer type, and a 32-bit pointer.During the 1980s, this was the predominant C data model availablefor 32-bit UNIX platforms.<p>To describe these two data models in modern terms, the 16-bit UNIXplatforms used an IP16 data model, while 32-bit UNIX platforms use theILP32 programming model.The notation describes the width assigned to the basic data types;for example, ILP32 denotes that<B>int</B>(I),<B>long</B>(L), and<B>pointer</B>(P) types are all 32-bit entities.This notation is used extensively throughout this article.<p>The first UNIX standardization effort was begun in 1983 bya /usr/group committee.This work was merged into the work program of the IEEE POSIX committeein 1985.By 1988, both POSIX and X/Open committees had developed detailedstandards and specifications that were based upon the predominantUNIX implementations of the time.These committees endeavored to develop architecture-neutral definitionsthat could be implemented on any hardware architecture.<p>The transition from 16-bit to 32-bit processor architectures happenedquite rapidly just before the UNIX standardization work was begun.Since the specifications were based on existing practice and thepredominant data model did not change during this gestation period,some dependencies upon the ILP32 data model were inadvertentlyincorporated into the final specifications.<p>Most of today's 32-bit UNIX platforms use the ILP32 data model.However another data model, the LP32 model, is also very popularfor other operating systems.The majority of C-language programs written for Microsoft Windows 3.1are written for the Win-16 API which uses the LP32 data model.The Apple Macintosh also uses the LP32 data model.<p>32-bit platforms have a number of limitations which are increasinglya source of frustration to developers of large applications, such asdatabases, who wish to take advantage of advances in computer hardware.There is much discussion today in the computer industry about thebarrier presented by 32-bit addresses.32-bit pointers can only address 4GB of virtual address space.There are ways of overcoming this limitation, but application developmentis more complicated and performance is significantly reduced.Until recently the size of a data file could not exceed 4GB.However, the 4GB file size limitation was overcome by the LargeFile Summit extensions which are included in XSH, Issue 5.<p>Disk storage has been improving in real density at the rate of70% compounded annually, and drives of 12GB and larger are readily available.Memory prices have not dropped as sharply, but 64MB chips arereadily available, with larger chips in active development.CPU processing power continues to increase by about 50% every 18 months,providing the power to process ever larger quantities of data.This conjunction of technological forces, along with the continueddemand for systems capable of supporting ever larger databases andsimulation models and full-motion video, have generated requirements forsupport of larger addressing structures.<p>A number of 64-bit processors are now available, and the transitionfrom 32-bit to 64-bit architectures is rapidly occurring amongstall the major hardware vendors.64-bit UNIX platforms do not suffer from the file size or flataddress space limitations of 32-bit platforms.Applications can access files that occupy terabytes of disk spacebecause 64-bit file offsets are possible.Similarly, applications can now theoretically access terabytes ofmemory because pointers can be 64 bits.More physical memory results in faster operations.The performance of memory-mapped file access, caching, and swapping,is greatly improved.64-bit virtual addresses simplify the design of large applications.All the major database vendors now support 64-bit platforms becauseof dramatically improved performance for very large databaseapplications available on very large memory (VLM) systems.<p>The world is currently dominated by 32-bit computers, a situation thatis likely to continue to exist for the near future.These computers run 16 or 32-bit applications or some mixture of the two.Meanwhile, 64-bit computers will run 32-bit code, 64-bit code, ormixtures of the two (and perhaps even some 16-bit code).New 64-bit applications and operating systems must integrate smoothlyinto this environment.Key issues facing the computing industry are the interchange ofdata between 64 and 32-bit systems (in some cases on the same system)and the cost of maintaining software in both environments.Such interchange is especially needed for large application suitessuch as database systems, where one may want to distributemost of the applications as 32-bit binaries that run across a largeinstalled base, but be able to choose 64-bits for a few crucial applications.<h3>64-bit Data Models</h3><p>Prior to the introduction of 64-bit platforms, it was generallybelieved that the introduction of 64-bit UNIX operating systems wouldnaturally use the ILP64 data model.However, this view was too simplistic and overlooked optimizationsthat could be obtained by choosing a different data model.<p>Unfortunately, the C programming language does not provide a mechanismfor adding new fundamental data types.Thus, providing 64-bit addressing and integer arithmetic capabilitiesinvolves changing the bindings or mappings of the existing data typesor adding new data types to the language.<p>ISO/IEC 9899:1990, Programming Languages - C (ISO C) left the definition of the<B>short int</B>,the<B>int</B>,the<B>long int</B>,and the<B>pointer</B>deliberately vague to avoid artificially constraining hardwarearchitectures that might benefit from defining these data typesindependent from the other.The only constraints were that<B>int</B>smust be no smaller than<B>short</B>s,and<B>long</B>smust be no smaller than<B>int</B>s,and<B>size_t</B>must represent the largest unsigned type supported by an implementation.It is possible, for instance, to define a<B>short</B>as 16 bits, an<B>int</B>as 32 bits, a<B>long</B>as 64 bits and a<B>pointer</B>as 128 bits.The relationship between the fundamental data types can be expressed as:<p><I>sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long) = sizeof(size_t)</I><p>Ignoring non-standard types, all three of the following64-bit pointer data models satisfy the above relationship:<ul><p><li>LP64 (also known as 4/8/8)<p><li>ILP64 (also known as 8/8/8)<p><li>LLP64 (also known as 4/4/8).<p></ul><p>The differences between the three models lies in the non-pointerdata types.The table below details the data types for the above three data modelsand includes LP32 and ILP32 for comparison purposes.<pre><P><table bordercolor=#000000 border=1 align=center><tr valign=top><th align=center> <b>Data Type</b><th align=center> <b>LP32</b><th align=center> <b>ILP32</b><th align=center> <b>ILP64</b><th align=center> <b>LLP64</b><th align=center> <b>LP64</b><tr valign=top><td align=left> <b>char</b><td align=left> 8<td align=left> 8<td align=left> 8<td align=left> 8<td align=left> 8<tr valign=top><td align=left> <b>short</b><td align=left> 16<td align=left> 16<td align=left> 16<td align=left> 16<td align=left> 16<tr valign=top><td align=left> <b>int32</b><td align=left> <td align=left> <td align=left> 32<td align=left> <td align=left> <tr valign=top><td align=left> <b>int</b><td align=left> 16<td align=left> 32<td align=left> 64<td align=left> 32<td align=left> 32<tr valign=top><td align=left> <b>long</b><td align=left> 32<td align=left> 32<td align=left> 64<td align=left> 32<td align=left> 64<tr valign=top><td align=left> <b>long long (int64)</b><td align=left> <td align=left> <td align=left> <td align=left> 64<td align=left> <tr valign=top><td align=left> <b>pointer</b><td align=left> 32<td align=left> 32<td align=left> 64<td align=left> 64<td align=left> 64</table></pre><p>When the width of one or more of the C data types is changed,applications may be affected in various ways.These effects fall into two main categories:<ul><p><li>Data objects, such as a structure, defined with one of the 64-bitdata types will be different in size from those declared inan identical way on a 16 or 32-bit system.<p><li>Common assumptions about the relationships between the fundamentaldata types may no longer be valid in a 64-bit data model.Applications which depend on those relationships often cease to workproperly when compiled on a 64-bit platform.A typical assumption made by many application developers is that:<p><I>sizeof(int) = sizeof(long) = sizeof(pointer)</I><p>This relationship is not codified in any C programming standard, but itis valid for the ILP32 data model.However, it is not valid for two of the three 64-bit data modelsdescribed above, nor is it valid for the LP32 data model.<p></ul><p>The ILP64 data model attempts to maintain the relationship between<B>int</B>,<B>long</B>,and<B>pointer</B>which exists in the ILP32 model by making all three types the same size.Assignment of a pointer to an<B>int</B>or a<B>long</B>will not result in data loss.<p>The downside of this model is that it depends on the addition of anew 32-bit data type such as<B>int32</B>to handle true 32-bit quantities.There is thus a potential for conflict with existing<B>typedef</B>sin applications.An application which was developed on an ILP32 platform, andsubsequently ported to an ILP64 platform, may be forced to makefrequent use of the<B>int32</B>data type to preserve the size and alignment of data because ofinteroperability requirements or binary compatibility withexisting data files.<p>The LLP64 data model preserves the relationship between<B>int</B>and<B>long</B>by leaving both as 32-bit types.Data objects, such as structures, which do not contain pointers willbe the same size as on a 32-bit system.This model is sometimes described as a 32-bit model with 64-bit addresses.Most of the run-time problems associated with the assumptions betweenthe sizes of the data types are related to the assumption that apointer will fit in an<B>int</B>.To solve this class of problems,<B>int</B>or<B>long</B>variables which should be 64-bits in length are changed to<B>long long</B>(or<B>int64</B>),a non-standard data type.This data model is thus again dependent on the introduction of a newdata type.Again there is potential for conflict with existing<B>typedef</B>sin applications.<p>The LP64 data model takes the middle road.8, 16, and 32-bit scalar types (<B>char</B>,<B>short</B>,and<B>int</B>)are provided to support objects that must maintain size andalignment with 32-bit systems.A 64-bit type,<B>long</B>,is provided to support the full arithmetic capabilities, and isavailable to use in conjunction with pointer arithmetic.Applications that assign addresses to scalar objects need to specifythe object as<B>long</B>instead of<B>int</B>.<p>In the LP64 data model, data types are natural.Each scalar type is larger than the preceding type.No new data types are required.As a language design issue, the purpose of having<B>long</B>in the language anticipates cases where there is an integral typelonger than<B>int</B>.The fact that<B>int</B>and<B>long</B>represent different width data types is a natural and common senseapproach, and is the standard in the PC world where<B>int</B>is 16-bits and<B>long</B>is 32-bits.<p>A major test for any C data model is its ability tosupport the very large existing UNIX applications code base.The investment in code, experience, and data surrounding theseapplications is the largest determiner of the rate at which newtechnology is adopted and spread.In addition, it must be easy for an application developer tobuild code which can be used in both existing and new environments.<p>The UNIX development community is driven technically by a setof API agreements embodied in standards and specifications documentsfrom groups such as X/Open, IEEE, ANSI, and ISO.These documents were developed over many years to codify existingpractice and define agreement on new capabilities.As a result these specifications are of major value to the systemdevelopers, application developers, and end-users.There are numerous test suites which verify that implementations correctlyembody the details of a specification and certify that fact tointerested parties.Any 64-bit data model cannot invalidate large portions of thesespecifications and expect to achieve wide adoption.<p>A number of vendors have extensive experience with the LP64 data model.By far, the largest body of existing 32-bit code already modifiedfor 64-bit environments runs on LP64 platforms.Experience has shown that it is relatively easy to modify existingcode so that it can be compiled on either an 32-bit or 64-bit platform.Interoperability with existing ILP32 platforms is well proven andis not an issue.At least one LP64-based operating system (Digital UNIX V4.0)has met and passed the majority of existing verification suites andhas obtained the UNIX 95 brand.<p>A small number of ILP64-based platforms have also shipped.These have demonstrated that it is feasible to complete theimplementation of an ILP64 environment.⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -