IanG on Tap

I have to agree with Chris Sells here. (In case you're reading this offline and are wondering what on earth I'm referring to, he's talking about the fact that Intel have finally admitted that the Itanium is no longer their only 64-bit architecture. They will be releasing CPUs with a 64-bit evolution of the venerable x86 architecture, much as AMD have already done. Chris concludes that competition drives processors' quality up and their prices down.) However, I'm considerably less upbeat about this development than he is.

While I can't really argue with the economics, I think this outcome is technically undesirable.

The lineage of the x86 CPU is long and involved, and the architecture has a lot of historical baggage as a result. For example, I'm not sure how many people are still relying heavily on the source-level compatibility feature that allows them to put their 8080 assembly language source through an 8086 assembler, and have everything still work. That was important three decades ago when the 8086 first appeared, but does anyone care now? (And that's not a typo - it is roughly three decades. The 8086 came out in 1976, so presumably the design process started at least 30 years ago.)

I suspect nobody would notice if their new 64-bit CPU wasn't able to run their favourite old 8080 programs. But this feature will be with us for as long as the x86 is with us. Even when original rationale for such features has long been irrelevant, every new x86 CPU still has to support them because it has to be compatible with its immediate predecessor. (You could call this cruft by induction.)

I resent that fact that resources are devoted to supporting such vestigial DNA (both on-chip resources, and engineering resources at AMD or Intel). I'd rather these were devoted to improving features that are relevant today. (Or making the chip cheaper. Either is fine. Or even increasing AMD and Intel's profits... I just resent paying for historical features.) The move to 64 bits seems like it should have been an opportunity to drop this baggage. (Or at least sideline it, so that it has nothing to do with the core architecture of the processor. Much like the support for 16-bit applications in Windows is pretty much isolated to the 16-bit subsystem these days, rather than permeating the whole OS.) But it now looks like that may never happen, so as a consumer of processors, I'm going to have to keep on paying for that baggage. Moreover, I can't help but think that the cost to Intel of developing not one but two 64-bit processors is going to end up getting passed on to me too.

So that is why I'm slightly disappointed to see the yet another rehash of the same old architecture with its 8-bit roots come out on top. (Of course I don't know much about processor design, so I could easily be complete wrong... Maybe it isn't that expensive to keep supporting all this goop. But it surely can't be free.)

Playing devil's advocate though, it does seem a bit like the late 1980s and early 1990s all over again. Back then, the 32-bit x86 architecture was technically one of the least desirable options, compared to the cleaner, faster contemporary RISC processors. Also, its complexity made it expensive to develop - Intel did eventually manage to redress the performance gap, but at vast expense. However, its compelling continuity story enabled it to achieve sufficient volumes to offset the expense of its considerable complexity.

But the current x86-64 vs Itanium situation is not quite the same thing. The continuity proposition of the 16-bit to 32-bit x86 upgrade path was simple: the 80386 was the only 32-bit CPU on the market that could execute your 16-bit applications without requiring some kind of translator or interpreter. AMD don't have that same advantage today - the Itanium is quite capable of executing 32-bit code. The main technical difference is that while AMD's 64-bit CPUs seem to be aiming for high 32-bit performance, the Itanium's philosophy seems to be that its 32-bit support is there for compatibility rather than performance.

Perhaps what Intel should have done was produce a couple of Itanium revs with 32-bit performance that was at least as good as their 64-bit speed. During the transition from 16 to 32 bits, almost 10 years elapsed between the first 32-bit x86 CPU (the 386) appearing, and the arrival of a CPU that sacrificed 16-bit performance significantly in order to favour 32-bit performance. (The Pentium Pro was the first to do that, and even at 10 years it was arguably premature - there was still an awful lot of 16-bit code out there at the time.) If Intel had taken the same approach with the Itanium, maybe it would have been more widely adopted by now. And then we wouldn't be saddled with 8080 compatibility for another 30 years...

Then again, could it possibly be that the comparatively low cost of AMD's offerings might really be the dominating factor here? The cheapest Itanium system price I could find on the net just now here in the UK costs just over £4100. The best price I've seen quoted for a 64-bit AMD system is staggeringly low by comparison - an almost unbelievable £423! I'm a technology fan, and I like the idea of having an Itanium, but it's just eye-wateringly expensive.

Of course you could argue that these two issues - the high cost and the poor 32-bit performance - are just different sides of the same coin. The Itanium's real problem may well be that Intel simply didn't aim it at the mass market, and the disappointing take-up suggests that this may have been the wrong strategy. (Of course it's easy to say that with hindsight. All those years ago when the Itanium project got started, the projected margins for 64-bit systems probably made for an extremely compelling business case. But the industry has changed since then.)

But is bringing out a new (for Intel) 64-bit architecture really the answer? Mightn't it be better to have produced an Itanium-Lite? (Or 'Litanium' if you prefer.) As I understand it, the existing Itaniums have a high performance 64-bit execution system and also a 32-bit unit with indifferent performance. Couldn't they have produced a version that's the other way around: something that provides excellent 32-bit performance, and supports the 64-bit architecture, but with less good performance than offered by the existing systems? They could pitch this as the 'cheap' Itanium to get people to start upgrading, and then build on that to sell more high end systems..

Perhaps they cared too much about being perceived as a serious 64-bit player, and worried that a low-end play would ruin their credibility with the high margin customers they were aiming for. But then Intel already has a pretty good history of gradually encroaching on turf that was once regarded as Sun's natural territory. Couldn't this bottom up attrition have worked as well for Itanium systems as it has with Xeon? (But then I don't build processors for a living. Maybe this just can't be done, and maybe that's why Intel has gone down the 64-bit x86 path.)

(By the way, there's something I'm also not clear on: is the 64-bitified x86 architecture that Intel are releasing going to be compatible with AMD's equivalent? Or are there now three 64-bit architectures in the Wintel world? (Itanium, AMD64, and this new Intel thing?) I've read several articles on this trying to find an answer, with inconclusive results... Most articles don't even mention it and those that do state it as a question that is as yet unanswered. I've got the reference manuals for both, but I don't really have time to read them through side by side to work it out just now... Although I notice that they both seem to have the exact same extensions to the register file, including the 8 new registers called R8-R15. The new REX prefixes look similar too. So even if they're not identical, the new architectures are pretty similar.)

Update:Apparently it is AMD64-compatible. None other than Linus Torvalds was, not unreasonably, annoyed at the lack of clarity and said so in this discussion. But it looks like someone did actually go through the manuals side by side, and the Intel 64-bit extensions are essentially identical. (Or at least as similar as Intel's and AMD's 32-bit processors are, i.e. enough to run the same code, which is what matters.)