'64-bit' CPUs have existed in
supercomputers since the 1960s and in
RISC-based
workstations and
servers since the early 1990s. In 2003 they were introduced to the (previously
32-bit) mainstream
personal computer arena, in the form of the
x86-64 and 64-bit
PowerPC processor architectures.
A CPU that is 64-bit internally might have external
data buses or
address buses with a different size, either larger or smaller; the term "64-bit" is often used to describe the size of these buses as well. For instance, many current machines with 32-bit processors use 64-bit buses (e.g. the original
Pentium and later CPUs), and may occasionally be referred to as "64-bit" for this reason. Likewise, some 16-bit processors (for instance, the
MC68000) were referred to as 16-/32-bit processors as they had 16-bit busses, but had some internal 32-bit capabilities. The term may also refer to the size of an instruction in the computer's
instruction set or to any other item of data (e.g. 64-bit
double-precision floating-point quantities are common). Without further qualification, "64-bit" computer architecture generally has integer
registers that are 64 bits wide, which allows it to support (both internally and externally) 64-bit "chunks" of integer data.
Architectural implications
Registers in a processor are generally divided into three groups: integer, floating point, and other. In all common general purpose processors, only the integer registers are capable of storing pointer values (that is, an address of some data in memory). The non-integer registers cannot be used to store pointers for the purpose of reading or writing to memory, and therefore cannot be used to bypass any memory restrictions imposed by the size of the integer registers.
Nearly all common general purpose processors (with the notable exception of most
ARM and 32-bit
MIPS implementations) have integrated floating point hardware, which may or may not use 64-bit registers to hold data for processing. For example, the
x86 architecture includes the
x87 floating-point instructions which use 8 80-bit registers in a stack configuration; later revisions of x86, and the
x86-64 architecture, also include
SSE instructions, which use 8 128-bit wide registers (16 registers in x86-64). By contrast, the 64-bit
Alpha family of processors defines 32 64-bit wide floating point registers in addition to its 32 64-bit wide integer registers.
Memory limitations
Most CPUs are currently (as of 2005) designed so that the contents of a single integer register can store the
address (location) of any datum in the computer's
virtual memory. Therefore, the total number of addresses in the virtual memory — the total amount of data the computer can keep in its working area — is determined by the width of these registers. Beginning in the
1960s with the
IBM System/360, then (amongst many others) the
DEC VAX minicomputer in the
1970s, and then with the
Intel 80386 in the mid-
1980s, a ''de facto'' consensus developed that 32 bits was a convenient register size. A 32-bit register meant that 2
32 addresses, or 4
gigabytes of
RAM, could be referenced. At the time these architectures were devised, 4 gigabytes of memory was so far beyond the typical quantities available in installations that this was considered to be enough "headroom" for addressing. 4-gigabyte addresses were considered an appropriate size to work with for another important reason: 4 billion integers are enough to assign unique references to most physically countable things in applications like
databases.
However, by the early 1990s, the continual reductions in the cost of memory led to installations with quantities of RAM approaching 4 gigabytes, and the use of virtual memory spaces exceeding the 4-gigabyte ceiling became desirable for handling certain types of problems. In response, a number of companies began releasing new families of chips with 64-bit architectures, initially for
supercomputers and high-end
workstation and
server machines. 64-bit computing has gradually drifted down to the personal computer desktop, with some models in
Apple's Macintosh lines switching to PowerPC 970 processors (termed "G5" by Apple) in 2003 and to 64-bit EM64T processors in 2006, and with x86-64 processors becoming common in high-end
PCs. The emergence of the 64-bit architecture effectively increases the memory ceiling to 2
64 addresses, equivalent to 17,179,869,184 gigabytes or 16
exabytes of RAM. To put this in perspective, in the days when 4
MiB of main memory was commonplace, the maximum memory ceiling of 2
32 addresses was about 1,000 times larger than typical memory configurations. Today, when 1
GiB of main memory is common, the ceiling of 2
64 addresses is about ten billion times larger, i.e. ten million times more headroom.
Most 64-bit consumer PCs on the market today have an artificial limit on the amount of memory they can recognize, because physical constraints make it highly unlikely that one will need support for the full 16 exabyte capacity. Apple's Mac Pro, for example, can be physically configured with up to 16 gigabytes of memory, and as such there is no need for support beyond that amount. A recent
Linux kernel (version 2.6.16) can be compiled with support for up to 64 gigabytes of memory.
64-bit processor timeline
★ 1961:
IBM delivered the
IBM 7030 Stretch supercomputer. This used 64-bit data words and 32 or 64-bit instruction words.
★ 1974:
Control Data Corporation launched the
CDC Star-100 vector supercomputer, which used a 64-bit word architecture (previous CDC systems were based on a 60-bit architecture).
★ 1976:
Cray Research delivered the first
Cray-1 supercomputer. This was based on a 64-bit word architecture, which formed the basis for later Cray vector supercomputers.
★ 1983:
Elxsi launched the Elxsi 6400 parallel
minisupercomputer. The Elxsi architecture had 64-bit data registers but a 32-bit address space.
★ 1991:
MIPS Technologies produced the first 64-bit microprocessor, as the third revision of their
MIPS RISC architecture, the R4000. The CPU was used in
SGI graphics workstations starting with the
IRIS Crimson. However, 64-bit support for the R4000 was not included in the
IRIX operating system until IRIX 6.2, released in 1996.
Kendall Square Research deliver their first KSR1 supercomputer, based on a proprietary 64-bit RISC processor architecture running
OSF/1.
★ 1992:
Digital Equipment Corporation (DEC) introduced the pure 64-bit
Alpha architecture which was born from the
PRISM project.
★ 1993: DEC released the 64-bit
OSF/1 AXP Unix-like operating system (later renamed Tru64 UNIX) and the
OpenVMS operating system for Alpha systems.
★ 1994:
Intel announced plans for the 64-bit
IA-64 architecture (jointly developed with
HP) as a successor to its 32-bit
IA-32 processors. A 1998–1999 launch date was targeted. SGI released IRIX 6.0, with 64-bit support for
R8000 CPUs.
★ 1995:
Sun launched a 64-bit
SPARC processor, the UltraSPARC.
Fujitsu-owned
HAL Computer Systems launched workstations based on a 64-bit CPU, HAL's independently designed first generation SPARC64.
IBM released 64-bit
AS/400 systems, with the upgrade able to convert the operating system, database and applications. DEC released
OpenVMS Alpha 7.0, the first full 64-bit version of OpenVMS for Alpha.
★ 1996: HP released an implementation of the 64-bit 2.0 version of their
PA-RISC processor architecture, the
PA-8000.
Nintendo introduces the
Nintendo 64 video game console, built around a low-cost variant of the MIPS R4000.
★ 1997: IBM released their
RS64 full 64-bit
PowerPC processors.
★ 1998: IBM released their
POWER3 full 64-bit PowerPC/
POWER processors. Sun released
Solaris 7, with full 64-bit UltraSPARC support.
★ 1999: Intel released the
instruction set for the IA-64 architecture. First public disclosure of
AMD's set of 64-bit extensions to IA-32, called
x86-64 (later renamed AMD64).
★ 2000:
IBM shipped its first 64-bit
ESA/390-compatible
mainframe, the
zSeries z900, and its new
z/OS operating system. 64-bit
Linux on zSeries followed almost immediately.
★ 2001: Intel finally shipped its 64-bit processor line, now branded
Itanium, targeting high-end servers. It fails to meet expectations due to the repeated delays getting IA-64 to market, and becomes a
flop.
Linux was the first operating system to run on the processor at its release.
★ 2002: Intel introduced the
Itanium 2 as a successor to the Itanium.
★ 2003: AMD brought out its AMD64-architecture
Opteron and
Athlon 64 processor lines.
Apple also shipped 64-bit "G5"
PowerPC 970 CPUs courtesy of
IBM, along with an update to its
Mac OS X operating system, that added partial support for 64-bit mode. Several
Linux distributions released with support for AMD64.
Microsoft announced that it would create a version of its
Windows operating system for these AMD chips. Intel maintained that its Itanium chips would remain its only 64-bit processors.
★ 2004: Intel, reacting to the market success of AMD, admitted it had been developing a clone of the AMD64 extensions, which it calls IA-32e and later renames EM64T. Updated versions of its
Xeon and
Pentium 4 processor families supporting the new instructions were shipped.
Freescale announces the 64-bit
e700 core, successor to their
PowerPC G4 series.
★ 2004:
VIA Technologies announced the Isaiah 64-bit processor.
[1]
★ 2005: On
January 31, Sun released
Solaris 10 with support for AMD64 and EM64T processors. Intel released the EM64T based Pentium Extreme Edition 840 and
Pentium D in the second quarter. On April 30, Microsoft publicly released
Windows XP Professional x64 Edition for AMD64 and EM64T processors. In May, AMD introduced its first dual-core AMD64
Opteron and
Athlon 64 X2. In July, IBM announced its new dual-core 64-bit
PowerPC 970MP. Microsoft releases the
Xbox 360 game console which use the 64-bit, triple-core
Xenon PowerPC processor manufactured by IBM.
★ 2006: Dual-core Montecito
Itanium 2 processors in production. Sony, IBM, and Toshiba begin manufacturing of the 64-bit
Cell processor for use in the
PlayStation 3, servers, workstations, and other appliances. Apple, Inc. features 64-bit EM64T
Xeon processors in their new
Mac Pro and Intel
Xserve computers, and later updates the
iMac,
MacBook and
MacBook Pro to use EM64T
Core 2 processors.
32 vs 64 bit
A change from a 32-bit to a 64-bit architecture is a fundamental alteration, as most
operating systems must be extensively modified to take advantage of the new architecture. Other software must also be
ported to use the new capabilities; older software is usually supported through either a ''hardware compatibility mode'' (in which the new processors support the older 32-bit version of the instruction set as well as the 64-bit version), through software
emulation, or by the actual implementation of a 32-bit processor core within the 64-bit processor (as with the Itanium processors from Intel, which include an
x86 processor core to run 32-bit x86 applications). The operating systems for those 64-bit architectures generally support both 32-bit and 64-bit applications.
One significant exception to this is the
AS/400, whose software runs on a virtual
ISA, called TIMI (Technology Independent Machine Interface) which is translated to native machine code by low-level software before being executed. The low-level software is all that has to be rewritten to move the entire OS and all software to a new platform, such as when
IBM transitioned their line from the older 32/48-bit "IMPI" instruction set to 64-bit PowerPC (IMPI wasn't anything like 32-bit PowerPC, so this was an even bigger transition than from a 32-bit version of an instruction set to a 64-bit version of the same instruction set).
While 64-bit architectures indisputably make working with large data sets in applications such as
digital video, scientific computing, and large
databases easier, there has been considerable debate as to whether they or their 32-bit compatibility modes will be faster than comparably-priced 32-bit systems for other tasks. In
x86-64 architecture (AMD64 and Intel 64), the majority of the 32-bit operating systems and applications are able to run smoothly on the 64-bit hardware.
Sun's 64-bit Java virtual machines are slower to start up than their 32-bit virtual machines because Sun still assumes that all 64-bit machines are servers, and have only implemented the "server" compiler (C2) for 64-bit platforms.
[2] The "client" compiler (C1) produces slower code, but compiles much faster. So although a Java program on a 64-bit JVM may perform better over a long period (typical for long-running "server" applications), its start-up time is likely to be much longer. For short-lived applications (such as the Java compiler,
javac) the increased start-up time can dominate the run time, making the 64-bit JVM slower overall.
It should be noted that speed is not the only factor to consider in a comparison of 32-bit and 64-bit processors. Applications such as multi-tasking, stress testing, and clustering (for
HPC) may be more suited to a 64-bit architecture given the correct deployment. 64-bit clusters have been widely deployed in large organizations such as
IBM,
Vodafone,
HP and
Microsoft, for this reason.
Pros and cons
A common misconception is that 64-bit architectures are no better than 32-bit architectures unless the computer has more than 4 GiB of memory. This is not entirely true:
★ Some operating systems reserve portions of
process address space for OS use, effectively reducing the total address space available for mapping memory for user programs. For instance, Windows XP DLLs and userland OS components are mapped into each process's address space, leaving only 2 to 3.8 GB (depending on the settings) address space available, even if the computer has 4 GiB of RAM. This restriction is not present in 64-bit Windows.
★
Memory mapping of files is becoming less useful with 32-bit architectures, especially with the introduction of relatively cheap recordable DVD technology. A 4 GiB file is no longer uncommon, and such large files cannot be memory mapped easily to 32-bit architectures; only a region of the file can be mapped into the address space, and to access such a file by memory mapping, those regions will have to be mapped into and out of the address space as needed. This is an issue, as memory mapping remains one of the most efficient disk-to-memory methods, when properly implemented by the OS.
The main disadvantage of 64-bit architectures is that relative to 32-bit architectures the same data occupies slightly more space in memory (due to swollen pointers and possibly other types and alignment padding). This increases the memory requirements of a given process and can have implications for efficient processor cache utilization. Maintaining a partial 32-bit model is one way to handle this and is in general reasonably effective. In fact, the highly performance-oriented
z/OS operating system takes this approach currently, requiring program code to reside in any number of
32-bit address spaces while data objects can (optionally) reside in 64-bit regions.
Currently, most commercial software is built as 32-bit code, not 64-bit code, so it can't take advantage of the larger 64-bit address space or wider 64-bit registers and data paths on 64-bit processors, or, on x86 processors, the additional registers in 64-bit mode. However, users of free or
open source operating systems have been able to use exclusive 64-bit computing environments for years. Not all such applications require a large address space or manipulate 64-bit data items, so they wouldn't benefit from the larger address space or wider registers and data paths; the main benefit to 64-bit versions of applications that wouldn't benefit from them would be that x86 versions would be able to use more registers.
Software availability
64-bit systems sometimes lack equivalents to software that is written for 32-bit architectures. The most severe problem is incompatible
device drivers. Although most
software can run in a 32-bit compatibility mode (also known as an
emulation mode, e.g. Microsoft
WoW64 Technology), it is usually impossible to run a driver (or similar software) in that mode since such a
program usually runs in between the
OS and the hardware, where direct
emulation cannot be employed. Many
open source software packages can simply be compiled from source to work in a 64-bit environment on operating systems such as Linux. All that would be needed in this case is a compiler (usually
gcc) for the 64-bit machine. Currently the 64-bit versions for most device drivers are not available, so using a 64-bit operating system can become frustrating due to a lack of available drivers.
Because device drivers usually execute within the operating system kernel, it is possible to run the kernel as a 32-bit process while still supporting 64-bit user processes. This provides the memory and performance benefits of 64-bit for users without breaking binary compatibility with existing 32-bit device drivers, at the cost of some additional overhead within the kernel. This is the mechanism by which
Mac OS X enables 64-bit processes while still supporting 32-bit device drivers.
64-bit data models
Converting application software written in a
high-level language from a 32-bit architecture to a 64-bit architecture varies in difficulty.
One common recurring problem is that some programmers assume that
pointers have the same length as some other data type. Programmers assume they can transfer quantities between these data types without losing information.
Those assumptions happen to be true on some 32-bit machines (and even some 16-bit machines), but they are no longer true on 64 bit machines.
The
C programming language and its descendant
C++ make it particularly easy to make this sort of mistake
[1].
To avoid this mistake in C and C++, the
sizeof operator can be used to determine the size of these primitive types if decisions based on their size need to be made, both at compile and run time. Also, the <limits.h> header in the
C99 standard, and numeric_limits class in <limits> header in the C++ standard, give more helpful info; sizeof only returns the size in
chars. This used to be misleading, because the size of a char (
CHAR_BITS) is by itself not defined the same way in all implementations of C or C++. However, except for those compilers targeting
DSPs, "64 bits == 8 chars of 8 bits each" has become the norm.
One needs to be careful to use the
ptrdiff_t type (in the standard header
<stddef.h>) for the result of subtracting two pointers; too much code incorrectly uses "int" or "long" instead. To represent a pointer (rather than a pointer difference) as an integer, use
uintptr_t where available (it is only defined in C99, but some compilers otherwise conforming to an earlier version of the standard offer it as an extension).
Neither C nor C++ define the length of a pointer, int, or long to be a specific number of bits.
In most programming environments on 32-bit machines, pointers, "int" variables, and "long" variables are all 32 bits long.
However, in many programming environments on 64-bit machines, "int" variables are still 32 bits wide, but "long"s and pointers are 64 bits wide. These are described as having an 'LP64'
data model. Another alternative is the 'ILP64' data model in which all three data types are 64 bits wide, and even 'SILP64' where "short" variables are also 64 bits wide. However, in most cases the modifications required are relatively minor and straightforward, and many well-written programs can simply be recompiled for the new environment without changes. Another alternative is the 'LLP64' model, which maintains compatibility with 32-bit code by leaving both int and long as 32-bit. "LL" refers to the "long long" type, which is at least 64 bits on all platforms, including 32-bit environments.
Many 64-bit compilers today use the 'LP64' model (including Solaris, AIX, HP, Linux, Mac OS X, and IBM z/OS native compilers). Microsoft's VC++ compiler uses the 'LLP64' model. The disadvantage of the LP64 model is that storing a long into an int may overflow. On the other hand, casting a pointer to a long will work. In the LLP model, the reverse is true. Neither should happen in proper C99 code.
Note that a programming model is a choice made on a per-compiler basis, and several can coexist on the same OS. However typically the programming model chosen by the OS API as primary model dominates.
Another consideration is the data model used for
drivers. Drivers make up the majority of the operating system code in most modern operating systems (although many may not be loaded when the operating system is running). Many drivers use pointers heavily to manipulate data, and in some cases have to load pointers of a certain size into the hardware they support for
DMA. As an example, a driver for a 32-bit PCI device asking the device to
DMA data into upper areas of a 64-bit machine's memory could not satisfy requests from the operating system to load data from the device to memory above the 4 gibibyte barrier, because the pointers for those addresses would not fit into the DMA registers of the device. This problem is solved by having the OS take the memory restrictions of the device into account when generating requests to drivers for DMA, or by using an
IOMMU.
Current 64-bit microprocessor architectures
64-bit
microprocessor architectures (
as of 2006) include:
★ The
DEC Alpha architecture (view
Digital Alpha timeline)
★ Intel's
IA-64 architecture (used in Intel's
Itanium CPUs)
★ The
x86-64 architecture, a 64-bit version of the
x86 architecture (also known as "x64")
★
★ AMD's AMD64 (used in AMD's
Athlon 64,
Opteron,
Sempron, and
Turion 64 CPUs)
★
★ Intel's Intel64 (used in Intel's newer
Pentium 4,
Xeon, and
Core 2 CPUs)
★
SPARC architecture (64-bit as of SPARC V9)
★
★ Sun's UltraSPARC architecture
★
★ Fujitsu's SPARC64 architecture
★ IBM's
POWER architecture (64-bit as of
POWER3 and
RS64 variants)
★ IBM/Motorola's
PowerPC architecture (64-bit
PowerPC 620 and
PowerPC 970 variants)
★ IBM's
z/Architecture, used by IBM zSeries and
System z9 mainframes, a 64-bit version of the
ESA/390 architecture
★ MIPS Technologies' MIPS IV, MIPS V, and MIPS64
architectures
★ HP's
PA-RISC family (64-bit as of PA-RISC 2.0)
Most 64-bit processor architectures can execute code for the 32-bit version of the architecture natively without any performance penalty. This kind of support is commonly called ''biarch support'' or more generally ''multi-arch support''.
Beyond 64 bits
As of 2007, 64-bit words seem to be sufficient for most practical uses. Still, it should be mentioned that IBM's
System/370 and successors use
128-bit floating point numbers, and many modern processors also include 128-bit floating point registers. The System/370 and successors are notable, however, in that they also use variable-length
decimal numbers of up to 16 bytes (i.e.
128-bit).
Images
In digital imaging, 64-bit refers to
48-bit images with a
16-bit alpha channel.
See also
★
Computer memory
References
1. VIA Unveils Details of Next-Generation Isaiah Processor Core
2. Frequently Asked Questions About the Java HotSpot VM
العربية
中国
Français
Deutsch
Ελληνική
हिन्दी
Italiano
日本語
Português
Русский
Español
![Don\](images/articles/thumbs/beachrainthumb.jpg "Don\")
