64bit.html

unix 下的C开发手册,还用详细的例程。

However, as of early 1997, no LLP64 or ILP64-based systems have
achieved the same level of standards conformance or met the
requirements of the UNIX 95 brand.
<p>
Although the number of applications written in C requiring a large
virtual address space is growing rapidly, there has not been
a requirement to date for a 64-bit
<B>int</B>
data type.
The majority of existing 64-bit applications previously ran only
on 32-bit platforms, and had no expectation of a greater range for the
<B>int</B>
data type.
The extra 32 bits of data space in a 64-bit
<B>int</B>
would appear to be wasted.
Any future applications which require a larger scalar data type can
use the
<B>long</B>
type.
<p>
Nearly all applications moving from a 32-bit platform require some
minor modifications to handle 64-bit pointers, especially where
erroneous assumptions about the relative size of
<B>int</B>
and
<B>pointer</B>
data types were made.
Common assumptions about the relative sizes of
<B>int</B>,
<B>char</B>,
<B>short</B>,
and
<B>float</B>
data types generally do not cause problems on LP64 platforms
(since the sizes of those data types are identical to those on an
ILP32 platform), but do so on an ILP64 platform.
<p>
Other language implementations will continue to support a 32-bit
<B>int</B>
type.
For example, the FORTRAN-77 standard requires that the type INTEGER
be the same size as REAL, which is half the size of DOUBLE PRECISION.
This, together with customer expectations, means that FORTRAN-77
implementations will generally leave INTEGER as a 32-bit type,
even on 64-bit platforms.
A significant number of applications use C and FORTRAN together,
either calling each other or sharing data files.
Such applications have been amongst the first to move to 64-bit
environments.
Experience has shown that it is usually easier to modify the data
sizes and types on the C side than the FORTRAN side of such applications.
These applications will continue to require a 32-bit
<B>int</B>
data type in C regardless of the size of the
<B>int</B>
data type.
<p>
In 1995, a number of major UNIX vendors agreed to standardize on the
LP64 data model for a number of reasons:
<ul>
<p>
<li>
Experience suggests that neither the LP64 nor the ILP64 data models
provide a painless porting path from a 32-bit platform, but that
all other things being equal, the smaller data types in the LP64 data
model enable better application performance.
<p>
<li>
A crucial investment for end-users is the existing data built up
over decades in their computer systems.
Any proposed solution must make it easy to utilize such data on
a continuing basis.
Unfortunately, the ILP64 data model does not provide a natural way
to describe 32-bit data types, and must resort to non-portable
constructs such as
<B>int32</B>
to describe such types.
This is likely to cause practical problems in producing code which
can run on both 32 and 64-bit platforms without numerous
<B>#ifdef</B>
constructions.
It has been possible to port large quantities of code to LP64 platforms
without the need to make such changes, while maintaining the investment
made in data sets, even in cases where the typing information was
not made externally visible by the application.
<p>
<li>
Most
<B>int</B>s
in existing applications can remain as 32 bits in a
64-bit environment; only a small number are expected to be the same size as
<B>pointer</B>
or
<B>long</B>.
Under the ILP64 data model, most
<B>int</B>s
will need to change to
<B>int32</B>.
However,
<B>int32</B>
does not behave like a 32-bit
<B>int</B>.
Instead,
<B>int32</B>
is like
<B>short</B>
in that all operations have to be converted to
<B>int</B>
(64-bits, sign extended) and performed in 64-bit arithmetic.
Thus,
<B>int32</B>
in the ILP64 data model is not exactly the same as
<B>int</B>
in the ILP32 data model.
These differences may cause subtle and hard-to-find bugs.
<p>
<li>
Instruction cycle penalties are incurred whenever additional cycles
are required to properly implement the semantics of the intended data model.
For example, in the LP64 data model it is only necessary to perform
sign extension on
<B>int</B>
when you have a mixed expression including
<B>long</B>s.
However, most integral expressions do not include
<B>long</B>s
and compilers can be made smart enough to only sign extend when necessary.
<p>
<li>
<B>int</B>
is by far the most frequent data type to be found (statically
and sometimes dynamically) within C and C++ programs.
64-bit integers require twice as much space as 32-bit integers.
Applications using 64-bit integers consume additional memory and
CPU cycles transporting that memory throughout the system.
Furthermore, the latency penalty of 64-bit integers can be enormous,
especially to disk, where it can exceed 1,000,000 CPU cycles
(3 nsec to 3 msec).
The memory size penalty for unneeded 64-bit integers could therefore
be very high for some applications.
<p>
<li>
Portability, especially for combined FORTRAN and C applications,
is enhanced by the LP64 data model, and the most common types of
problems that can occur are susceptible to automatic detection.
<p>
<li>
Interoperability is improved by the ability to use a standard
data type to declare data structures that can be used in both
32-bit and 64-bit environments.
<p>
<li>
Standards conformance has been demonstrated both in the practical
sense by the porting of many programs and in the formal sense
of compliance with industry standards through verification test suites.
<p>
<li>
Transition from the current industry practice is smooth and
direct following a path grooved with experience and demonstrated success.
<p>
<li>
No new non-portable data types are required.
The data model makes natural use of the C fundamental data types.
<p>
</ul>
<h3>Data Size Neutrality</h3>
<p>
When it was understood that the Single UNIX Specification was constraining system implementations
that were other than ILP32, the relevant specifications were
reviewed and recommendations drafted to make these specifications
data size- and architecture-neutral.
These recommendations were incorporated into the Single UNIX Specification, Version 2 published in 1997.
<p>
The following is a summary of the changes that were made.
Changes are identified with respect to the CAE Specifications which
made up the previous version of the Single UNIX Specification.
<h4>System Interface Definitions, Issue 5 (XBD)</h4>
<p>
The following text was added to System Interface Definitions, Issue 4, Version 2 (XBD), Chapter 10, page 130,
point 6, as a fourth bullet item:
<pre>
<dl compact><dt> <dd>
&quot;Ranges greater than those listed here are allowed.&quot;
</dl>
</pre>
<p>
This section describes the argument syntax of the standard
utilities and introduces terminology used throughout the Single UNIX Specification
for describing the arguments processed by the utilities.
It was updated so that the maximum value of a numerical argument
is allowed to be greater than a 32-bit value, thus permitting support
of 64-bit values.
<h4>System Interfaces and Headers, Issue 5 (XSH)</h4>
<p>
Two general changes were made to System Interfaces and Headers, Issue 4, Version 2 (XSH):
<ul>
<p>
<li>
Use of the type
<B>int</B>
for return values, arguments, and structure members.
<p>
Several functions using the type
<B>int</B>
for return values, arguments, or structure members are not able
to represent 64-bit values correctly on architectures implementing
an LP64 data model.
Where alternate functions were available which do not have this
limitation, the functions were marked LEGACY and the alternate functions
noted in the Application Usage section.
Where no alternative function was available, the types were changed
in a data model-neutral manner to overcome this limitation.
<p>
<li>
<B>size_t</B>
<I>versus</I>
<B>ssize_t</B>.
<p>
Several functions have a parameter declared to be
<B>size_t</B>
where the parameter specifies the length of an object to manipulate,
and returns the portion of the length of the object processed in a type
<B>ssize_t</B>.
The type
<B>ssize_t</B>
is required so that a negative return value can be used to
indicate an error.
However, in these functions it is possible for the return value to
exceed the range of the type
<B>ssize_t</B>
(since
<B>size_t</B>
has a larger range of positive values than
<B>ssize_t</B>).
Some functions, such as
<I>mq_receive()</I> ,
<I>msgrcv()</I> ,
<I>read()</I> ,
<I>strfmon()</I> ,
and
<I>write()</I> ,
resolve this conflict by restricting the object size in the description
section.
For example, the description section for the
<I>rea()</I>d
function states: "If the value of
<I>nbyte</I>
is greater than {SSIZE_MAX}, the result is implementation-dependent."
<p>
</ul>
<p>
The following were the detailed changes:
<ul>
<p>
<li>
<I>getdtablesize()</I>
<p>
The
<I>getdtablesize()</I>
function returns the size of the file descriptor table.
This is equivalent to
<I>getrlimit()</I>
with the RLIMIT_NOFILE option.
Whereas the
<I>getrlimit()</I>
function returns a value of type
<B>rlim_t</B>.
This function, returning an
<B>int</B>,
may have problems representing appropriate values in the future.
A note about this was added to the Application Usage section,
and the function marked LEGACY, with the recommendation that applications
should use the
<I>getrlimit()</I>
function instead.
<p>
<li>
<I>getpagesize()</I>
<p>
The
<I>getpagesize()</I>
function returns the current page size.
It is equivalent to
<I>sysconf</I>(_SC_PAGE_SIZE) and
<I>sysconf</I>(_SC_PAGESIZE).
This function, returning an
<B>int</B>,
may have problems representing appropriate values on non-32-bit platforms.
Also, the behavior is not specified for this function on systems
that support variable size pages.
On variable page size systems, a page can be extremely large
(theoretically, up to the size of memory).
This allows very efficient address translations for large segments
of memory that have common page attributes.
A note about this has been added to the Application Usage section,
and the function marked LEGACY, with the recommendation that
applications should use the
<I>sysconf()</I>
function instead.
<p>
<li>
<I>readlink()</I>
<p>
The
<I>readlink()</I>
function returns the size of the information that it reads as a type
<B>int</B>,
but the size of the buffer area is specified by a
<B>size_t</B>.
This function is specified in the IEEE PASC P1003.1a draft standard,
and the return value may change in a future version of the
Single UNIX Specification to reflect the final POSIX.1a standard.
<p>
<li>
<I>sbrk()</I>
<p>
The parameter to the
<I>sbrk()</I>
function is a type
<B>int</B>
defining the number of bytes by which to change the break value.
This function may not be able to address the full memory range
in the future for certain data models.
A new type has been introduced to be used in place of the type
<B>int</B>.
This is the
<B>intptr_t</B>
type which is an abstract data type equating
to a signed integral type large enough to hold any pointer.
This new type is one of a new set of types introduced in a new header
<I>inttypes.h</I>
to address the issues of data sizes for specific types.
<p>
<li>
<I>inttypes.h</I>
<p>
The
<I>inttypes.h</I>
header is a new header in the Single UNIX Specification, Version 2 and includes definitions for
at least the following types:
<dl compact>
<p>
<dt><B>int16_t</B><dd>16-bit signed integral type.
<p>
<dt><B>int32_t</B><dd>32-bit signed integral type.
<p>
<dt><B>int64_t</B><dd>64-bit signed integral type.
<p>
<dt><B>uint16_t</B><dd>16-bit unsigned integral type.
<p>
<dt><B>uint32_t</B><dd>32-bit unsigned integral type.
<p>
<dt><B>uint64_t</B><dd>64-bit unsigned integral type.
<p>
<dt><B>intptr_t</B><dd>Signed integral type large enough to hold any pointer.
<p>
<dt><B>uintptr_t</B><dd>Unsigned integral type large enough to hold any pointer.
<p>
</dl>
<p>
<li>
<I>sys/shm.h</I>
<p>
The element
<I>shm_segsz</I>
of structure
<B>shmid_ds</B>,
specifying the size of a memory segment was of type
<B>int</B>.
This has been changed to type
<B>size_t</B>.
<p>
<li>
<I>sys/stat.h</I>
and
<I>sys/statvfs.h</I>
<p>
The element
<I>st_blocks</I>
of the structure
<B>stat</B>
was changed to the new abstract
<B>blkcnt_t</B>
type.
<p>
The elements
<I>f_blocks</I>,
<I>f_bfree</I>,
and
<I>f_bavail</I>
of the structure
<B>statvfs</B>
were changed to the new abstract
<B>fsblkcnt_t</B>
type.
<p>