Gear & Gadgets / Product News & Reviews

An Introduction to 64-bit Computing and x86-64

When I first heard that AMD had plans to extend the x86 ISA to 64 bits, I …

Many modern processors support two additional data types: floating-point data and vector data. Each of these two data types has its own set of registers and its own execution unit(s). The following table compares all four data types in 32-bit and 64-bit processors:

Data Type Register
x86 Width x86-64
Integer GPR ALU 32 64
Address GPR ALU or AGU 32 64
Floating-point* FPR FPU 64 64
Vector VR VPU 128 128

*x87 uses 80-bit registers to do double-precision floating-point. The floats themselves are 64-bit, but the processor converts them to an internal, 80-bit format for increased precision when doing computations.

You can see from the table above that the difference the move to 64 bits makes is in the integer and address hardware. The floating-point and vector hardware stays the same.

Current 64-bit applications

Now that we know what 64-bit computing is, let's take a look at the benefits of increased integer and data sizes.

Dynamic range

The main thing that a wider integer gives you is increased dynamic range. Instead of defining the term "dynamic range," I'll just show you how it works.

In the base-10 number system to which we're all accustomed, you can represent a maximum of ten integers (0 to 9) with a single digit. This is because base-10 has ten different symbols with which to represent numbers. To represent more than ten integers you need to add another digit, using a combination of two symbols chosen from among the set of ten to represent any one of 100 integers (00 to 99). The general formula that you can use to compute the number of integers (dynamic range, or DR) that you can represent with an n-digit base-ten number is:

DR = 10n

So a 1-digit number gives you 101 = 10 possible integers, a 2-digit number 102 = 100 integers, a 3-digit number 103 = 1000 integers, and so on.

The base-2, or "binary," number system that computers use has only two symbols with which to represent integers: 0 and 1. Thus, a single-digit binary number allows you to represent only two integers, 0 and 1. With a two-digit (or "2-bit") binary, you can represent four integers by combining the two symbols (0 and 1) in any of the following four ways:

  1. 00 = 0
  2. 01 = 1
  3. 10 = 2
  4. 11 = 3

Similarly, a 3-bit binary number gives you eight possible combinations, which you can use to represent eight different integers. As you increase the number of bits, you increase the number of integers you can represent. In general, n bits will allow you to represent 2 n integers in binary. So a 4-bit binary number can represent 24 or 16 integers, an 8-bit number gives you 28=256 integers, and so on.

So in moving from a 32-bit GPR to a 64-bit GPR, the range of integers that a processor can manipulate goes from 232 = 4.3e9 to 264 = 1.8e19. The dynamic range, then, increases by a factor of 4.3 billion. Thus a 64-bit integer can represent a much larger range of numbers than a 32-bit integer.

The benefits of increased dynamic range, or, how the existing 64-bit computing market uses 64-bit integers

Since addresses are just special-purpose integers, an ALU and register combination that can handle more possible integer values can also handle that many more possible addresses. With all the recent press coverage that 64-bit architectures have garnered, it's fairly common knowledge that a 32-bit processor can address at most 4GB of memory. (Remember our 232 = 4.3 billion number? That 4.3 billion bytes is about 4GB.) A 64-bit architecture could theoretically, by contrast, address up to 18 million terabytes.

Of course, there's a big difference between the amount of address space that a 64-bit address value could theoretically yield and the actual sizes of the virtual and physical address spaces that a given 64-bit architecture supports. In the case of x86-64, the virtual address space is 48-bit, which makes for about 282 terabytes of virtual address space. (To borrow a line from my old IA-64 preview article, I'm tempted to say about this number what Bill Gates supposedly said about 640K back in the DOS days-"282 terabytes ought to be enough for anybody." But don't quote me on that in 10 years when Quake 16 takes up three or four million terabytes of hard disk space.) x86-64's physical address space is 40-bit, which can support about 1 terabyte of physical memory.

