Newsmaker: AMD hits its stride

(continued from previous page)

set of applications. Microsoft is now on the verge of the release of their (64-bit) operating system.

Everything I've just described, we dreamed would happen. That was our best-case scenario. In some sense, the scenario has turned out better than our best-case scenario. First of all, we didn't know when we started down this path that Sun would take an approach to bring Solaris as a first-class citizen into the x86 world and to bet a major portion of their future strategy around...Opteron.

Then something that we had hoped for was to have IBM, Hewlett-Packard and Sun using our products in the core of their most important businesses.

You've said, "You can't move software." What are you referring to? Are you talking about reforming hardware instead?
The AMD 64 and the 64-bit extensions we did (in the Opteron and the Athlon 64 in order to extend current 32-bit x86 processors to 64 bits) were all based on the idea that the (Intel) Itanium was an ill-conceived idea. There's no technical basis for the need to change (software). We can make high-performance computers either way.

The extension of that into the future is this idea we've been talking about for the last two years or so, which we refer to as "x86 everywhere." More and more devices are becoming computers. I don't mean that everything's a PC--your refrigerator is not going to be a PC. But more and more devices are becoming digital computers with huge software stacks on them.

As these software stacks get bigger and more sophisticated and complicated, the need for the value of an underlying common language increases. That's why the x86 processor has moved so well from the desktop to the laptop to the server, and today we're making huge inroads with it into the SAN and NAS market, into the embedded market.

What needs to be done to enable this is we and the other x86 suppliers need to make more variety of processors--lower-power ones, higher-performance ones, cheaper ones.

I think that the approach that we're going to take for the consumer electronics initially...is to start offering x86-based solutions for more and more consumer applications. I don't mean jamming a PC processor into a blender. What I mean is designing an appropriate x86 processor for appropriate devices--whether those be portable media devices, home media servers (or) a set-top box--designing the processor around the constraints of power, the constraints of cost, and bringing the value of this huge software base (to each new device category).  

More Newsmakers

[Andrew J Glina]

Buy now pay later

The AMD vs. Intel CPU war is always interesting. Even so, from the point of view of an assembly language programmer, it is a disappointment that AMDs 32/64 bit push appears to be winning. 64 bit personal computing, while unquestionably desirable, is not needed now and it probably would have been better to wait until the Itanium's price came down and the average system memory size was 2GB. (I have 256 MB and run Win2K.) Intel's pure 64 bit model would of produced better programs due to the elimination of 20 years of legacy support, but it is becoming increasing likely that the Itanium may never become a dominant consumer CPU. It was my hope that the 64 bit change would go smoother and be more distinct than the 32 bit one. The 80386 was the Intels first 32 bit chip and it came out in 1985. However it took 15 years until a mainstream OS came out that was fully 32 bit, and even now 16 bit software is still around. Will we now see a repeat with the 64 bit systems?

One of the biggest limitations of the x86 family is the low availability of usable general purpose registers. Registers are small areas on a chip that are used for short term storage and data manipulation. A high numbers of registers reduces the CPUs reliance on memory (including cache) which massively increases CPU efficiency. The Itanium has 128 General Purpose Registers, the PowerPC (In Macs) has 32, and x86 chips have 8. Much of the AMD64 increased efficiency of recompiled code is due to changing of memory access to registers. AMD64 chips double the amount (from 8 to 16) and size of the registers (from 32 the 64 bit), but they need to have a prefix prior to each 64 bit instruction so the CPU knows to treat the instruction. This contributes to why recompiled code is around 25% bigger than the 32 bit equivalent. It seems silly to me to be stuck with this problem permanently even if the whole world migrates to 64 bit computing and uses no 32 bit software. Besides, the current generation isnt much faster than Athlon XP processors of similar MHz unless run on a AMD64 OS using AMD64 optimized software.

The AMD64 (and their Intel clones) are not the revolutionary chips that many hail them to be, but they definitely are an improvement. Opterons especially excel in the multi-processor server market due their HyperTransport bus. The core design of the x86 dates back to the mid 1970s so why add another patch to an already over patched design? Eventually the mainstream computer world will have to make a clean break with the past, so why not now? It does make me wonder why the PC world can't pull off the same change as Apple did when they dumped 68000 processors and upgraded to PowerPCs. It was not without its fair share of problems, but in the end it was worth it.

(I will probably buy mine next year after the Windows XP 64 bit non-beta version is out. If you can't beat 'em...)

[billtodd]

The difference between theory and practice

is important here. Let's examine your points one by one:

"from the point of view of an assembly language programmer, it is a disappointment that AMDs 32/64 bit push appears to be winning."

