Slashdot Mirror
64-bit Processor Next Year, Says AMD
Kill Switch writes: "There's this ZDNet article about AMD's announcement that they plan to introduce a 64-bit 'Sledgehammer' chip for the desktop (that's right, DEKSTOP); they also announced that they will be releasing new chips based on the new Mustang core and it looks like there will be way too many versions of this (various desktop, and server versions); and they announced mobile versions of the Duron and Athlon, based on the Mustang core." This could just be crazy enough to work! Updated 11:20GMT by timothy: wwelch contributed a link to a pretty good overview of the current 64-bit field, which of course excludes this just-announced AMD, but which helps put it all in perspective.
The x86 ISA is so defective that any reasonable assembly programmer who has used any other ISA would rather gouge out his or her eyes with sharp pieces of bamboo rather than deal with the monstrosity that is x86. Any potential extention of the x86 ISA to 64-bits will take one of two forms, neither of which is neccesarily pleasant:
*An extended set of instructions (akin to MMX, 3dNow!, or SSE) that operate on 64-bit words and corresponding memory operations that load/store 64-bit words using an increased address speed. This option seems to be the one that AMD will most probably use, since they stress compatibility with the existing ISA to such a great extent in their PR. This is also the worse option: we will still be stuck with the essential garbage that underlies the x86 ISA: 2 operand instructions, a limited register set, nonorthogonality of the instruction set, and numerous other flaws.
*The processor boots to x86 compatibility mode, then requires an instruction to bring it into x86-64 mode. x86-64 mode is a sanely designed ISA that addresses and performs operations on 64-bit works. We lose the limitations of a tiny register set, horrible instruction encoding, and the other flaws of x86. This option would be far superior to the first one, but if one is willing to go to such lengths to distance oneself from the original x86 ISA (thereby losing all compatibility with native x86 applications in x86-64 mode), why not just migrate completely to a new ISA and use those wonderful fabs for new Alphas or Power4s and include a token K7 or P3 for x86 compatibility? BTW, this option almost resembles the rationale for the monstrosity that is IA-64...
Most troubling of all is that x86-64 may bring back segments. I cannot stress how horrible this would be; application programmers from the days of mixed 16/32-bit programming will agree with me. In any case, we have been stuck with this sickening, illogical, inelegant, and inefficient instruction set for the past 3 decades; do we really want to put up with another 3 decades of this crap? I say, kill off x86 for good and move to a sane architecture.
Evaluating processor performance is not just a matter of multiplying (function units*data size*clock speed). Many issues need to be considered for advanced, out-of-order, superscalar processors, including decoder width, cache structure, branch prediction techniques, reorder buffers, pipeline depth, mispredict penalties, and base instruction set. Sledgehammer will probably come close, if not slightly surpass, current 21264 integer performance, but will fall somewhat short of FP performance. However, by the time that Sledgehammer does come out, 21264b (first in a hybrid .18/.25 process, then completely migrated to .18 micron design rules) will almost certainly have clock speeds comparable to the Sledgehammer; the EV68 will blow just about every commodity chip (ie. excluding custom vector processors) out of the water in any performance metric.
"Don't forget that you'll have to buy twice the RAM chips to get the same amount of memory (effectively.)"
Bullshit. The size of the base word will not affect the effective amount of memory, just the amount of memory that can be addressed. If you declare a 16-bit variable (probably a short, but ANSI makes no guarantees), it will occupy 16-bits, subject to alignment constraints.
"And programs will be about twice as large on your hard drive due to the 64 bit instruction words."
(Alpha) stage3-decompose.o: 213920 bytes
(x86) stage3-decompose.o: 264018 bytes
Here's a hint: 64 bit ISAs don't neccesarily use 64 bit instructions; the x86 ISAs variable length words take up as much (if not more) space than the fixed 32-bit words in more RISC-like ISAs.
"And there's no point in running a 64 bit system with IDE drives, so you'd best pick up some nice expensive SCSI drives, too."
IDE drives can offer entirely acceptable performance, although for a serious performance system or server, one would of course use SCSI drives or a RAID array. But it's definitely possible to use IDE drives with 64 bit systems.
"Some 16 and 32 bit code will recompile cleanly. I expect much more will not."
If AMD specifies the standard LP-64 programming model (longs and pointers are 64 bits, ints are 32 bits), I would expect a significant majority of the non-Windows software to compile relatively cleanly on the Sledgehammer (or other 64 bit processor). Most Windows software unfortunately won't, because of some poor assumptions built into MFC and standard Windows programming techniques that I won't go into here (specifically the assumption that sizeof(int)==sizeof(int *)==sizeof(long)).
This could be AMD's master stroke against Intel - if AMD can get application developers like Adobe supporting their 64 bit extensions, Intel will be in big, big trouble. Especially since AMD are promising 64 bit loving on the desktop, while Intel are still pushing the line that 64 bit is server technology.
It's interesting that Intel are being outmanoevered at their own game; for years, manufacturers would throw up technologically superior chips (680x0 in its heyday, the original ARM 2 line, the Alpha, PPC, etc) with better performance, but they would be unable to get much market penetration, since the market valued x86 compatability in 90% of cases. Now Intel is offerring (well, vapouring) a 64 bit architecture that offers second-rate ia32 compatibility and has a competitor claiming all the goodness of a fast 64 bit system with little or no loss for ia32 apps.
It will also be interesting to see how this affects the free software world. For example, free databases like Postgres could look more attractive with cheap, abundant 64 bit hardware to run them on. And, more than that, if there is a schism in the i32 world, with some people going the ia64 route, and some going the Sledgehammer, the ability to recompile open source apps to the arch that best suits one's own needs, rather than have purchasing dictated by a split applications market, could be a win.
> Will 16- or 32-bit apps notice a speed performance on a 64-bit architechture?
Certainly for apps that do a lot of 64-bit arithmetic, though that's probably mostly scientific applications rather than the familiar desktop application. Beyond that I'm not sure, and would like to hear opinions too. Will it help with things like graphics, since you would be able to wade through the masses of data involved in various transformations faster?
> Will 16- or 32-bit apps need to be ported or just recompiled to gain a speed boost?
It is supposed to be backward compatible with current x86 systems. Probably without even a recompile. It would almost be suicide for a company to push a 64-bit x86 architecture otherwise, since (so far!) the overwhelming majority of such machines would be bought to run Windows and Windows apps, and very many people would be very reluctant to buy a processor that made them throw out their fine collection of apps.
Similarly, software houses will be reluctant to ship 64-bit versions of their apps until 64-bit processors are common. (Witness that even Linux binaries are often still distributed for the lowest common denominator, the i386, though surely most of us run 486s, 586s, or 686s by now.)
The preponderance of existing 32-bit apps probably means that most users will not get the full benefits of the 64-bitness of the new processors. This is another area where users of OSS will probably reap the early benefits, since they will be able to recompile their apps as true 64-bit apps right away (probably after having a few issues tweaked), whereas commercial apps will likely continue to ship as 32-bit binaries for several years after the first 64-bit x86s hit the market.
As a final observation, these chips will surely price above even the high end Thunderbirds, which are already going to be too pricy for most people. I suspect that the early adopters of 64-bit x86 will mostly be people who need the number-crunching abilities. For others, it will initially be a status symbol (very important in the corporate environment, ya know!).
--
Sheesh, evil *and* a jerk. -- Jade
The idea of the CPU having two 'personalities', and distinguishing by a bit in the code segment descriptor was suggested in the days of the PPro, by one of Intels own engineers. I don't recall their name, but I do recall they were listed as one of the original developers of the 8051.
He claimed the 'x86'ness of the PPro took 7% of the die space. For an additional 5%, they could have added a second 'personality', and begun the migration to a 'cleaner' ISA some years ago.
Oh well...
Three cheers for AMD! (o8
So in other words, you're saying it's an Alpha killer?
---
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
I read the referenced RealWorldTech article well before seeing this information on Slashdot, so I'll give a summary of Paul DeMone's conclusions, as well as my impression of why Sledgehammer was excluded.
.18/.25 process, then fully migrated to .18 design rules. The clock speed (especially after it's contracting out to IBM) will become competitive again. 21364 will add improved SMP capabilities (and an improved cache) to the basic EV6 core. The 21464 will be an impressive 8-issue processor with simultaneous multithreading.
*Alpha: The reigning champion of the 64-bit processors battlefield. The 21264a (EV67) shipping now still has the best integer and FP performance of any processor. The 21264b (EV68) will be released in two phases: first as a hybrid
*PA-RISC: HP has not neccesarily given up on its own processors, despite its nominal strategic alliance with Intel's IA64. An enormous cache allows the current members of this family to keep pace, even without significant architectural modifications. Later members could
*Itanium: A bloated instruction set that is incredibly ornate. Heavily dependent on compiler technology. Lots of marketing hype that exaggerates the true technical merit of the Merced processor. The Merced will debut at a relatively slow clock speed, but McKinley (HP's 2nd generation IA64 CPU) will definitely been a key competitor in the 64-bit HPC market.
*Sparc: Poor in performance, but software application support keeps these Sun processors alive. Even the not-yet-released UltraSparc 3 will have disappointing performance relative to modern processors.
*MIPS: Fading out.
*Power: The Power4 looks very impressive, but not much information has been released about it to this point.
The Sledgehamer is simply not a very interesting chip; it is generally agreed that x86 had the misfortune to become the most popular desktop ISA, without regard to its actual merits. An extention of x86 to 64-bits does not interest people much, essentially because of how ugly, inefficient, and inelegant the original x86 ISA is/was. Speaking for myself, I certainly do not want to have to put up with 30 more years of this defectiveness.
From Here
AMD has disclosed specifications to the major OS vendors and Microsoft so that they may ensure that their operating systems and tools will be AMD x86 64-bit aware
AND
"By extending the x86 instruction set to 64-bits, AMD's x86-64 technology should give us very fast compiler retargetting and the easiest kernel port so far," said Alan Cox, Linux Kernel Developer.
-----------------
It looks like a real battle ahead for Intel.
Is it possible that this could mark the start of an age in which our desktop chips and our portables are inherently different? I have serious doubts about Intel's ability to scale down Itanium to laptop scale and power consumption. Now it looks like AMD is going the same way, too. Many of the high-performance architectures, PPC joyfully excluded, don't even attempt to be portable. I'd like to think this is just a temporary condition, while manufacturing processes are improved, but I think with the physical limits we're looking at, even PPC may not be too far away on this trend. Hopefully we can see crusoe-like innovation on the portable end to offset the pain, but don't be surprised if portability means a different instruction set in the near future, or at least a different native one, regardless of what may be emulated.
WARNING: there is a trojan on your
Individual processes can select which instruction set they wish to run in, IA32 or IA64, even though the kernel is executing entirely in the IA64 instruction set. We've added IA32 kernel interfaces to match the system calls available currently on the i386 Linux kernel. This is not vaporware, this is running and has been publicly demonstrated at conferences this year.
Currently I've run IA32 versions of bash, gdb, gcc and netscape. All of these programs are running now with no known problems. I'm sure there are IA32 programs out there that don't work yet but my goal is to make sure that eventually all IA32 programs will run on the Itanium.
I admit to having a bias on this subject as I work for VA Linux and my job is to help create Linux for the IA64 processor.
--
--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
What ZDNet didn't mention is that the Mustang based processors will be SMP capable. The north bridge used for these processors will provide two separate host processor busses giving each processor full bandwidth to the bridge (as opposed to shared bandwidth, as with Intel) but limiting SMP to two processor configurations.
2 34&cid=194
See my earlier post at http://slashdot.org/comments.pl?sid=00/05/19/1822