AMD's x86-64 Moves Forward

MBCook writes "AMD Hammer line is definatly moving forward. The Inquirer has a supposidly leaked memo from MS saying that they have working x86-64 silicon that runs both 32 and 64-bit Win XP. Van's Hardware is reporting that MS is backing x86-64 over Intel's IA-64, and that MS has apparently convinced Intel to move to x86-64! There is an article over at Ace's Hardware from CeBIT that includes some coverage of AMD's Hammer line (including its NUMA). Last but not least is News.com's report that MS is preparing Windows to support NUMA." And it looks like the line will be named Opteron.

Comments

Re:Nice. M$ once again stifles innovation ...

[mark_space2001]

Well, that may be true, but the article at Van's Hardware says AMD's architecture is actually better:

Our sources also allege that top Microsoft decision makers view x86-64 as the clearly superior solution over IA64, an underperforming VLIW architecture widely judged as Byzantine.

It goes on to point out that AMD has filed more patents in the last 3 years than Intel, and that AMD is widely seen as the true inovator between the two companies.

I can't say what's correct myself, but I think you may be jumping to conclusions.

Re:Nice. M$ once again stifles innovation ...

[mikefoley]

The Alpha proved that the MARKET is not ready for a non-backwards compatible chip.

It's not what I want, it's not what you want, it's what the MARKET wants. I know. I used to work at DEC/Compaq and API. The market drives technology, not the other way around.

If you read about the architectures, you'll see that when you compare x86, x86-64, IA-64, and Alpha, that -technically-, the Alpha was the best. However, it's applications that call the shots. x86 might not be as "elegant" solution as IA-64, but it allows easy migration to 64-bit computing without the expense of moving to a totally different architecture. It's a low risk solution. You can convince your boss to update your servers to these new fast AMD systems and run your apps as is, then be a hero when you migrate some big database to use 64-bit addressing and memory management without buying a new server!

I fully expect to see Clawhammer-based motherboards and CPU's at around $300 or so LONG before you'll see IA-64 at that price point. That alone will push x86-64 from the ground up.
(And because of architectures like Alpha, Linux will be ready to roll, fully 64-bit) Not to mention laptops running on Clawhammer!

Noooooooo!

[Burgundy Advocate]

Dear God! How fucking lame!

Another hacked on extention to the same old architecture that we've been using since the 4004 and 8080 (no, seriously). The basic 8-bit core, the bizarrely segmented registers, the warped-ass extentions, and the CISC instruction set... it all makes me sick. Not to mention that we're still using a fucking BIOS.

Have you ever used something with OpenBoot? It's incredibly nice.

But no, we're still using a system that's basically an overglorified 386DX.

Despite the speed hit, the IA64 architecture was a step in the right direction. A big step. In this case, AMD is going to be setting the industry back.

Re:The bit stuff, explain to a layman. TIA

[bentini]

Wow.

I disagree from an architectural standpoint. In an ideal world, we'd all have 8-bit machines. All our arithmatic would be insanely fast; we'd be able to use combinational logic to allow two probagation levels for ANY operation (add, sub, mul, div, sqrt, log, etc). That's because it's cost effective to do so; a minimal set of possible outcomes. I'm not completely sure, but I'll speculate that it's possible to arbitrarily generate an arbitrarily sized number from just these 8 bits; though most likely it would be programatically (even if done via micro-code), and thus would be non-optimal for larger than 8-bit data-sets. So obviously, as we've been able to, we've increased the data-length throughout history as we've demonstrated a need.

8 bits?! Why 8 bits? You make it sounds like this is atomic, when it's not. At all. If you're going to go for the theoretical minimum, go for 1 bit. The CM-1 used 1 bit processors, and could do everything. But why 8 bit?! That's sort of whack.

Another important factor (which is presumably obvious in concept) is that a higher word-size has a greater probability of wasted space. A 1-bit boolean, for example, wasts 63bits.. Booleans are very common, and though they can easily be consolidated in c-struct's, such is rarely the case, since there are memory alignment issues (and flat-out laziness on the part of programmers). The wasted word-space also affects the instructions. Rarely do you actually see 64bit aligned CPU-instructions (except in VLIW or in places that the data-word-size was irrelevant). Such a situation would have massive implications towards performance. But one serious consideration is that the population of 64bit constants using a 32bit instructional word is expensive. Now you have to perform at least 3 (probably 4 or 5) instructions just to load a constant. Suddenly "a++" starts to look scary (at least when non-optimal compilers are used). In all cases sub-word-size'd instructional arguments are permissable to the delight of compiler designers, but there are still classes of problems that thwart this.. Namely memory addressing...

A) consolidate in c-structs? Programmer laziness?
Don't bash the programmer, at all. That's just cruel. The programmer shouldn't have to. That's the compiler's job. However, that can often slow down the code, when it has to mask all the bits, op, then mask all the bits again. So, just using one word for a boolean makes sense. Surely, though, a compiler could do what it wans.
B) Constants get loaded into a different segment than the code, so they won't be in the code, most likely. Unless they're ints or somesuch, in which case you can just use an add-immediate to move them in, and in almost all cases (as you YOURSELF very specifically state) they won't take up more than one immediate.
C) "a++ looks scary"? Umm, a++ will still take one operation (add $rx, $rx, 1). What are you even talking about? Not to mention that compilers optimize.
D) You can still have 32 bit data values in a 64 bit computer by loading the words from memory differently, so don't think that suddenly EVERYTHING has to be in memory as a 64 bit value just because your architecture is that.
E) On a 32 bit architecture (at least, real ones), the 4 gig memory limit (2 on certain ones, e.g. MIPS) is per process, not per system. Thus, you can have many processors, each of which have 4 gigs of memory allocated and using running on a computer with 512K of memory. It would be slow, but that's the beauty of software.