Nice bit of nostalgia considering assembly courses at Northeastern University were MIPS/SPIM when I took them back in... 1992-ish? Was an easy-A class because I had been programming in 6502 and then 68k assembly for years before, but SPIM gave me great respect for the power of virtualizing a system you are developing for.
And MIPS is still a great instruction set to learn the basics on.
MIPS still has a small but strong foothold in the embedded world; for example, the Cavium Octeon network processor family is based on MIPS64. That's why I found myself writing MIPS assembly code most recently.
I remember when large-scale multi-core MIPS was the impending next generation of network processing technology; at the time, architectures specialized to packet processing seemed promising, but they seem less so now. What's the current state of play with X64 vs. custom MIPS?
Cavium was not yet sharing eval parts when I left this field, just a bit before Intel cancelled their NXP line (which was fun to play with).
Intel is closing the gap with their DPDK, but Cavium creams them on clock-by-clock and on cost of goods.
Cavium Octeon chips currently scale to 32 cores at 1.4Ghz, but with ZIP, GZIP, AES, SHA1, etc coprocessors running at 800Mhz. All cores share a fast, coherent unified L2.
One of the key advantages of the Octeon architecture is their hardware work scheduling unit. This is essentially a highly programmable hash engine on packet fields (with software-only bits for software classify-then-reschedule). The idea is to ensure that no packets with identical hashes are in flight on any core at the same time.
If programmed correctly, this work scheduling prevents data structure contention, which is particularly problematic when you scale to 32 (and next-gen up to 48 [then I believe to 64] cores).
The chips also support direct packet transport (XAUI, SGMII, etc), rather than requiring transport across PCI-e. Each of these ports can be programmed separately, so you can use switch-specific goofy encapsulation modes (Broadcom HiGig2, Marvell DSA, etc) to support very quick traffic <-> physical port mappings.
I should also mention that Cavium scales down very well, all of the way to configurations like 2 cores at 400Mhz for PoS, SOHO usage, and such. So it can be an attractive architecture to target.
Finally, Octeon family MIPS64 has a lot of MIPS64 extensions, like branch on bit, posted atomic operations (e.g. statistics, where you don't care about the value, you just want to += 42 it), pop count, fast bitfield subfield extract, etc.
One of the big easy advantages of NPs was direct to L2 cache I/O (instead of PCI to northbridge to DRAM to cache miss to cache). Intel now has this. NPs do still have hardware schedulers and other features, but Intel has much stronger CPUs.
Anyway, I hope Cavium succeeds with their Thunder. Perhaps there is a large enough "anything but Intel" market for them in the microserver world.
Cisco, Juniper, et al have built/are building a lot of networking gear around Cavium and Broadcom multicore MIPS parts. Intel is muscling back in to the arena, though.
The IXP was an interesting family, but I recall the toolchain being less than pleasant - although at that time the MIPS vendors weren't covering themselves in glory either.
Not so small either - as of 2011 they were the 3rd largest architecture by units shipped, with 656 million units sold, after ARM and ARC (Synopsis), and easily outdistancing x86... Latest numbers I've seen still estimates 300 million+ units last year.
They're "just" mainly in niche fixed-function products, so few people tends to get to program them.
I agree. I've been stopping and starting learning assembly for several years with x86. It didn't really gel but with the book above, the quizzes and exercises its really started to gel, even basic concepts such as nibbles, words, twos complement, etc. What's more I can actually make a lot more sense of low-level code for IA now, such as the simple kernel post recent, and boot loader in ASM.
For the more complex exercises, I've found writing a working program in C first to be beneficial. At first I used Emacs Lisp because its nice to write in Emacs, which I'm using along with the Assembly major mode. C has less of a cognitive shift during translation since its much closer to what you're working with.
In a stoic sort of way, I have a new appreciation for C and an even greater appreciation for lisp. This, however, has not interfered with my enjoyment of learning MIPS, which I'm deriding much of from this book.
I bought that once on a whim, when I worked a few blocks away from Powell's Technical Books, back when that was its own entity. Never really had the chance to do anything with it though.
A lot of routers still use MIPS, and a fair amount of special purpose embedded systems. I still have a few now somewhat aging MIPS SoC development boards from chumby, though we never put out a MIPS-based product.
Not a lot of general purpose use anymore since the golden age of the SGI/N64/PS2/PSP.
I have this vague recollection that for a while, MIPS was sort of in the running against ARM for more things, but has now been pretty much completely squeezed out of certain markets, like phones.
It wasn't really ever in the running for phones/tablets; there were some cheap no-name Chinese devices using MIPS early on but now they all use Rockchip or Mediatek SoCs. Imagination did buy MIPS with the stated goal of pushing into this market, but it's truly too late.
Really, the only growth left for MIPS is through China's government's technology independence initiative in developing the Loongson/Godson CPUs, for which they licensed MIPS. A Loongson powers the laptop that RMS uses.
Apart from all the other stuff listed: Set-top boxes. The WDTV Live for example, uses a specialized tri-core Sigma Design MIPS CPU, where one of the selling points is that one of the cores can be locked down by the board manufacturer with the intent of e.g. running DRM stuff.
If you're interested in assembly but don't want to learn it with tools that seem old (qtspim), yasp gives you a nice web ui to step through your assembly code.
Probably because it's not as popular. Given enough popularity, anything will start deviating from its originally clean and pure design and turn into a monstrosity...
I did a basic tutorial for my class when I took computer architecture. I think I got most of the basic stuff right. Probably some mistakes and lack of insight how stack works at the time I was writing the tutorial. Correction is welcome.
We learned MIPS and wrote a compiler for it. This was in 2002, so the compiler was in Java. Still a lot of fun. What were those two tools? LEX and YACC? Nostalgia.
(Had to look those two up, I remembered them as LACC and YEX)
That's because it's a better ISA than ARM or x86 (both of which carry loads of legacy crud) and the early MIPS-related patents have also expired. In addition, there are loads of MIPS textbooks out there.
There are still lots of markets that use MIPS. In addition, China seems interested in a national ISA and seems quite invested in MIPS. I wouldn't write it off just yet.
I would say that MIPS is the only ISA that has definitively proven itself in everything from tiny microcontrollers to multi-core, SMT (hyperthreaded) monsters that run most of the world's networks or the upcoming Chinese petaflop supercomputers.
In the CS department, they do teach a limited subset of MIPS with a Java simulator. But the Engineering labs switched from m68k to ARM about two years ago despite the latter having a much more complex instruction set because of a large hardware donation. :(
Not really. If you believe that RISC is a good way to learn X86 by breaking you in on assembly language in a strict load-store, simple addressing-mode context, then ARM is a more reasonable first ISA to learn.
Many thousands of teenagers picked up X86 (and X86 protected mode!) from nothing more than the MASM Bible during the 1990s, so rather than overcomplicate things, I might just say "don't let yourself get intimidated" and dive right into X86.
And MIPS is still a great instruction set to learn the basics on.