About Opentopia
Opentopia Directory Encyclopedia Tools

64-bit

Encyclopedia : 6 : 64 : 64B : 64-bit

 

N-bit Processors
4-bit 8-bit 16-bit 24-bit 31-bit 32-bit 48-bit 64-bit 128-bit
N-bit Applications
    16-bit   31-bit 32-bit   64-bit  
N-bit Data Sizes
4-bit 8-bit 16-bit     32-bit   64-bit 128-bit
nibble byte octet word dword qword
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.

As of 2004, 64-bit CPUs are common in servers, and have recently been introduced to the (previously 32-bit) mainstream personal computer arena in the form of the AMD64, EM64T, and PowerPC 970 (or "G5") processor architectures.

Although a CPU may be 64-bit internally, its external data bus or address bus may have a different size, either larger or smaller, and the term 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. 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, however, a computer architecture described as "64-bit" generally has integer registers that are 64 bits wide and thus directly supports dealing both internally and externally with 64-bit "chunks" of integer data.

Contents

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 AMD64 architecture, also include SSE instructions, which use 16 128-bit wide registers. 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 232 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, with the march of time and the continual reductions in the cost of memory (see Moore's Law), by the early 1990s installations with quantities of RAM approaching 4 gigabytes began to appear, 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 Apple Computer's PowerMac desktop line as of 2003 using a 64-bit processor (the G5 chip from IBM), and AMD's "AMD64" architecture (implemented by Intel as "EM64T") becoming common in high-end PCs. The emergence of the 64-bit architecture effectively increases the memory ceiling to 264 addresses, equivalent to 17,179,869,184 gigabytes or 16 exabytes of RAM. To put this in perspective, in the days when a mere 4 kB of main memory was commonplace, the maximum memory ceiling of 232 addresses was about 1 million times larger than typical memory configurations. Taking today's standard as 4 GB of main memory (actually, few personal computers have this much), then the difference between today's standard and the 264 limit is a factor of about 4 billion. 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 Power Mac G5, 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. The latest Linux kernel (version 2.6.16) can be compiled with support for up to 64 gigabytes of memory.

64-bit microprocessor timeline

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 an older 32-bit instruction set as well as the new modes), through software emulation, or by the actual implementation of a 32-bit processor core within the 64-bit processor die (as with the Itanium processors from Intel, which include an x86 processor core to run 32-bit x86 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). Another significant exception is IBM z/Architecture, which readily handles applications concurrently with different addressing expectations (24, 31, and 64 bit).

While 64-bit architectures indisputably make working with huge 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 EM64T), the majority of the 32-bit operating systems and applications are able to run smoothly on the 64-bit hardware.

Some programs can be slower in 64-bit mode, since emulators and compilers take a while to process. To overcome this, 64-bit APIs such as Java and .NET need to be rewritten, so that instructions are both 32-bit and 64-bit compatible, and applications can make full use of the 64-bit processor. A 64-bit motherboard can accommodate more memory, and memory overflow or extra resources required are not the major problem.

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, 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:

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 31-bit address spaces while data objects can (optionally) reside in 64-bit regions.

Linux: 64-bit Linux has become more common in recent years. While finding prepackaged binaries for 64-bit systems has been a problem for some users, many Linux software packages can simply be compiled from source to work in a 64-bit environment. Gentoo Linux supports a very robust 64-bit environment. One issue is that 64-bit Linux cannot play certain audio and video formats easily, due to closed-sourced codecs that are incompatible with 64-bit media players. A workaround is to use 32-bit versions of those media players with the codecs, thus enabling playback of those formats.

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 (variables that store memory addresses) 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.

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 at run time. Also, limits.h in the C99 standard and climits in the C++ standard give more helpful info; sizeof only returns the number of bytes, which is sometimes misleading, because the size of a byte is also not well defined in C or C++. One needs to be careful to use the ptrdiff_t type (in the standard header <stddef.h>) when doing pointer arithmetic; too much code incorrectly uses "int" or "long" instead.

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. 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 that 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. Most 64 bit compilers today use the LP64 model (including Solaris, AIX, HP, Linux, MacOS native compilers), Microsoft however decided to use the LLP64 model.

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.

Current 64-bit microprocessor architectures

64-bit microprocessor architectures (as of 2006) include: Most 64-bit processor architectures can execute 32-bit code natively without any performance penalty. This kind of support is commonly called biarch support or more generally multi-arch support.

A completely distinct change in microprocessor design since approximately 2004 has been the introduction of multicore (initially, dual core) processors, which include two or more separate processor cores in a single "chip" or package. Effectively, dual-core processors deliver two-way Symmetric multiprocessing computers using a single motherboard processor socket - or four-way machines with two sockets, and so on. Some dual-core x86 chips, such as AMD's Athlon 64 X2 range, are 64-bit capable; others, such as Intel's Core Duo, are 32-bit devices. The performance and capacity implications of multi-core processors are entirely independent and different from those of 64-bit versus 32-bit. A processor with two 32-bit cores is not a 64-bit processor.

Beyond 64 bits

64-bit words seem to be sufficient for most practical uses today (c. 2006). Still, it should be mentioned that IBM's System/370 used 128-bit floating point numbers, and many modern processors also include 128-bit floating point registers. The System/370 was notable, however, in that it also used variable-length decimal numbers of up to 16 bytes (i.e. 128-bit).

IBM's OS/400 has for years used 128-bit pointers. Apps are designed to run on a virtual machine, then converted to the native instruction set when installed. The original hardware was a 32-bit CISC system similar to the System/370. Current hardware is 64-bit PowerPC. A future transition to 128-bit will be painless.

IPV6 addresses are 128 bits long. Processors that can manipulate a 128 bit integer would be helpful when dealing with IPV6 addresses. See [rfc1924 section 7].

Images

In digital imaging, 64-bit refers to 48-bit images with a 16-bit alpha channel.

See also

External links

This article was originally based on material from the Free On-line Dictionary of Computing, which is [Foldoc licenselicensed] under the GFDL.

-

 

From Wikipedia, the Free Encyclopedia. Original article here. Support Wikipedia by contributing or donating.
All text is available under the terms of the GNU Free Documentation License See Wikipedia Copyrights for details.

Search Titles
0123456789
ABCDEFGHIJ
KLMNOPQRST
UVWXYZ?

E-mail this article to:

Personal Message: