Always a bridesmaid, never a bride. The perennial runner-up in the “name that processor IP” sweepstakes, MIPS Technologies is the perpetual #2 – the company that isn’t ARM.
That’s too bad, because MIPS has contributed a lot to the world of processor IP. The company just never gets quite the respect or recognition that ARM gets. Like AMD to Intel, MIPS is the underdog to ARM’s 500-pound gorilla, keeping the latter honest and keeping competition lively. For most people in the market for processor IP, there’s ARM and then there’s… uh… some other players, I’m sure.
As companies, both ARM and MIPS are about the same age and both have been in the licensing business for about the same amount of time. Of the two, MIPS has the more impressive heritage. Whereas ARM started out with home computers, MIPS was designed for supercomputers. ARM was originally Acorn Computers (and later, Acorn RISC Machines), a cheap home machine that was sort of the British equivalent of an Apple ][ or TRS-80.
MIPS, on the other hand, sprang out of seminal university research at Stanford and UC Berkeley into reduced instruction-set computing (RISC). John Hennessy, one of the inventors of the MIPS architecture and coauthor of the nerd bible, “Computer Architecture: a Quantitative Approach,” is now president of Stanford University – all of it, not just the engineering department. The MIPS research begat Silicon Graphics, a Silicon Valley high flyer beloved by Hollywood animation studios. The licensing business was spun out as MIPS Technologies, complete with splashy IPO in the late ’90s.
Which company would you rather buy your processor from?
MIPS trivia: according to Hennessy, the name MIPS stands for “microprocessor without interlocked pipelines stages,” not millions of instructions per second. Or meaningless indicator of performance for salesman.
Let’s Get Small
So much for the catch-up. What’s the news? Well, the new news is old news, if you see what I mean. You see, MIPS has announced a pair of new processor cores, called the M14K and the M14Kc, which are remarkable mostly for some old technology that’s been redone. Both cores implement code compression, which isn’t new for MIPS but is new for the M14K. Got it?
Code compression is a technique for reducing a microprocessor’s memory usage. Every programmer knows that processors use a lot of memory, and RISC processors are the worst of all. It’s not uncommon for an IC designer to spend more real estate on memory than on the processor and other logic. If only there was some way to reduce the processor’s memory requirements…
Enter code compression. The idea has been around for years, and many companies – including ARM and MIPS – have implemented it in their processors before. But how can you arbitrarily reduce the size of code storage? It’s not as though you could remove half the bits or something.
Actually, you can. MIPS and other 32-bit RISC processors normally have fixed-length 32-bit instructions. In fact, that’s one of the defining characteristics of a RISC processor. And while that elegant and orthogonal architecture makes processor design (and compiler design) clean and easy, it also wastes a lot of space. A lot of instruction words are padded with unneeded bits merely for regularity’s sake. Not all instructions really need to be 32 bits long; they just are because… well, because that’s what RISC rules say you should do. It is the way of things.
If we’re willing to eschew tradition and give up on academic ideas of technical elegance, what we discover is that instructions want to be different lengths. Some need to encapsulate long address pointers; others just need a few bits to say, “return from interrupt” or “clear carry flag.”
At the high-volume (read: low-cost) end of the market, technical elegance takes a back seat to practical cost concerns, and most IC designers in that camp couldn’t care less about upholding RISC doctrine. That makes code compression a big deal.
Enter MicroMIPS
About a hundred years ago, MIPS came up with MIPS-16, a wee little miniature instruction set for its mighty MIPS processors. With a software switch, you could swap between two different modes. One mode ran “normal” 32-bit MIPS code and the other turned on the MIPS-16 instruction set. It was like getting two processors in one. Code written and compiled for the MIPS-16 mode used less memory because, hey, it was a 16-bit instruction set. The downsides were that you were restricted to a limited number of functions and operations, and you couldn’t mix 16-bit and 32-bit code. An explicit jump was required to hop from one mode to the other and back again. Not ideal, but not a bad tradeoff.
Except that customers didn’t like it. It was a hassle to swap code modes, and so much high-level code had to remain in standard 32-bit software that the overall space saving wasn’t great. Spiffy technology; iffy economics.
For the record, ARM had a nearly identical code-compression scheme called Thumb (groan), and it had all the same limitations.
ARM amputated Thumb and redesigned it a few years ago, calling it Thumb-2. Now all ARM processors come with the Thumb-2 code-compression technology whether you like it or not. (You’re not required to use it, just license it.) And as of today, MIPS has followed suit. The company has overhauled MIPS-16 and called its successor microMIPS. And it works much better than before.
MIPS claims that microMIPS code is about one-third smaller than standard MIPS code. In other words, if you take the same C source code and compile it two different ways, the microMIPS version will use about 35% less memory. Not a bad trick. If you’ve got megabytes of MIPS code on your chip or in your system, that’ll be a nice dividend.
Performance suffers almost not at all; the company claims 98% performance parity between microMIPS and normal MIPS. So the space savings comes at almost no cost.
UnlikeMIPS-16, there’s no need to switch between 16-bit and 32-bit code; microMIPS is a complete standalone instruction set. You can boot the processor in 16-bit microMIPS mode and leave it there forever. About the only time you’d need to switch to “normal” mode is if you’re calling existing 32-bit binaries that you can’t (or don’t want to) recompile.
As their names might suggest, the M14K cores are variations on the existing low-end M4K core designs. They have the same five-stage pipeline and are limited to fairly pedestrian 300-MHz clock rates. The ’Kc version comes with a cache. That makes these cores competitors to ARM’s low-end Cortex-M3 processor. Both are aimed at 16-bit microcontroller users looking to upgrade.
RISC Was a Bad Idea
I should point out here that microMIPS isn’t technically a 16-bit instruction set. Some instructions are 16 bits long, but there are 32-bit and 48-bit instructions as well. In fact, if I didn’t know better, I’d be tempted to call microMIPS a variable-length CISC instruction set. Horrors! Oh, the awfulness!
Can it be that RISC was actually a bad idea? That all the vaunted advantages of regular, orthogonal, fixed-length instructions, big caches, and clever compilers were all just a big waste of time? You won’t get any of the microprocessor companies to admit it, but yeah, RISC was a dumb idea. It sounded sexy in the 1990s, but, little by little, we’ve come crawling back to the old-fashioned ideas that processors should be useful, practical, and economic. RISC may win design awards but clunky, kludgy old CISC wins the hearts of designers and programmers. And that’s what matters.
