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.
You are correct - instruction set doesn't make a difference to most programmers' code. A few places where it _does_ make a difference are:
Some features of an instruction set and chip architecture make it easy to optimize code to run quickly. Some features make it harder. With 4 general-purpose registers, and only two or three more that you might be able to use for storage in a pinch (3 of ds/es/fs/gs), you have to keep fetching operands from memory if you're dealing with many variables at once. Even with a cache, this is slow. It also makes things like loop unrolling much harder.
The core of any optimized graphics driver will have hand-tuned assembly. This isn't just for software rasterizers - this is for geometry engines and the like also, which are still around in abundance.
As these do much deep mucking about with the processor state, many pieces of these have to be written in assembly (take a look in
None of these will be issues for most programmers, but they still do come up, and all programmers working on code where speed is important will notice the effect on compiler optimizations.
Any potential extention of the x86 ISA to 64-bits will take one of two forms, neither of which is neccesarily pleasant:
You overlook the third way - apply the same kind of extension as is used for 32-bit.
Early x86s were 16-bit chips. When the 80386 came along, a kludge was implemented to allow 32-bit - add 0x66 in front of any 16-bit instruction to make it work on 32-bit operands.
The obvious way to add support for 64-bit instructions without adding a new processing mode or bloating the instruction set is to find another unused byte code and declare it to be the 64-bit specifier.
Code looks very similar to 32-bit code, all old code still works, and you have very few headaches porting a compiler to the new platform.
The _best_ thing to do is abandon the architecture completely, but if that's not an option, this is probably the cleanest way of extending x86.
"Fresh on the heals of the AMD announcment of a 64 bit processor, Microsoft announced that they would release a 64 bit version of Windows as soon as they could convince chief architect Bill Gates that "long long" wasn't his penis size."
-- Happy 4th From Jordo --
Do you have Linux and a DotPal? Click here now!
"Sledgehammer" is a completely cool name. Don't change it to some marketroids idea like "Athlon Pro". I want to be able to tell people that I've got a Sledgehammer!
General Relativity: Space-time tells matter where to go; Matter tells space-time what shape to be.
"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.
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?
Memory copies on the x86 are already 64-bit due to a sneaky hack - MMX loads/stores have been 64-bit for a while, and thus take one clock. Of course, you still have the MMX/FP switching overhead.
I don't really see much that could speed up existing code. The only 64-bit transfers that go on (MMX and FP loads) are already handled as 64-bit transfers.
If you're writing a 64-bit application, then yes, many things will be faster (due to you now being able to hold double-precision floats in one register if nothing else), but that involves at least a recompile and possibly additional tweaking.
It's a ZDNet article. It's not News for Nerds: it's News for Dummies. And your average dummy would probably not make the conceptual leap from "major OS" to "that must mean Microsoft, too."
What is interesting is that someone thought it important to not panic the Windows users. Imagine if ZDNet's readers were to think that the AMD Sledgehammer wasn't going to be Windows compatible. The poor chip would never sell!
--
--
Don't like it? Respond with words, not karma.
The nice thing about Sledgehammer and any derived desktop versions will be that the processor core will be able to recognize between 32- and 64-bit apps, and switch between them. I'm not sure if it's still true of the current design, but early on the AMD folks were saying that Sledgehammer would be able to work with 32-bit apps by effectively "splitting" the core as if it were 2 32-bit x86 cores working in tandem, therefore doubling the number of 32-bit instructions that a normal core would be able to deal with at any given clock cycle. Likwise, for 64-bit apps the core would work in lockstep like a normal 64-bit core. Interesting, if the concept still holds true...
/.ers bitch about x86 being such a horrible ISA (it is, but who cares unless you're unlucky enough to have to code in assembler...), and about the desire for backwards-compatibility holding tech back (sure it does, but it also saves time, effort, and apps, for the user), there are advantages. First of all, I'll still be able to multi-boot Windows 98 on my future Sledgehammer to play all those wonderful old DOS and early Windows games I've collected over the years and come to love dearly--it'll be ages and ages before Linux or anything else is able to effectively emulate Windows well enough to get top-notch performance from even fairly old games, and even then most of that will be thanks to increased processor power (like emulating an Apple ][c on my 400MHz processor--easy because the whole damned machine can be executed virtually thanks to processing muscle many, many times more than the original). Not just that, but businesses with legacy, custom x86 software will be able to upgrade with virtually no software costs. Backwards-compatibility may induce cruft, but is often desirable for both personal and business reasons. I look forward, two or so years from now, to being able to run 64-bit Linux, Windows 98, BeOS, and maybe Windows 2002, all on the same AMD box. Now, if only someone would create a VMS environment for x86... ;-)
At any rate, it *will* be able to run 32-bit apps natively, not through emulation as with Merced--err, Itanium (dumb name). As much as many
"The more corrupt the state, the more numerous the laws."--Tacitus, *The Annals*
> 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
For existing x86 32-bit code, I expect the Sledgehammer to perform significantly better than the Merced in all respects (for equivalent clock speeds). For heavily numerical or scientific programming, I expect that the Merced will do better than the Sledgehammer, even with a significant clock speed differential (the Sledgehammer will probably release with a > 300 Mhz lead over the Merced). This is especially so for tasks such as encryption, large integer arithmetic, computational linear algebra, and certain other applications of this type. One must keep in mind that the Merced can potentially execute 2 bundles of 3 instructions each every clock cycle (and that some instructions can perform more than one operation on multiple operands); optimistically, Merced can perform something like 12 discrete operations every cycle (on full width words, no less). For general purpose applications(non-server, non-computational codes), before the IA64 compilers mature, I think that the Sledgehammer would do better.
The "spliting the 64-bit core into two x86 32-bit cores" idea could not possibly work efficiently. It is quite safe to say that the AMD folks must have come to their senses by now and abandoned any thought of doing Sledgehammer that way. A modern chip trace (say an adder) is highly optimized for the word size and rely critically on signal propagation delay for the most efficiency. Spliting (using the previous example of an adder) into 2 32-bit adders would result in totally incorrect results or a nonoptimal implementation, at which point one is better off just designing the functional units seperately.
x86 *is* a terrible ISA and backwards compatibility *does* hold back tech, both in terms of performance and price/performance. If we were not shackled with the x86 ISA so pervasively, the design and fabrication talent that Intel and AMD so obviously possess could have been far better used to design chips whose performance would have been incredible. My reasoning is that if one is willing to go so such lengths and create a new ISA (albeit one that is supposedly compatible with x86 and that extends it), thereby requirely new compilers and OS support, one should go all the way and just start from scratch and use a decent, sane, reasonable ISA.
I thought the AMD Moron chip was somehow a combination of "More" and "Athlon". Looks like it is really Mobile + Duron.
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
You understate the case. Every modern general purpose CPU implementation is "design symbiotic" with a targeted modern compiler(s). The primary distinction between RISC/CISC/VLIW/etc. architectures is the tradeoff of work between the CPU and the compiler. (Go dig around in the technical documentation at the TI 'C6x DSP web site for a fascinating view of how a modern VLIW architecture impacts processor and compiler design.)
The architectural decisions in hardware must be borne out by a compiler that leverages these features to the fullest. Likewise, the implementation of a CPU must actively enable the compiler to take maximum advantage of hardware bandwidth. Once the chips tape out, both Intel and AMD MUST ensure that the compilers measure up -- or else they've run half the race and given up.
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
Does this mean that JAVA gets an Extra Long? And maybe a Quadruple? And now UNICODE can expand to 8 bytes per character. Get to include extraterrestial character sets like Klingon and Vulcan.
Wovon man nicht sprechen kann, darueber muss man schweigen. Ludwig Wittgenstein