0% found this document useful (0 votes)
5 views

64-Bit Computer a Complete Guide

The document discusses 64-bit computer architecture, detailing its historical development, architectural implications, and the transition from 32-bit to 64-bit systems. It highlights the advantages of 64-bit systems, such as increased memory addressing capabilities and improved performance for large data sets, while also addressing limitations and misconceptions. The timeline of 64-bit processor development is outlined, showcasing key milestones and the evolution of 64-bit technology in various computing environments.

Uploaded by

Sarvesh Jaiswal
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
5 views

64-Bit Computer a Complete Guide

The document discusses 64-bit computer architecture, detailing its historical development, architectural implications, and the transition from 32-bit to 64-bit systems. It highlights the advantages of 64-bit systems, such as increased memory addressing capabilities and improved performance for large data sets, while also addressing limitations and misconceptions. The timeline of 64-bit processor development is outlined, showcasing key milestones and the evolution of 64-bit technology in various computing environments.

Uploaded by

Sarvesh Jaiswal
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 12

64-BIT COMPUTER

In computer architecture, 64-bit integers, memory addresses, or other data units are
those that are at most 64 bits (8 octets) wide. Also, 64-bit CPU and ALU
architectures are those that are based on registers, address buses, or data buses of
that size. 64-bit is also a term given to a generation of computers in which 64-bit
processors were the norm.

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.

Without further qualification, a 64-bit computer architecture generally has integer


and addressing registers that are 64 bits wide, allowing direct support for 64-bit
data types and addresses. However, a CPU might have external data buses or
address buses with different sizes than the registers, even larger (the 32-bit
Pentium had a 64-bit data bus, for instance). The term may also refer to the size of
low-level data types, such as 64-bit floating-point numbers.

Architectural implications
Processor registers are typically divided into several groups: integer, floating-
point, SIMD, control, and often special registers for address arithmetic which may
have various uses and names such as address, index or base registers. However, in
modern designs, these functions are often performed by more general purpose
integer registers. In most processors, only integer and/or address-registers can be
used to address data in memory, the other types cannot. The size of these registers
therefore normally limit the amount of directly addressable memory, even if there
are registers, such as floating-point registers, that are wider.

Most high performance 32-bit and 64-bit processors (some notable exceptions are
most ARM and 32-bit MIPS CPUs) have integrated floating point hardware, which
is often but not always, based on 64-bit units of data. For example, although the
x86/x87 architecture has instructions capable of loading and storing 64-bit (and 32-
bit) floating-point values in memory, the internal data and register format is 80-bit
wide. In contrast, the 64-bit Alpha family uses a 64-bit floating-point data and
register format (as well as 64-bit integer registers).
History
Most CPUs are 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 address register meant that 232 addresses, or 4 GB of RAM,
could be referenced. At the time these architectures were devised, 4 GB of memory
was so far beyond the typical quantities (16 MB) available in installations that this
was considered to be enough "headroom" for addressing. 4 GB 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.

Some supercomputer processor architectures of the 1970s and 80s used registers up
to 64 bits wide. However, 32 bits remained the norm until the early 1990s, when
the continual reductions in the cost of memory led to installations with quantities
of RAM approaching 4 GB, and the use of virtual memory spaces exceeding the 4-
gigabyte ceiling became desirable for handling certain types of problems. In
response, MIPS and DEC developed 64-bit microprocessor architectures, initially
for high-end workstation and server machines. By the mid-1990s, HAL Computer
Systems, Sun Microsystems, IBM and Hewlett Packard had developed 64-bit
architectures for their workstation and server systems. A notable exclusion to this
trend were mainframes from IBM, which remained 32-bit. During the 1990s,
several low-cost 64-bit microprocessors were used in consumer electronics and
embedded applications. Notably, the Nintendo 64 and PlayStation 2 both had 64-
bit microprocessors before its introduction in personal computers. High-end
printers and network equipment, as well as industrial computers also used 64-bit
microprocessors such as the Quantum Effect Devices R5000. 64-bit computing
started to drift down to the personal computer desktop from 2003 onwards, when
some models in Apple's Macintosh lines switched to PowerPC 970 processors
(termed "G5" by Apple) and the launch of AMD's 64-bit x86-64 extension to the
x86 architecture, processors based on this architecture becoming common in high-
end PCs.

The emergence of the 64-bit architecture effectively increases the memory ceiling
to 264 addresses, equivalent to approximately 17.2 billion gigabytes, 16.8 million
terabytes, or 16 exabytes of RAM. To put this in perspective, in the days when 4
MB 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 over 2 GB of main memory is common, the ceiling of 264 addresses is
about ten trillion times larger, i.e., ten billion times more headroom than the 232
case.

Limitations
Most 64-bit microprocessors on the market today have an artificial limit on the
amount of memory they can address, because physical constraints make it
impossible to support the full 16.8 million terabyte capacity. For example, the
AMD Athlon X2 has a 40-bit address bus and recognizes only 48 bits of the 64-bit
virtual address. The newer Barcelona X4 supports a 48-bit physical address and 48
bits of the 64-bit virtual address.

