INTEL: IT'S TIME TO SHARE
By Gregp on Jun 07, 2005
Apple's decision to move to the x86 architecture will have enormous implications for ISV's. Applications will have to be re-compiled, re-tested, and re-certified, including the mother-of-all of Apple's apps: Mac OS X. "Which processor is that?" will be added to the decision tree for thousands of support techs. All of this at substantial costs and, no doubt, user confusion. Trust me on this, for our support of Solaris 10 across SPARC and x64 is a lot more than an expensive hobby. It's real work and real money.
And it's all a needless waste.
We, meaning the industry, a long long time ago should have converged on a single, completely open core instruction set architecture (ISA). Why? Because ISA's have mostly lost any differential end-user benefit, while creating a whole lot of costs. Those costs being the aforementioned ISV certification and support of different binaries. Those create artificial switching costs, which in turn creates market friction, which in the end means higher prices and less choice for consumers.
The really tragic part is that it doesn't need to be. We've long had our choice of open architectures (e.g., SPARC and MIPS), But the "tyranny of binary compatibility" has now driven even Apple to a proprietary one: Intel's.
I often get that quizzical look when I describe x86 architecture as proprietary and SPARC as open. But those are the facts. We have long since shared SPARC. We help set up SPARC International as independent body, and anyone can register with it for as many chips as they care to make for only $99. It's even an IEEE standard, and completely open and without royalties.
And x86? Go give Intel $99 and tell them that you want to stamp out millions of chips that say "Intel Architecture Compatible" on them. Tell them that all you want is to copy the ISA. You will do your own implementation with your own design team and own intellectual property. And exactly what do you think they will say? Exactly.
I'm talking about the ISA, not the implementation. The distinction is an important one.
Certainly through the mid-nineties the simplicity of RISC architectures permitted superior implementations of high performance microprocessors (just as they are today enabling comparatively more aggressive multi-core and multi-threaded microsystems such as Niagara). Just to be clear, while the differences among RISC architectures (SPARC, MIPS, Power, Alpha,...) doesn't lead to any discernible ISV or end-user benefit, the differences among their implementations can and do: the absolute and relative price, performance, reliability and power consumption. The fact that the implementations differ is all about design teams, their goals, and their execution.
Apparently, IBM did not execute well in the performance-per-watt part of the low power space. Actually, Apple must have felt very negative about IBM's low-power futures at a time when laptops are starting to exceed desktop volumes. The PowerPC architecture is just fine. IBM's engineering isn't.
In contrast, x86/x64 is truly ugly, architecturally speaking. What's great has been Intel's and, more recently, AMD's implementations. Intel did a masterful job executing the 32-bit portable Centrino and the Xeon server lines, and AMD is kicking some serious butt with the 64-bit Opteron. All of this in spite of a nasty ISA.
So, the actual ISA doesn't really matter any more computer-science-wise. Intel makes its money by making good chips, but it supports the margins on those chips by effectively limiting the competitive field. Intel is a high volume, but nonetheless proprietary, chipmaker.
One answer to all of this would be to create a Lessig-like Commons. Essentially, accept that all of society and the whole of industry is better served when ubiquitous, royalty-free, interface standards belong to everyone (e.g., TCP/IP, radio modulation, etc.).
That could have come about two ways. Ideally, it would have been a process lead by academia (particularly appropriate because, IMO, microprocessor makers have done much more harvesting of academic research than they have made contributions.)
If I'm feeling especially surly, I label the lack of a concerted academic effort to define a standard ISA and quietly allowing their research to further proprietary industry ones, as one of the Great Failures of the computer science community. Shame on all of us.
Given that it didn't happen, and we are most definitely at the point where yet another ISA would be about as exciting as a new indoor plumbing standard, it's up to us in the industry to let the proprietary ISA era fade to black.
One way we do that by simply removing the patent and copyright claims to all of our instruction set architectures. Let any design team in the world choose, royalty free, to pursue whatever architectural path they wish. To participate in the evolution of our computing commons. It's called sharing.
We've been sharing SPARC for years. I challenge Intel to share their ISA in the same way. You too, IBM.
The other way we free the market from proprietary instruction sets is through virtual machines. The byte codes of the Java Virtual Machine (JVM) are the binary of an ISA. It's just that (almost) all implementations are very efficient software layers that abstract the underlying physical machine, making its identity irrelevant. It's a huge developer benefit because they can spend most of their energy developing and verifying to the JVM independent of the actual implementation. That cuts multiplatform support costs markedly. Double bonus is that writing to Java is also significantly more productive.
Apple, imagine that most of your software and that of your primary ISV's were written in Java. Just think of how much easier your platform change would be! To help you get started we've got some terrific tools, free for the taking.