“You’d be surprised how hard it can often be to translate an action into an idea.” – Karl Kraus
“Siri, launch my compiler.”
“Alexa, run a.out.”
“Hey, Google, execute that old CP/M program for me.”
“Cortana, halt and catch fire. Ha-ha.”
Wouldn’t it be cool if your personal digital assistant could execute any task, and any program, on any operating system? We’ve been designing computers for several lifetimes now. Why can’t they be universal?
We all remember reruns of Star Trek and the occasional appearance of the “universal translator” device. Whenever the script called for it, an Enterprise crewmember would whip out an Amazon Echo–like device and wave it around, instantly translating any alien’s spoken language into… well, into whatever language Starfleet crews speak in the 23rd Century. Apparently, Enterprise had (will have?) a wireless broadband connection to Amazon’s servers.
But back here in the early 21st Century, we’re still writing and compiling code for specific CPU instruction sets. Our programs are tied to specific hardware architectures the way that VHS and Beta cassette tapes operated only with their respective players. “Hey, Mister, can I rent that copy of Saturday Night Fever on VHS, please?”
So why don’t we have universal microprocessors – chips able to execute any code from any source? If CPUs were universal, we’d have competition based on price, power, and availability instead of binary compatibility. The whole universe of CPU chips would open up to us, and we’d no longer be beholden to one (or perhaps a small handful of) CPU vendor(s). Open competition is a wonderful thing. We have a universal ASCII code for information interchange, universal hydrocarbon fuel for cars (almost), universal AC and DC power requirements for portable electronics (again, almost), and other universal standards. Why not for processors?
Transistors are so tiny now, and the average SoC is so comparatively large and complex, that today’s CPU cores occupy just a tiny fraction of the chip’s real estate. Surely there’s room for a slightly larger, more universal version.
And think of the software savings! Plenty of teams spend more time and effort developing their software than they do on their hardware. Most companies developing consumer electronics or industrial systems employ more programmers than hardware engineers. Software is expensive. Hardware, while not cheap, isn’t the cost determinant it used to be. If you could make your hardware, and thus your software, infinitely transportable, you could run any code on any system! No more recompiling; no more porting; no more dusting off that old assembly-language manual to try to figure out what the code is doing.
How hard can it be?
John von Neumann proved that any computer can operate on just two or three basic commands. It may not be very fast or efficient, but it’ll work. So, if all programs can ultimately be reduced to just this core set of operations – the ultimate RISC, if you like – then surely any code can theoretically run on any processor? Just a little hardware translation here and there, and voila! Instant universal translator!
There are even designers on the street with the relevant experience. Dozens of companies have built binary-compatible clones of the x86, ARM, MIPS, PowerPC, 8051, SPARC, and nearly any other machine architecture you can think of. So it is doable.
The x86 is surely the most complex modern processor family to be reverse-engineered and duplicated, so simpler architectures like ARM and MIPS would be a doddle in comparison. After that, adding in an 8051, 6805, AVR, and all the other 8-bit MCUs would hardly add any complexity at all. And, as long as you’re at it, toss in a Java interpreter (or most of one, anyway), a DSP or two, and your favorite GPU for graphics acceleration. Oh, and maybe an encryption engine. And a network packet processor! That ought to cover it.
Or you could go the other route and have just one actual CPU core, but with a bunch of runtime-translation hardware in front of it. All your ARM code, x86 code, AVR code, et al, would be translated on the fly right before it gets thrown into the maw of the processor engine. You could even implement the translation hardware in FPGA so that it’s field-upgradeable. You could sell updates! Want to enable 8051 translation, Mr. Customer? That’ll cost you an extra $1.95/month subscription fee. Order a whole year and get it for just $20.
You could even define your own hardware API and encourage third-party development. Your chip would become a platform for other developers to create and market their own binary-translation plugins running on your chip. Naturally, you’d take a cut of the revenue – say, 20 percent – but the independent community would do the technical dirty work for you. The more development they do, the more useful your processor becomes.
What’s holding us back? Alas, history proves to be our enemy here. History and economics. And patent law. History, economics, patent law, and marketing are all agitating against us. Historically, a lot of processors – in fact, almost every processor, at one time or another – has been duplicated and cloned. It’s hard work, but it can be done – mostly. Most CPU cloning projects stall at about 85% completion. It’s all smooth sailing right up until that point, but then the project hits the rocks. Getting your ADD and SUB operations to work is trivial, and that fuels optimism. Getting those last few instructions to behave properly takes even more work and saps all that earlier hopefulness. Most CPUs were hard to design in the first place. Repeating that whole process, including side effects (intentional and otherwise), is the real trick.
And then there’s the patent-infringement issue. Mnemonics and operations can’t be patented, but specific hardware implementations can. Some CPU operations have such peculiar and nonintuitive side effects that it’s difficult or impossible to duplicate them all without infringing on someone’s patent. Some low-level CPU operations seem almost designed to be patentable.
Then there’s the invisible hand of economics. Sure, you might get your universal CPU to work, but who’s gonna buy it? Everyone, surely. Except that the evidence doesn’t bear that out. Cloned processors have rarely, if ever, done well in the market. Some of that is due to customer skepticism and reluctance. If a CPU isn’t 101% compatible in every conceivable (and inconceivable) way, customers will always wonder whether that obscure bug they’re chasing is due to their code or to your hardware. They’ll never be sure, and being able to sleep peacefully at night is worth a lot to a product manager.
And then there are the intangible effects of branding, marketing, and reputation. CPU chips are supposed to be unlovable lumps of silicon and copper designed to accomplish a job – mere hardware engines. But we get attached to our engines, and loyalty runs high among most programmers. Changing CPU architecture is asking a lot, but even changing vendors for the same architecture comes with an intangible cost. Anything that might sap productivity isn’t worth the risk.
Nobody’s done an all-in-one, truly universal processor. But many teams have tackled various parts of the whole, building Java processors in hardware, x86-translating processors, ARM clones, and other knock-off CPUs. They all did the job, more or less. And they all lost millions of dollars for their investors.
Universal processors are like Esperanto: a nice idea for a universal communications standard that nobody actually uses. As with so many other parts of our business, we allow inertia to undermine progress. Rats. Guess I’ll have to abandon that big breadboard project I’ve been working on.
Leave a Reply
You must be logged in to post a comment.