64-bit processor timeline


 1961: IBM delivers the IBM 7030 Stretch supercomputer, which uses 64-bit
data words and 32- or 64-bit instruction words.

 1974: Control Data Corporation launches the CDC Star-100 vector


supercomputer, which uses a 64-bit word architecture (previous CDC
systems were based on a 60-bit architecture).

 1974: International Computers Limited launches the ICL 2900 Series with
32-bit, 64-bit, and 128-bit twos-complement integers; 64-bit and 128-bit
floating point; 32-bit, 64-bit and 128-bit packed decimal and a 128-bit
accumulator register. The architecture has survived through a succession of
ICL and Fujitsu machines. The latest is the Fujitsu Supernova, which
emulates the original environment on 64-bit Intel processors.

 1976: Cray Research delivers the first Cray-1 supercomputer, which is based
on a 64-bit word architecture and would form the basis for later Cray vector
supercomputers.

 1983: Elxsi launches the Elxsi 6400 parallel minisupercomputer. The Elxsi
architecture has 64-bit data registers but a 32-bit address space.
 1991: MIPS Technologies produces the first 64-bit microprocessor, the
R4000, which implements the MIPS III ISA, the third revision of their MIPS
architecture.[2] The CPU is used in SGI graphics workstations starting with
the IRIS Crimson. However, 64-bit support for the R4000 would not be
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) introduces the pure 64-bit


Alpha architecture which was born from the PRISM project.

 1993: DEC releases the 64-bit DEC OSF/1 AXP Unix-like operating system
(later renamed Tru64 UNIX).

 1994: Intel announces plans for the 64-bit IA-64 architecture (jointly
developed with Hewlett-Packard) as a successor to its 32-bit IA-32
processors. A 1998 to 1999 launch date is targeted. SGI releases IRIX 6.0,
with 64-bit support for the R8000 chip set.

 1995: Sun launches a 64-bit SPARC processor, the UltraSPARC. Fujitsu-


owned HAL Computer Systems launches workstations based on a 64-bit
CPU, HAL's independently designed first-generation SPARC64. IBM
releases the A10 and A30 microprocessors, 64-bit PowerPC AS
processors.[5] IBM also releases a 64-bit AS/400 system upgrade, which can
convert the operating system, database and applications. DEC releases
OpenVMS 7.0, the first full 64-bit version of OpenVMS for Alpha.

 1996: Nintendo introduces the Nintendo 64 video game console, built


around a low-cost variant of the MIPS R4000. HP releases an
implementation of the 64-bit 2.0 version of their PA-RISC processor
architecture, the PA-8000.

 1997: IBM releases the RS64 line of 64-bit PowerPC/PowerPC AS


processors.

 1998: IBM releases the POWER3 line of full-64-bit PowerPC/POWER


processors. Sun releases Solaris 7, with full 64-bit UltraSPARC support.

 1999: Intel releases the instruction set for the IA-64 architecture. AMD
publicly discloses its set of 64-bit extensions to IA-32, called x86-64 (later
renamed AMD64).
 2000: IBM ships its first 64-bit ESA/390-compatible mainframe, the zSeries
z900, and its new z/OS operating system. 64-bit Linux on zSeries follows
almost immediately.

 2001: Intel finally ships its 64-bit processor line, now branded Itanium,
targeting high-end servers. It fails to meet expectations due to the repeated
delays in getting IA-64 to market. Linux is the first operating system to run
on the processor at its release.

 2003: AMD introduces its Opteron and Athlon 64 processor lines, based on
its AMD64 architecture which is the first x86 based 64 bit processor
architecture. Apple also ships the 64-bit "G5" PowerPC 970 CPU courtesy
of IBM, along with an update to its Mac OS X operating system which adds
partial support for 64-bit mode. Several Linux distributions release with
support for AMD64. Microsoft announces plans to create a version of its
Windows operating system to support the AMD64 architecture. FreeBSD
releases with support for AMD64. Intel maintains that its Itanium chips
would remain its only 64-bit processors.

 2004: Intel, reacting to the market success of AMD, admits it has been
developing a clone of the AMD64 extensions named IA-32e (later renamed
EM64T). Intel also ships updated versions of its Xeon and Pentium 4
processor families supporting the new instructions.

 2004: VIA Technologies announces the Isaiah 64-bit processor.

 2005: On January 31, Sun releases Solaris 10 with support for AMD64 and
EM64T processors. On April 30, Microsoft releases Windows XP
Professional x64 Edition for AMD64 and EM64T processors.

 2006: Sony, IBM, and Toshiba begin manufacturing of the 64-bit Cell
processor for use in the PlayStation 3, servers, workstations, and other
appliances.

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), 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 has only implemented the "server" JIT compiler (C2) for
64-bit platforms.[10] The "client" JIT compiler (C1), which produces less efficient
code but compiles much faster, is unavailable on 64-bit platforms.

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 (high-performance computing)—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, 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 GB 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 GB of RAM. This restriction is not present in 64-bit
operating systems. (This also applies to computers running Windows Vista
with Service Pack 1 as it only shows the installed RAM not the usable.)

 Memory-mapped files are becoming more difficult to implement in 32-bit


architectures, especially due to the introduction of relatively cheap
recordable DVD technology. A 4 GB 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 a problem, as memory mapping
remains one of the most efficient disk-to-memory methods, when properly
implemented by the OS.
 Some programs such as data encryption software can benefit greatly from
64-bit registers (if the software is 64-bit compiled) and effectively execute 3
to 5 times faster on 64-bit than on 32-bit.

 Some complex numerical analysis algorithms are limited in their precision


by the errors that can creep in because not all floating point numbers can be
accurately represented with a small number of bits. Creeping inaccuracies
can lead to incorrect results, often leading to attempts to divide by zero, or to
not identify two quantities as being identical for practical purposes.
International Computers Limited added 128-bit support to the ICL 2900
Series in 1974 largely as a result of requests from the scientific community.

The main disadvantage of 64-bit architectures is that relative to 32-bit architectures


the same data occupies 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 x86 software is compiled into 32-bit code, not 64-bit
code, so it does not take advantage of the larger 64-bit address space or wider 64-
bit registers and data paths on x86 processors, or the additional registers in 64-bit
mode. However, users of most RISC platforms, and users of free or open source
operating systems (where the source code is available for recompiling with a 64-bit
compiler) have been able to use exclusive 64-bit computing environments for
years. Not all such applications require a large address space nor manipulate 64-bit
data items, so they wouldn't benefit from the larger address space or wider registers
and data paths. The main advantage to 64-bit versions of such applications is the
ability to access more registers in the x86-64 architecture.

Software availability
x86-based 64-bit systems sometimes lack equivalents to software that is written for
32-bit architectures. The most severe problem in Microsoft Windows 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 for IA64) or run in 32-bit mode natively (on AMD64), 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. Because 64-bit drivers for most devices were not available until early
2007, using 64-bit Microsoft Windows operating system was considered
impractical. However the trend is changing towards 64-bit computing as most
manufacturers provide both 32-bit and 64-bit drivers nowadays.

Because device drivers in operating systems with monolithic kernels, and in many
operating systems with hybrid kernels, 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. These 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. Differences between
the C89 and C99 language standards also exacerbate the problem [11]

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
standards leave the definition of the CHAR_BIT macro, and therefore the number
of bits in a char, to the implementations. 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. C99, however, stdint.h provides names for integer types with
certain numbers of bits where those types are available.

In most programming environments on 32-bit machines, pointers, "int" types, and


"long" types are all 32 bits wide.

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.
64-bit data models
Data model short int long long long pointers
LLP64 16 32 32 64 64
LP64 16 32 64 64 64
ILP64 16 64 64 64 64
SILP64 64 64 64 64 64
Many 64-bit compilers today use the LP64 model (including Solaris, AIX, HP,
Linux, Mac OS X, FreeBSD, 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. These are not problems
which affect fully standard-compliant code but code is often written with implicit
assumptions about the widths of integer types.

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 gigabyte 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 2008) include:

 64-bit extensions of the Intel x86 architecture, commonly known generically


as "x86-64" or "x64":
o AMD's AMD64 extensions (used in Athlon 64, Opteron, Sempron,
Turion 64 and Phenom processors)
o Intel's Intel 64 extensions (used in newer Celeron, Pentium 4, Pentium
D, Xeon, Core 2, Core i7, and Atom processors)
o VIA Technologies' 64-bit extensions, used in the VIA Nano
processors
 Power Architecture:
o IBM's POWER6 processor
o IBM's PowerPC 970 processor
o The Cell Broadband Engine used in the PlayStation 3, designed by
IBM, Toshiba and Sony, combines a 64-bit Power architecture
processor with eight 128-bit "Synergistic Processing Elements"
o IBM's "Xenon" processor used in the Microsoft Xbox 360 comprises
three 64-bit PowerPC cores.
 SPARC V9 architecture:
o Sun's UltraSPARC processors
o Fujitsu's SPARC64 processors
 IBM's z/Architecture, used by IBM zSeries and System z9 mainframes, a
64-bit version of the ESA/390 architecture
 Intel's IA-64 architecture (used in Itanium processors)
 MIPS Technologies' MIPS64 architecture

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 bi-arch support or more generally multi-arch support.
CONTENTS

 1 Architectural implications

 2 History

 3 Limitations

 4 64-bit processor timeline

 5 32 vs 64 bit

 6 Pros and cons

o 6.1 Software availability

 7 64-bit data models

 8 Current 64-bit microprocessor architectures

You might also like