feature article
Subscribe Now

Mighty MIPS Goes Micro

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.

Leave a Reply

featured blogs
May 17, 2022
'Virtuoso Meets Maxwell' is a blog series aimed at exploring the capabilities and potential of Virtuoso® RF Solution and Virtuoso MultiTech. So, how does Virtuoso meet Maxwell? Now,... ...
May 17, 2022
Explore Arm's SystemReady program, and learn how we're simplifying hardware/software compliance through pre-silicon testing for Base System Architecture (BSA). The post Collaborating to Ensure that Software Just Works Across Arm-Based Hardware appeared first on From Silicon ...
May 12, 2022
By Shelly Stalnaker Every year, the editors of Elektronik in Germany compile a list of the most interesting and innovative… ...
Apr 29, 2022
What do you do if someone starts waving furiously at you, seemingly delighted to see you, but you fear they are being overenthusiastic?...

featured video

Building safer robots with computer vision & AI

Sponsored by Texas Instruments

Watch TI's demo to see how Jacinto™ 7 processors fuse deep learning and traditional computer vision to enable safer autonomous mobile robots.

Watch demo

featured paper

5 common Hall-effect sensor myths

Sponsored by Texas Instruments

Hall-effect sensors can be used in a variety of automotive and industrial systems. Higher system performance requirements created the need for improved accuracy and more integration – extending the use of Hall-effect sensors. Read this article to learn about common Hall-effect sensor misconceptions and see how these sensors can be used in real-world applications.

Click to read more

featured chalk talk

56 Gbps PAM4 Performance in FPGA Applications

Sponsored by Mouser Electronics and Samtec

If you are working on an FPGA design, the choice of a connector solution can be a crucial element in your system design. Your FPGA connector solution needs to support the highest of speeds, small form factors, and emerging architectures. In this episode of Chalk Talk, Amelia Dalton joins Matthew Burns to chat about you can get 56 Gbps PAM4 performance in your next FPGA application. We take a closer look at Samtec’s AcceleRate® HD High-Density Arrays, the details of Samtec’s Flyover Technology, and why Samtec’s complete portfolio of high-performance interconnects are a perfect fit for 56 Gbps PAM4 FPGA Applications.

Click here for more information about Samtec AcceleRate® Slim Body Direct Attach Cable Assembly