So, what do you do with over 4GB of memory? Well, caching a very large database in it is a start. Back-end servers for mammoth databases are one place where 64 bits have long been a requirement, so it's no surprise to see upcoming 64-bit offerings billed as capable database platforms.

On the media and content creation side of things, folks who work with very large 2D image files also appreciate the extra RAM. And a related, much sexier application domain where large amounts of memory come in handy is in simulation and modeling. Under this heading you could put various CAD tools and 3D rendering programs, as well as things like weather and scientific simulations, and even, as I've already half-jokingly referred to, realtime 3D games. Though the current crop of 3D games wouldn't benefit from greater than 4GB of RAM, it is quite possible that we'll see a game that benefits from greater than 4GB RAM within the next five years. But we'll discuss the possibilities for 64 bits in the consumer space later in the article, so let's not get ahead of ourselves.

There is one drawback to the increase in memory space that 64-bit addressing affords. Since memory address values (or pointers, in programmer lingo) are now twice as large, they take up twice as much cache space. Pointers normally make up only a fraction of all the data in the cache, but when that fraction doubles it can squeeze other useful data out of the cache and degrade performance slightly.

Some who read the discussion above would no doubt point out that Xeon systems are available with more than 4GB. Furthermore, Intel supposedly has a fairly simple hack that they could implement to allow their 32-bit systems to address up to 512GB of memory. Still, the cleanest and most future-proof way to address the 4GB ceiling is a larger pointer.

Some applications, mostly in the realm of scientific computing (MATLAB, Mathematica, MAPLE, etc.) and simulations, require 64-bit integers because they work with numbers outside the dynamic range of 32-bit integers. When the result of a calculation exceeds the range of possible integer values, you get a situation called either overflow (i.e. the result was greater than the highest positive integer) or underflow (i.e. the result was less than the largest negative integer). When this happens, the number you get in the register isn't the right answer. There's a bit in the x86's processor status word (see this page for a bit more on the PSW) that allows you to check to see if an integer has just exceeded the processor's dynamic range, so you know that the result is bogus. Such situations are very, very rare in integer applications. As an engineering student I never ran into this problem, although I did run into the somewhat related problem of floating-point round-off error a few times.

Programmers who run into integer overflow or underflow problems on a 32-bit platform do have the option of using a 64-bit integer construct provided by a higher level language like C. In such cases, the compiler uses two registers per integer, one for each half of the integer, to do 64-bit calculations in 32-bit hardware. This has obvious performance drawbacks, making it less desirable than a true 64-bit integer implementation.

Finally, there is another application domain for which 64-bit integers can offer real benefits: cryptography. Most popular encryption schemes rely on the multiplication and factoring of very large integers, and the larger the integers the more secure the encryption. As we'll discuss in the final section, AMD is hoping that the growing demand for tighter security and more encryption in the mainstream business and consumer computing markets will make a cheap, 64-bit, x86-compatible processor attractive.

At this point, I should make a quick note of a fact that I'll refer to again in the article's conclusion: increased performance was not mentioned above as a straightforward, across-the-board benefit of increased dynamic range. As I stated previously, 64-bit integer code runs slowly on a 32-bit machine, due to the fact that the 64-bit computations have to be split apart and processed as two separate 32-bit computations. So you could say that there's a performance penalty for running 64-bit integer code on a 32-bit machine; this penalty is absent when running the same code on a 64-bit machine, since the computation doesn't have to be split in two. The take-home point here is that only applications that require and use 64-bit integers will see a performance increase on 64-bit hardware that is due solely to a 64-bit processor's wider registers and increased dynamic range. So there's no magical performance boost inherent in the move from 32 bits to 64 bits, as people are often led to think by journalists who write things like, "64-bit computers can processes twice as much data per clock cycle as their 32-bit counterparts." Technically, this is true in a very restricted sense, but it would be better to say the following: "64-bit computers can process numbers that are 4.3 billion times as large as those processed by their 32-bit counterparts." It sounds a lot less sexy because it is, but at least no one is misled into thinking that 64-bitness makes a computer somehow twice as fast.

Expand full story

You must to comment.