And it's not *all* that much of an exaggeration to suggest that the number of people around the world so disappointed could all congregate in a single medium-to-large restaurant some evening and commiserate about it. I.e., that disappointment, such as it may be, is not really significant (and I say that as someone with a decade of professional experience doing nothing *but* assembly language programming).

"64 bit personal computing, while unquestionably desirable, is not needed now and it probably would have been better to wait until the Itanium's price came down and the average system memory size was 2GB."

Only if one accepts that Itanium would have been a preferable platform, which I'll address below. Otherwise, sooner is better, if for no other reason than that it gives developers the inexpensive platforms they need to generate the 64-bit application base which desktops will want to have by the time they'll want to have it (and of course *some* non-developers will be able to profit from it earlier as well - e.g., those heavily into graphics and video - plus Windows itself has some operating system bottlenecks which a 64-bit platform eliminates, even when all the user applications remain 32-bit ones).

"Intel's pure 64 bit model would of produced better programs due to the elimination of 20 years of legacy support"

That's a very debatable assertion. Despite being a new architecture, Intel and HP managed to trowel a fair amount of native cruft into Itanium (Alpha users porting there experience a 3-fold increase in code size, for example - and Alpha code is already somewhat less dense than x86 code).

"It was my hope that the 64 bit change would go smoother and be more distinct than the 32 bit one."

What you see as desirable, others do not.

"The 80386 was the Intels first 32 bit chip and it came out in 1985. However it took 15 years until a mainstream OS came out that was fully 32 bit, and even now 16 bit software is still around. Will we now see a repeat with the 64 bit systems?"

One might hope so. There's no earthly reason why the vast majority of existing 32-bit programs should *ever* need to be ported to 64 bits, as long as the available processors continue to run them at full speed. And, of course, there are a few hundred million people around the world with existing copies of these programs who would just as soon be able to continue to run them.

"One of the biggest limitations of the x86 family is the low availability of usable general purpose registers."

Fortunately, this 'limitation' is of interest only to theoreticians and to designers of compiler back-ends (which must generate machine instructions from the higher-level language input). Everyone else just cares about how the machine runs, and x86 code runs quite competitively indeed with Itanium code.

"Registers are small areas on a chip that are used for short term storage and data manipulation. A high numbers of registers reduces the CPUs reliance on memory (including cache) which massively increases CPU efficiency."

Well, no, it doesn't - because registers (at least in the role you're ascribing to them) simply constitute yet another level of cache (the term 'level 0' is sometimes used). So having more registers is only one way to skin the performance cat: having a very fast level-1 cache is another, and having a lot of extra 'invisible' internal registers (used by a mechanism called 'register renaming') effectively increases the size of the 'level 0' register cache without making those additional registers externally visible.

So massive numbers of registers (especially visible registers) fall much more into the 'nice to have' category than being anything resembling a feature of 'massive' significance. The proof is the performance-competitiveness of the x86 architecture with both its Itanium and RISC competition.

"AMD64 chips double the amount (from 8 to 16) and size of the registers (from 32 the 64 bit), but they need to have a prefix prior to each 64 bit instruction so the CPU knows to treat the instruction. This contributes to why recompiled code is around 25% bigger than the 32 bit equivalent. It seems silly to me to be stuck with this problem permanently even if the whole world migrates to 64 bit computing and uses no 32 bit software."

Hmmm. Doesn't it seem even sillier, then, to be stuck with something like a the *4-fold* across-the-board increase in code size implied by the Itanium architecture?

"Besides, the current generation isnt much faster than Athlon XP processors of similar MHz unless run on a AMD64 OS using AMD64 optimized software."

But it runs existing software *vastly* faster than Itanium does - in fact, about as fast as Itanium runs 64-bit software.

"The AMD64 (and their Intel clones) are not the revolutionary chips that many hail them to be, but they definitely are an improvement."

Given that they open the door to 64-bit computing without closing it on the existing 32-bit environment, while at the same time providing performance that no other architecture can beat (we are talking about cores here, not all the ancillary aspects like busses, memory paths, etc.), one might suggest that they're a very significant improvement.

"The core design of the x86 dates back to the mid 1970s so why add another patch to an already over patched design?"

Primarily to maintain compatibility with the tremendous existing base of software. IBM seems to have found this desirable in the mainframe environment which was predicted to have died decades ago: its current mainframes can (and do) still run some software written in the 1960s.

"Eventually the mainstream computer world will have to make a clean break with the past"

Care to explain why? If anything, technology advances make the expense of maintaining compatibility less and less onerous.

"It does make me wonder why the PC world can't pull off the same change as Apple did when they dumped 68000 processors and upgraded to PowerPCs."

It's not that it can't do that, it's that it has no need to.

"It was not without its fair share of problems, but in the end it was worth it."

And today it would not be.

- bill