AMD's New SledgeHammer: 64 bit chip
ChickenBomb wrote to us with word that perennial battle between Intel and AMD is continuing with AMD unveiling plans for their new 64-bit microprocessor, code-named SledgeHammer. Heck of a lot better name then Itanium, IMHO.
This reminds me of the time when Intel introduced the 8086. Back then, ZiLOG with the Z80 was a real force in the market competing with Intel's 8080, Motorola's 6800 and Rockwell's 6502.
Then came the 16 bit revolution (when we really needed more - the 16-bit minicomputers running out of space should have been the clue.)
The competitors were:
Intel with the 8086
ZiLOG with the Z8000
Motorola with the 68000
National Semiconductor with the 16032 (later called 32016)
In technical terms, the order of merit was 16032, 68000, Z8000, 8086. In marketing the 8086 was way ahead, but I think the 68000 was next.
Only two of these gained any substantial market share, and the 68000 had the advantage of being really a 32 bit processor. The 16032 was a better 32 bit processor, but it was just too late arriving.
If AMD have some technical feature of the scale of 32 vs 16 bits back then, and they are also far enough along with the development that they can ship at most a few months behind Intel, they have a chance of competing in this space. The more likely outcome of developing an incompatible processor is that we will see them reinvent themselves in some niche market in a few years time as ZiLOG have now done.
The Open Source community may well be able to use SledgeHammer when it arrives, but the software shipped as binary will ship for itanium first (or only), and that will be what counts.
It will work well for AMD because it is a compromise solution. The PC industry is completely built on compromises because the masses like to take small incremental steps. That's just how evolution works; large mutations are risky, and escaping a local optimum is expensive. It looks like Intel tried to introduce real technological progress, and now they're going to face a threat from someone who is going to use their very own stepwise refinement doctrine.
I don't know whether to be happy or sad about this. I hate seeing low tech win again, but there's such satisfying justice in seeing Intel stabbed with their own weapon, wielded by someone who uses their old(?) philosophy. Yes, I hope AMD goes ahead with this, and makes a mockery of the PC industry for another 20 years. Maybe that's my hatred talking, but I just can't help it. Even if the new boss is the same as the old boss, it's going to feel soooo good to see the old boss suffer.
---
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
Do we really need another 64-bit CPU when there is already a really great one languishing on the sidelines? Alpha AXP runs Linux extremely well and is the fastest microproceesor out there. Don't get me wrong... I love AMD's offerings--I've got Linux boxen running on their 5x86, their K6 II and K6 III lines, and I'm hankering for an Athlon, but Alphas are a sweet machine, and you can get 'em now. I guess I'd have a more welcoming attitude if I thought it would help drive down entry-level price points for the other offering like Itaniums and Alphas.
One viagra in the morning before work; I just know I'm gonna be screwed
Intel realizes this, I think. But on the other hand, the clock is ticking on the life expectancy of _every_ 32-bit chip. If you average desktop system being sold today has 128M of memory today, and that number is doubling every 18 months, then in 4 more doubling, or 6 years, the average desktop system will have 2 gig of ram. Already it's not unusual to see large servers with 10's of gig of ram, and high-end workstations with multiple gigs of ram. Intel is the _only_ desktop & server chip manufacturer still selling only 32-bit chips.
The 386 was released in 1986 IIRC. It wasn't until 1995 that Microsoft managed to release a broadly-accepted 32-bit OS. And the situation doesn't look any better today. But Intel can't wait ten years for Microsoft to get it's act together. This explains Intel's sudden support for Linux- it's one operating system that Intel can assure itself will be running on Merced (if you want something done right...). Intel already has had experience with the GCC compiler (remember pgcc), and once GCC is ported, even Linus agrees that porting Linux is easy.
Folks seem to have the idea that companies, chip or otherwise, are somehow single-tasking entities. This couldn't be further from the truth. Most chip companies work on several projects in parallel, and if it's a competitive line such as CPUs or 3D graphics chips, these projects overlap (this has been SOP at Intel & Motorola, for example, since the 80s). AMD previously mentioned that the design team derived from the NexGen team, the folks who did the K6, are not the people behind the K7. So, presumably, they aren't sitting around playing Quake III, they're working on something new. More than likely, it's a CPU, and since these folks have proven pretty hot on architecture in the past, doing so in the present wouldn't be a surprise. As for Athlon, it's in production. Unless they do any more true versions of the chip (eg, K7-2, etc) or have major production problems, there is no chip designer work left on the Athlon project anyway. Whatever they're doing now is more than likely process tweaks, die shrinks, etc. That's different people, unless there's some redesign necessary along with a shrink -- anyway, not enough work to occupy a whole uP design team. So these guys are likely on to bigger and better things now, too.
-Dave Haynie
A lot of people complain about Java because it's Run Everywhere theory isn't overly useful to them. They get pretty good portability from C, and why would they want to give up the processing speed for a questionable advantage?
But I see a lot of people here saying that AMD's "compromise" will succeed cause it won't force developers to port everything all at once. It'll save a lot of work, so it'll succeed over Merced. Some also bemoan that this means a lesser quality chip will win. A drastic change in architecture is too risky, they say.
But, Java is also portable to anything new that comes along, so an advantage of the VM architecture is there isn't as much reason to fear drastic innovation in the underlying hardware. This is major, IMO. My code will work anywhere, once someone ports the VM to it. A single port, and everyone's code is brought to the new hardware. This is why many people argue that the greater flexibility of the VM architecture is worth the relatively minor performance hit and even the larger memory hit.
First, make it work, then make it right, then make it fast, then, make it bloated!
From what I understand, they made the name Pentium because of copyright issues. Apparently a bunch of small no name chip competitors were trying to pass off their chips that had 486 on them, as Intel chips. People would see the 486, and assume it was an Intel chip, when it might not be. So Intel named the 586 the Pentium so those companies couldnt' trick consumers as easily.
This is definitely a compromise solution, but it could work well for AMD. I think that Intel is underestimating the need for backward compatibility (and high performance backward compatibility). Intel is convinced that they now have the market presence required to force the move to an entirely new architecture.
The only problem is if there is an alternative, and AMD appears to be poised to offer just such an alternative.
If they can deliver on the performance end, and I think they can, they will offer a much more attractive solution to users and developers. Users won't have to upgrade apps and OS to get better performance, and it sounds like developers of high end apps might have to make only minor changes to adapt their software to use the 64 bit aspects of the chip.
AMD has essentially decided to continue in the path that Intel has followed for the last 15 years. Intel has decided to veer off that path in favor of a new architecture. AMD has decided that there might still be a few years of profitability in it, and I think that they are right.
-josh
Intel?? AMD??
To heck with both of them! I'm saving up for a Transmeta!
It's not so much the backwards compatability as the fact that the ISA was not designed properly in the first place. Actually, the x86 is pretty close to being a really good compiler target. The offset+base+index*scale addressing can be put to good use. The problem is the non-orthogonality of the instruction set (rep movs takes a byte count only in ECX, etc.).
The 386 was somewhat unfortunate because it seems to have come along "too early." My hope is that AMD will do one of two things:
Dynamic compilation (or "JIT" or whatever) has come a long way in recent years. I hope AMD takes note of it. By moving the more ugly parts of x86 into software, AMD can hopefully design a more efficient core for whatever 64-bit ISA they dream up. If it's built on x86, then AMD should put the 32-bit and 64-bit parts in hardware (adding the appropriate opcodes and formats to get a truly orthogonal ISA) and do everything else in software.
It will be interesting to see what happens.
--