In 1991, Microsoft, Compaq, DEC and other vendors joined forces to develop a standard that would succeed the IBM PC compatible platform. MIPS was selected as the high-end CPU.
The ACE companies were a major part of the Windows PC market, almost an “everyone but IBM” crowd. MIPS was the original development architecture for Windows NT, so presumably it had fans in high places at Microsoft.
MIPS had a lot of shots at the goal over the decades (workstation, consoles, embedded) but somehow missed them all.
The big players in the Wi-Fi SOC market are all using ARM in recent designs, Intel and its multi-core Atom being an exception. RISC-V isn't supplanting these at the moment. The chipsets in this market are highly specialized: most of the network functionality is offloaded to proprietary hardware peripherals, and the CPU is mostly only doing control plane and bookkeeping. Given the low margins of these products, some designers may eventually drop ARM for RISC-V, but there is a lot of inertia: designers are far more concerned with keeping up with fast-changing wireless standards and delivering new features. The marginal cost saved replacing these small, slow, low-cost, low-power cores isn't a big priority, especially given any risk of delaying new products.
I suspect there is plateau coming in the foreseeable future, as all the most desirable spectrum is fully utilized by maturing chipset designs. Should that happen, cost reduction will become a higher priority.
> There was some design oddness that plagued early MIPS and SPARC that future architectures avoided.
I wrote a Ghidra extension that can export relocatable object files. The MIPS analyzer for it is the hardest algorithmic challenge I've ever tackled, by far. The quirks of that architecture offer an endless supply of frustrating edge cases.
It uses split HI16/LO16 relocations because the earliest versions couldn't use literal pools due to a lack of PC-relative loads/stores, so figuring out pointers within the instruction stream require elaborate register dependency and code block graph traversal. Branch delay slots further scramble that instruction stream because compilers will attempt to stuff them with useful instructions. The System V ABI reference documentation for MIPS is woefully outdated and incomplete, with various extensions left undocumented.
The x86 analyzer in comparison is very straightforward. I haven't tried to add support for another RISC instruction set, but I struggle to think of one that would be even harder to deal with than MIPS (except SPARC, maybe).
It does delay slots by turning the PC into a two element queue so the behavior of JMP x/JMP y is well defined if mostly useless.
It also makes relatively heavy use of hi/lo splits for address constants with something like 21/11 bit splits being typical.
Also has a mechanism where most ALU instructions can conditionally trigger a skip of the next instruction based on the computed value.
And as more of a local concern that just adds friction to everything touching an instruction -- constants are sliced and shuffled into smaller bitfields within the instruction in a seemingly arbitrary way (only thing that makes sense is that the sign bit of signed constants is always in the same place in the instruction).
1) to keep rs1, rs2, and rd fields in the same places in every instruction that has them. I can't think of any other ISA that does this consistently. The place it show up the most is in load and store instructions. In most ISAs the "same" format is used for both, except that the register field that is used for the data to be stored in a store is used for the place to put the loaded data in a load. RISC-V uses the normal rs1 and rs2 fields for store address and data, and rs1 and rd for load address and place to put the result.
2) to give a different range of constants for conditional branch and jump offsets, where odd offsets are not possible, so what is bit 0 in arithmetic instruction constants is instead used as a hi bit -- but not the sign bit but the next one, so that sign extension is always (as mentioned for PA-RISC) always from the same bit.
These two things do genuinely make small microcontroller class RISC-V CPUs smaller and faster than they would otherwise be.
The cost is it takes half a dozen lines of code in assemblers and disassemblers and JIT and emulators to encode or decode constants. Code that can be written once and put in a function and put in a library, so it's a (very small) one-time cost for programmers. No big deal. It also of course requires a few more instructions each time its run, but it doesn't have any significant effect even on interpretive emulators, let alone transpiling ones.
there is still mips mcus in some products here and there. some router manufacturers have already started using riscv and arm (ofc). i tend to find old mipsel marvell mcus in settops and older cable modems, and really small things.
microchip still has mips based pic32mz as well. i still use this in some automotive design
The first *nix workstation I ever sat in front of (at an undergrad CS lab in the early 90s) was a DECStation 2100 with a MIPS R2000.. Sadly they were replaced by Sparcs when Sun made an exclusive deal with our University.
Rochester Institute of Technology had MIPS in their CSCI-250 Concepts of Computer Systems class. I remember debugging my final project for the semester being a bit of a nightmare because it was a much larger MIPS assembly project, and debugging it used gdb if I remember correctly..
Not sure if they still use it as I graduated from there back in 2020
… without interlocked pipeline stages was an early weird RISC bet not unlike register windows, branch delay slots or tagged integers. They abandoned it in R4000.
No, they got rid of the load delay slot in MIPS II. While not required in later ABIs, they kept the branch delay slot for backwards compatibility. MIPS32/MIPS64, which came out much later, also had several new branch instructions without delay slots.
One (probably the only) nifty thing the branch delay slot allowed was in the user-space threads implementation, you didn't have to burn a register for the jump to another thread, you'd do the branch and then clobber the register with the last bit of the jumped-to thread's context. Kinda fiendishly clever.
I only meant that MIPS got rid of the "without interlocking pipeline stages" in the R4000, not the other stuff. I was just saying that was a weird architectural feature not unlike BDSs and register windows. BTW, tagged integers are still in SPARC but just for 32b.
I'll have to look up the nifty trick. I have a soft spot for delay slots.
This article completely misses the early heyday of MIPS, the ACE consortium:
https://en.wikipedia.org/wiki/Advanced_Computing_Environment
In 1991, Microsoft, Compaq, DEC and other vendors joined forces to develop a standard that would succeed the IBM PC compatible platform. MIPS was selected as the high-end CPU.
The ACE companies were a major part of the Windows PC market, almost an “everyone but IBM” crowd. MIPS was the original development architecture for Windows NT, so presumably it had fans in high places at Microsoft.
MIPS had a lot of shots at the goal over the decades (workstation, consoles, embedded) but somehow missed them all.
> MIPS was the original development architecture for Windows NT,
Nitpick: I'm pretty sure the original ISA was the Intel i860.
I remember seeing a lot of wifi routers using MIPS architecture..
Did they all move onto using Arm these days or is RISC-V gaining traction there too these days?
The big players in the Wi-Fi SOC market are all using ARM in recent designs, Intel and its multi-core Atom being an exception. RISC-V isn't supplanting these at the moment. The chipsets in this market are highly specialized: most of the network functionality is offloaded to proprietary hardware peripherals, and the CPU is mostly only doing control plane and bookkeeping. Given the low margins of these products, some designers may eventually drop ARM for RISC-V, but there is a lot of inertia: designers are far more concerned with keeping up with fast-changing wireless standards and delivering new features. The marginal cost saved replacing these small, slow, low-cost, low-power cores isn't a big priority, especially given any risk of delaying new products.
I suspect there is plateau coming in the foreseeable future, as all the most desirable spectrum is fully utilized by maturing chipset designs. Should that happen, cost reduction will become a higher priority.
Global Foundries just bought MIPS, so perhaps there is life in the old architecture yet.
https://gf.com/gf-press-release/globalfoundries-to-acquire-m...
Edit: the article starts with the above press release.
It spends substantial time on the Nintendo 64, but not much on the "Emotion Engine" of the Sony PS2 (which was a more advanced MIPS CPU).
https://en.wikipedia.org/wiki/Emotion_Engine
There was some design oddness that plagued early MIPS and SPARC that future architectures avoided.
https://www.jwhitham.org/2016/02/risc-instruction-sets-i-hav...
One place where everyone saw the work of MIPS was the original movie Jurassic Park, on an SGI Crimson.
https://en.wikipedia.org/wiki/SGI_Crimson
> There was some design oddness that plagued early MIPS and SPARC that future architectures avoided.
I wrote a Ghidra extension that can export relocatable object files. The MIPS analyzer for it is the hardest algorithmic challenge I've ever tackled, by far. The quirks of that architecture offer an endless supply of frustrating edge cases.
It uses split HI16/LO16 relocations because the earliest versions couldn't use literal pools due to a lack of PC-relative loads/stores, so figuring out pointers within the instruction stream require elaborate register dependency and code block graph traversal. Branch delay slots further scramble that instruction stream because compilers will attempt to stuff them with useful instructions. The System V ABI reference documentation for MIPS is woefully outdated and incomplete, with various extensions left undocumented.
The x86 analyzer in comparison is very straightforward. I haven't tried to add support for another RISC instruction set, but I struggle to think of one that would be even harder to deal with than MIPS (except SPARC, maybe).
Ever look at PA-RISC?
It does delay slots by turning the PC into a two element queue so the behavior of JMP x/JMP y is well defined if mostly useless.
It also makes relatively heavy use of hi/lo splits for address constants with something like 21/11 bit splits being typical.
Also has a mechanism where most ALU instructions can conditionally trigger a skip of the next instruction based on the computed value.
And as more of a local concern that just adds friction to everything touching an instruction -- constants are sliced and shuffled into smaller bitfields within the instruction in a seemingly arbitrary way (only thing that makes sense is that the sign bit of signed constants is always in the same place in the instruction).
> constants are sliced and shuffled
I can see you haven't looked at RISC-V :-)
There are two reasons RISC-V shuffles constants:
1) to keep rs1, rs2, and rd fields in the same places in every instruction that has them. I can't think of any other ISA that does this consistently. The place it show up the most is in load and store instructions. In most ISAs the "same" format is used for both, except that the register field that is used for the data to be stored in a store is used for the place to put the loaded data in a load. RISC-V uses the normal rs1 and rs2 fields for store address and data, and rs1 and rd for load address and place to put the result.
2) to give a different range of constants for conditional branch and jump offsets, where odd offsets are not possible, so what is bit 0 in arithmetic instruction constants is instead used as a hi bit -- but not the sign bit but the next one, so that sign extension is always (as mentioned for PA-RISC) always from the same bit.
These two things do genuinely make small microcontroller class RISC-V CPUs smaller and faster than they would otherwise be.
The cost is it takes half a dozen lines of code in assemblers and disassemblers and JIT and emulators to encode or decode constants. Code that can be written once and put in a function and put in a library, so it's a (very small) one-time cost for programmers. No big deal. It also of course requires a few more instructions each time its run, but it doesn't have any significant effect even on interpretive emulators, let alone transpiling ones.
The original article points out that MIPS (the company) no longer designs chips using MIPS (the architecture).
I think the last MIPS design was Longsoon.
It appears to have been the Godson 3, perhaps the 4000 series.
https://en.wikipedia.org/wiki/Loongson#Godson_3_/_Loongson_3...
there is still mips mcus in some products here and there. some router manufacturers have already started using riscv and arm (ofc). i tend to find old mipsel marvell mcus in settops and older cable modems, and really small things.
microchip still has mips based pic32mz as well. i still use this in some automotive design
The first *nix workstation I ever sat in front of (at an undergrad CS lab in the early 90s) was a DECStation 2100 with a MIPS R2000.. Sadly they were replaced by Sparcs when Sun made an exclusive deal with our University.
Sadly, these machines are very difficult to find around here (and DEC had a factory in Ireland!)
UC Berkeley's intro to computer architecture course still uses MIPS for projects and exam questions.
Who else used (uses?) SPIM for this?
https://pages.cs.wisc.edu/~larus/spim.html ... and apparently its being kept up to date https://spimsimulator.sourceforge.net with new builds about every other year.
(I took the class from Professor Miller in... '92... Operating systems in... '94? 95? was from Professor Larus)
A first year course at UNSW, COMP1521[1] teaches MIPS and uses QtSPIM. Far from dead, a package is maintained on the AUR[2].
[1] https://cgi.cse.unsw.edu.au/~cs1521
[2] https://aur.archlinux.org/packages/qtspim
My university in Portugal did (UNL/FCT), similar timeframe.
CS61C uses RISC-V now.
Oh, cool! I remember hearing a lot about RISC-V back then, and it's also from Berkeley, so makes sense.
Makes sense. Isn't MIPS like a commercial variant of RISC-I?
IIRC, Berkeley RISC was mainly SPARC, although it was also the AMD 29k.
Stanford was MIPS.
Rochester Institute of Technology had MIPS in their CSCI-250 Concepts of Computer Systems class. I remember debugging my final project for the semester being a bit of a nightmare because it was a much larger MIPS assembly project, and debugging it used gdb if I remember correctly..
Not sure if they still use it as I graduated from there back in 2020
This was true of University of Maryland back in 2015 when I was there…
MIPS is also used in Ubiquiti's Edgerouter product line.
… without interlocked pipeline stages was an early weird RISC bet not unlike register windows, branch delay slots or tagged integers. They abandoned it in R4000.
No, they got rid of the load delay slot in MIPS II. While not required in later ABIs, they kept the branch delay slot for backwards compatibility. MIPS32/MIPS64, which came out much later, also had several new branch instructions without delay slots.
One (probably the only) nifty thing the branch delay slot allowed was in the user-space threads implementation, you didn't have to burn a register for the jump to another thread, you'd do the branch and then clobber the register with the last bit of the jumped-to thread's context. Kinda fiendishly clever.
I only meant that MIPS got rid of the "without interlocking pipeline stages" in the R4000, not the other stuff. I was just saying that was a weird architectural feature not unlike BDSs and register windows. BTW, tagged integers are still in SPARC but just for 32b.
I'll have to look up the nifty trick. I have a soft spot for delay slots.