

Ars explains the theory and praxis of 64 bit computing.

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 thought it was a terrible idea. Though x86 is the world's most successful ISA, it's also the world's most widely disparaged. Programmers, analysts, architecture buffs, and enthusiasts often see x86 as a leaden albatross around the neck of the entire computing industry, and like the Mariner's albatross we were all hoping it would just fall off at some point and slip quietly into the deep. But in spite of such hopes, I really knew better. In fact, I've argued elsewhere that x86 isn't going away anytime soon, and it no longer makes any real sense to gripe about its quirks from a performance perspective. I won't recap that argument here, but I can sum it up briefly.

Most of us would probably assent to the following statement: "there's a huge global market for mainstream business and consumer software, and the overwhelming majority of that software just so happens to use the x86 ISA." This statement is true, as far as it goes, but framing x86's role in the software industry this way misses an important point. In my article "The Future of x86 and the Concept of the ISA," I argue that a statement like the following would provide a more relevant assessment of the true state of the software industry: "There's a huge global market for mainstream business and consumer x86 software, and several smaller markets for software written to other ISAs." All discussions of the desktop prospects of widely ported operating systems (i.e. Linux) or of the possible effects of greater open source market penetration aside, this statement should still ring true to anyone who's acquainted with the present realities of the installed base of IT and consumer software.

If we think realistically about most of the world's commercial software not as "software" in the abstract but as x86 binary code, then it becomes apparent that improvements to the x86 ISA represent one of the most practical and cost-effective ways to advance and expand the x86 software market. Indeed, Intel's continuing extensions of additions to the x86 ISA prove just this point. Consider the move from 16 bits to 32 bits, the addition of the x87 floating-point instructions, and the addition of integer and then floating-point SIMD instructions. All of these modifications of x86 helped bring new capabilities to the PC, allowing it to find new applications and enter new markets. Thus, the ongoing adaptation of the x86 ISA to ever newer technological contexts has been one of the essential subplots in the past two decades' story of the "information revolution."

The present article outlines what AMD hopes is the next step in x86's evolution: x86-64. As we'll see, x86-64 is more than just a 64-bit extension to the 32-bit x86 ISA; it adds some new features, as well, while getting rid of some obsolete ones.

Note that this article deals with the x86-64 ISA only. The sequel will cover the specific implementations (Hammer, Opteron, etc.). And note also that the general discussions of 64-bit computing that make up the first half of the article are applicable to 64-bit platforms, not just x86-64. So those of you interested in the implications of a possible Apple move to a 64-bit platform like the PPC 970 might want to read at least the first half of the article.

Why 64 bits?

The question of why we need 64-bit computing is often asked but rarely answered in a satisfactory manner. That this is so is evidenced by the fact that the question keeps coming up again and again in online discussions of AMD's upcoming Hammer processor. There are good reasons for the confusion surrounding the question, the first of which is the rarely acknowledged fact that "the 64-bit question" is actually two questions: 1) how does the existing 64-bit server and workstation market use 64-bit computing, and 2) what use would the consumer market have for 64-bit computing. People who ask the 64-bit question are usually asking for the answer to question 1 in order to deduce the answer to question 2. This being the case, we'll first look at question 1 before tackling question 2.

What is 64-bit computing?

If you've read my introduction to the basic concepts in microprocessor technology, "Understanding the Microprocessor," then you're familiar with the code/data distinction and its implications. (If you haven't read that article, you might want to at least skim it and look at the diagrams before going any further.) Simply put, the labels "16-bit," "32-bit" or "64-bit," when applied to a microprocessor, characterize the processor's data stream. Although you may have heard the term "64-bit code," this designates code that operates on 64-bit data.

In more specific terms, the labels "64-bit," 32-bit," etc. designate the number of bits that each of the processor's general-purpose registers (GPRs) can hold. So when someone uses the term "64-bit processor," what they mean is "a processor with GPRs that store 64-bit numbers." And in the same vein, a "64-bit instruction" is an instruction that operates on 64-bit numbers.

In the diagram above, I've tried my best to modify an older diagram in order to make my point. A quick recap, in case you don't remember the original diagram: black boxes are code, white boxes are data, and gray boxes are results. Also, don't take the instruction and code "sizes" too literally, since they're intended to convey a general feel for what it means to "widen" a processor from 32 bits to 64 bits. 

You should notice that not all of the data in either memory, the cache, or the registers is 64-bit data. Rather, the data sizes are mixed, with 64 bits being the widest. We'll discuss why this is and what it means, shortly. (I should've made the outgoing data stream on the 64-bit processor a mix of 64-bit and 32-bit data, but it would've been too much work to go in and change all of those boxes like that. As it is, I just used the resize function the whole batch and left it at that.)

Note that in the 64-bit CPU pictured above, the width of the code stream has not changed; the same-sized opcode could theoretically represent an instruction that operates on 32-bit numbers or an instruction that operates on 64-bit numbers, depending on what the opcode's default data size is. (Fore more on opcodes, see this page. We'll talk about the specifics of x86-64 opcodes in the next section.) On the other hand, the width of the data stream has doubled. In order to accommodate the wider data stream, the sizes of the processor's registers and the sizes of the internal data paths that feed those registers must be doubled.

Now let's take a look at two programming models, one for a 32-bit processor and another for a 64-bit processor.

The registers in the 64-bit CPU pictured above are twice as wide as those in the 32-bit CPU, but the size of the instruction register (IR) that holds the currently executing instruction is the same in both processors. Again, the data stream has doubled in size, but the instruction stream has not. Finally, you might also also note that the program counter (PC) is doubled in size. We'll talk about the reason for this, shortly.

Now, what I just told you above was the simple answer to the question, What is 64-bit computing? If we take into account the fact that the data stream is made up of multiple types of data--a fact hinted at in the first comparative diagram above--then the answer gets a bit more complicated.

For the simple processor pictured above, the two types of data that it can process are integer data and address data. Ultimately, addresses are really just integers that designate a memory address, so address data is just a special type of integer data. Hence, both data types are stored in the GPRs, and both integer and address calculations are done by the ALU.

This article was first published in March, 2003.

Expand full story

0 Reader Comments

You must to comment.