If a microprocessor is nothing but a machine that executes software, then it’s probably important to make sure that all of the machines are compatible with all of the software. That’s a lot harder than it sounds.
Some CPU families have a long and storied history of binary compatibility. Intel’s x86 architecture comes to mind, because of its slavish devotion to binary compatibility dating back to the 1970s. Love it or hate it, at least you know that every x86 processor ever made will run any x86 program ever written. It’s a huge burden to bear, lugging all of that ‘70s-era baggage around, but it’s also one of the architecture’s greatest strengths.
At the other extreme, you have DIY processor architectures that can be customized like LEGO blocks. ARC, Tensilica, and others let advanced users add, remove, or define their own instructions. Without too much trouble, you can create a CPU instruction set that’s unique to your application. It won’t run a lick of third-party code, but not everybody cares about that. Indeed, some developers deliberately define oddball instruction sets so they can thwart a competitor’s code disassembly and reverse engineering.
Most processors lie somewhere in the middle: more or less compatible with their forebears, but not obsessively so. Freescale tweaked its venerable 68K family to produce ColdFire. ARM replaced Thumb with Thumb2, sacrificing compatibility in the process. MIPS, Power, and other architectures have all “streamlined” their ISA at some point, usually to jettison unused instructions that were slowing down the pipeline, or to make room for new instructions that handle media- or signal-processing. Sometimes both.
The unwritten assumption in all this is that the software community follows along. If the CPU vendor wakes up one morning and decides to perform surgery on its own opcode map, it’s a good bet that the company has cleared this in advance with most of the compiler writers, operating system vendors, and third-party codesmiths. Otherwise – surprise! –you’ve got a compatibility nightmare on your hands.
This gets especially tricky when the CPU instruction set is, shall we say, not tightly controlled. In x86 land, the ISA is controlled by Intel (and, in a few cases, AMD). In ARM’s world, the boffins in Cambridge write the ISA bible. IBM more or less controls everything about the Power instruction set, although there were some vendor-specific variations a few years ago that complicated things. And MIPS? Well, MIPS has taken a hands-off attitude toward ISA fragmentation.
Back in the days when MIPS and ARM were competing neck-and-neck for design wins, MIPS differentiated itself by (among other things) allowing its licensees to create their own hardware accelerators and define their own software instructions. The idea was to allow clever people do clever things, even if they didn’t work at MIPS. ARM, on the other hand (ahem), maintained iron-fisted control over the ISA, so that every ARM chip had exactly the same repertoire as every other. The net result was that all ARM chips run all ARM code, but not all MIPS chips can make the same claim.
Where does this leave us? With a weakened MIPS ecosystem that doesn’t have quite the impact that it could. The minor MIPS fragmentation makes third-party code a dicey prospect. And since MIPS, like ARM, is licensed as IP that’s rolled into a larger SoC device, the inevitable hardware incompatibilities don’t make things any easier.
Enter the Prpl Foundation. This oddly named group of MIPS aficionados works to unify and rationalize the MIPS software ecosystem. They want to make sure that MIPS-based code and development tools don’t fork off in strange directions. They’re not interested in defining the MIPS architecture itself – that’s Imagination Technologies’ job – only in guiding its ecosystem.
Chief among Prpl’s projects are QEMU and PrplWrt. (Prpl Foundation evidently has nothing against vowels. Just fully spelled-out words.) For those not familiar, OpenWrt is a stripped-down version of Linux intended for small-scale networking devices. The idea is to squeeze it into a small memory footprint by leaving off any Linux features not absolutely necessary for a modem or small router. (Why the name OpenWrt? Because the first version ran on the ubiquitous black-and-blue LinkSys WRT54G wireless router.) PrplWrt is obviously a Prpl-flavored OpenWrt.
QEMU is a processor-to-processor emulator. That is, it allows you to run code compiled for one CPU on a different CPU. Like running ARM code on a MIPS processor, for instance. QEMU is open-source code that has proven very popular with developers who want to port their old code to a new chip family, and it’s particularly useful for less-popular architectures that don’t have as much third-party code lying around. If x86 code is plentiful, say, but MIPS-based equivalents are hard to find, QEMU can get you up and running pretty quickly.
Prpl Foundation has no full-time employees. Like a lot of industry consortia, it’s staffed by volunteers from interested corporations. In Prpl’s case, the headcount comes from Broadcom, Qualcomm, Cavium, and other MIPS-related businesses. They all cooperate for their mutual benefit, guiding the development ecosystem and interface standards where they want them to go.
Prpl operates a lot like the Open Power Foundation, which we covered in July. Neither group concerns itself with chip design or CPU architecture, just with everything that happens downstream from that. Both aim to avoid fragmentation. Both labor to help their chosen CPU family.
Interestingly, Prpl Foundation describes itself as CPU-independent, which would seem to be completely at odds with the group’s stated goal. How can a group of MIPS boosters not be, well, MIPS boosters? Amit Rohatgi, the foundation’s president, explains that the group works to define standards and interfaces that could be applicable to any CPU architecture, not just MIPS. If other groups adopt the same standards, so much the better. A natural side effect of avoiding fragmentation is… avoiding fragmentation. There’s no reason their community can’t encompass immigrants, too.
Oh, and as for the name? Purple is the color of Imagination Technologies’ logo. And spelling it funny makes it unique and Internet-searchable. You see? These guys have the business savvy to go with their technical smarts.
