It's been two years since Advanced Micro Devices first announced its 64-bit extensions to the x86 architecture, and just about a year since the debut of the AMD Opteron processor on April 22, 2003. AMD had the "64 bit extensions" field to itself until February 2004, when Intel Corp. announced that it would adopt similar enhancements its next-generation 32-bit Xeon processors. This, of course, serves as both a tacit endorsement of AMD's technology initiatives, as well as a potential indictment against Intel's 64-bit Itanium 2 processors. What does Intel's new direction mean for Intel, for AMD, and for developers?

There is no doubt Intel's 64-bit extensions will be plug-compatible with AMD64 instructions. Intel has made clear its intention that binaries with 64-bit extension will work without modification on both AMD and Intel platforms, in much the same way 32-bit binaries run on both platforms today.

A proof point will occur when Microsoft ships its versions of Windows XP and Windows Server 2003 processors with 64-bit extensions. The folks in Redmond were emphatic that they would only ship one set of "x86 with 64 bit extensions" binaries that would have to serve both Intel's Xeon and AMD's Opteron and Athlon 64 processors. Consequently, compatibility will be required and enforced by the community of vendors.

There are currently three versions of these Windows products available for beta testing. You can download the beta version Windows Server 2003 for 64-Bit Extended Systems can download it here. Members of Microsoft's Developer Network (MSDN) can download a beta of the Enterprise Edition of the server from the subscription download area. Windows XP 64-bit Edition for 64-bit extended systems, can be examined at here.

Similarly, Linux variants from Red Hat and SUSE among others are expected to run equally well on both processor platforms.

Despite the binary compatibility at the software level, however, it is unlikely that all device drivers will be compatible across systems. Given that the processors depend on completely different chipsets, the incompatibilities among device drivers are almost certain to arise. For many situations this will make no real difference, except to ISVs and hardware manufacturers who will be forced to develop and test drivers for both platforms.

For consumers, this issue will show up mostly on systems that push the hardware envelope, such as gamers' boxes. However, due to the early lead built-up by AMD systems in those areas, the problem of missing drivers is likely to occur more frequently for Intel-based systems, at least at first.

Intel's x86 Superset
While Intel affirms this binary application compatibility, it doesn't deliver the message exactly that way. Instead, the company refers to delivery of a "superset" of the AMD64 extensions. This might sound alarming to developers and system builder, but it really isn't.

The extra instructions that "superset" implies are 13 instructions added with the recent Prescott stepping of the Pentium 4 processor. These instructions, code-named Prescott New Instructions (PNI), are now officially referred to as SSE-3 (for Streaming SIMD Extensions. SIMD is itself an acronym for the capability to simultaneously execute a single instruction across multiple data items).

SSE-3 extends the multimedia processing that Intel has added to each major generation of processors. Previous generations included MMX, SSE, and SSE-2—which are all supported in the AMD64 architecture. The new generation adds math capabilities useful in Fast Fourier transforms (FFTs) and vertex shading.

In a presentation at Stanford University, Kevin McGrath, AMD's chief architect for the AMD64 architecture, stated that the next revision of the processor's core will support SSE-3. (A video capture of McGrath's talk can be viewed here.)

Intel also added a pair of instructions to enhance performance of Hyper-Threading Technology (HTT), which is the company's technique for making one processor core function like two. It's not clear how AMD will support the HTT instructions, since the processor does not have HTT capability, but perhaps a multicore implementation will provide the needed capability.

At that point, Intel's claim of a superset may no longer be accurate: All code will run on both systems without any special case handling or modification. However, it will undoubtedly run faster on AMD systems, given the fact that the Prescott generation did nothing to cut into the performance lead currently enjoyed by AMD64 chips.

Goodbye, Gigahertz?
In March, Intel announced that it is taking another page from AMD's playbook: it will soon abandon clock speed as the consumer-oriented measure of processor power. It's about time, too.

All serious users of processor technology know that clock speed is only one factor in overall throughput. AMD has argued this point for years, using its own numbering scheme rather than actually discussing the megahertz. While Intel has not announced the details of the new naming scheme, it has hinted at three-digit model numbers, in which individual digits refer to specific features such as RAM, bus speed, and clock. This particular pattern may look familiar to AMD64 veterans, of course.

There is irony in Intel's decision to cease marketing its processors by clock speed. The Prescott chip's execution pipeline expanded to an astonishing 31 stages (up from 20 stages in the previous generation of Xeon and Pentium 4)—a costly move whose only benefit is enabling faster clocks (because now each stage performs less work).

So why work to rev the clock and then choose not to promote it? The answer is pointed to in the February issue of Microprocessor Report, in which analyst Peter Glaskowsky points out Intel's Pentium 4 and Xeon processors started 2003 at 3.06GHz and finished at 3.2GHz—a paltry increase that is substantially below previous year over year increases in clock speed.

This slow increase came after Intel's substantial expansion of the pipeline in the Pentium 4. So, despite investing in technology to boost clock speed, Intel has recognized that clocks cannot be revved forever. As a result, it has been forced to recognize AMD's longstanding position that processor throughput is a better measure of performance.

Mimicry is Good
Some diehard fans of AMD64 technology have expressed concern that Intel's exact cloning of the technology might be detrimental to AMD. However, Glaskowsky points out that Intel's entry into the world of 64-bit extensions is unalloyed good news for AMD. Prior to Intel's move, AMD's 64-bit extensions had only technical superiority, but didn't have market penetration. Because no other vendor was selling chips with those extensions, conservative purchasers had reason to hesitate.

However, now that Intel has joined the fray, Glaskowski predicts, prospective purchasers will begin examining the technology on a comparative basis. For AMD, such comparisons are good news. As benchmarks have shown, the AMD64 implementation performs very well. We don't know how much better the numbers are than Intel's, because the latter chips won't ship until June at the earliest. However, due to the high-bandwidth Hyper-Transport processor-to-memory bus of the Opteron architecture, AMD will likely retain a significant performance edge. (See Transport Your Application to Hyper Performance.)

In support of the position that these developments favor AMD, we can see that the uptake of AMD64-based processors in server systems has advanced considerably since the Intel announcement. Hewlett-Packard has announced new product lines based on AMD64 processors, while IBM and Sun have expanded their offerings.

It is clear that Intel's adoption of the 64-bit extensions is a major boost for the architecture, and will actually help drive adoption of AMD's Opteron and Athlon 64 processors. And it's clear that as both companies continue their decades-long battle, buyers will enjoy the benefits of ever richer feature sets and amazing performance without having to worry at all about compatibility.