5 ms·

We need diversity for solving different problems, not for diversity sake. What problem did MIPS solve in a unique way that others didn't? Because it wasn't des

• bitwize 6y ago
  MIPS was a nice simple ISA for CE students to learn and implement. Both ARM and RISC-V have gotchas that make them more complicated. I suppose it will live on in that form, especially if the IP is opened up.
  • schoen 6y ago
    I remember CS 61C at Berkeley used to use MIPS to teach assembly language programming and a bit about computer architecture, using the original MIPS version of Patterson and Hennessy's Computer Organization and Design. Now that book is available in both MIPS and RISC-V versions, with, I've assumed, much more effort going into the RISC-V version... I do think the simplicity of MIPS was a big plus there, including simplicity of simulating it (http://spimsimulator.sourceforge.net/ http://spimsimulator.sourceforge.net/). I suppose a lot of students may appreciate being taught on something that is or is about to be very widely used, even if it's more complicated in various ways -- and the fact that one of the textbook authors was a main RISC-V designer makes me assume that educational aspects are not at all neglected in the RISC-V world.
    • saagarjha 6y ago
      Not entirely related, but I found MARS (http://courses.missouristate.edu/KenVollmar/MARS/ http://courses.missouristate.edu/KenVollmar/MARS/) to be much nicer to use than SPIM. More on topic, though, RISC-V seems to really be designed in a way that makes it easy to teach. This is partially why I have doubts that it can be made very performant, but the focus of a prettier design over a more practical one is probably going to help it be more accessible to students.
• yjftsjthsd-h 6y ago
  Throwing out diversity because you don't see any immediate benefit is a great way to not have it when a different problem does show up. I don't know about unique way, but MIPS certainly was good at embedded; there's plenty of networking gear using it.
  • capableweb 6y ago
    > MIPS certainly was good at embedded As far as I understand, it's not that MIPS is the best at embedded, it's just that it's cheaper to sell as the license cost is non-existing and good support already exists in kernels and so on.
    • MaxBarraclough 6y ago
      What are the criteria for 'best'? If MIPS offered adequate performance and features, good performance-per-watt, and a competitive licence fee, and if none of its competitors could beat it, doesn't that count as 'best'?
    • yjftsjthsd-h 6y ago
      > it's not that MIPS is the best at embedded, it's just that it's cheaper to sell That sounds a lot like MIPS being the best at embedded. Not high-end, sure, but a lot of embedded is "what is the cheapest processor that can run Linux?"
  • jnwatson 6y ago
    PowerPC was the dominant processor in telecom equipment as far as I was aware. Perhaps the low end went MIPS.
• zdw 6y ago
  SPARC is well known to be different enough (big endian, register windowing of the stack, alignment, etc.) that it exposes a lot of bugs in code that would be missed in a little-endian, x86 derived monoculture. https://marc.info/?l=openbsd-bugs&m=152356589400654&w=2 https://marc.info/?l=openbsd-bugs&m=152356589400654&w=2
  • simias 6y ago
    I always found SPARC's stack handling to be very elegant and I write enough of low level code that these architectural details do from time to time impact me, but isn't it largely irrelevant for the industry at large? After all MIPS's original insight was that machine code was now overwhelmingly written by compilers and not handwritten assembly, so they made an ISA for compilers. I think history proved them absolutely right, actually these days there are often a couple of layers between the code people write and the instructions fed into the CPU. I guess my point is that nowadays I'm sure that many competent devs don't know what little-endian means and probably wouldn't have any idea of what "register windowing of the stack" is, and they're completely unaffected by these minute low level details. Making it a bit easier for OpenBSD to find subtle bugs is certainly nice, but that seems like a rather weak argument for the vast amount of work required to support a distinct ISA in a kernel. Honestly I'm not convinced by the argument for diversity here, as long as the ISA of choice is open source and not patent encumbered or anything like that. Preventing an x86 or ARM monoculture is worth it because you don't want to put all your eggs in Intel or Nvidia's basket, but if anybody is free to do whatever with the ISA I don't really see how that really prevents innovation. It's just a shared framework people can work with. Who knows, maybe somebody will make a fork of RISC-V with register windows!
    • goatinaboat 6y ago
      I'm sure that many competent devs don't know what little-endian means and probably wouldn't have any idea of what "register windowing of the stack" These days "bare metal programming" means writing raw HTML yourself in a text editor, no CSS, no JS.
  • tyingq 6y ago
• hajile 6y ago
  MIPS and Berkeley RISC started an entire revolution. They appear "not unique" only because other ISAs copied them so thoroughly. I think it's safe to say that Alpha, ARM, POWER, PA-RISC, etc wouldn't have been designed as they were without MIPS. Even today, comparing modern MIPS64 and ARM aarch64, I find ARM's new ISA to be perhaps more similar to MIPS than to ARMv7.
  • guerrilla 6y ago
    I think POWER might have originally been an independent rediscovery of RISC actually, while designing some PBX system.
  • sidpatil 6y ago
    > They appear "not unique" only because other ISAs copied them so thoroughly. https://tvtropes.org/pmwiki/pmwiki.php/Main/SeinfeldIsUnfunny https://tvtropes.org/pmwiki/pmwiki.php/Main/SeinfeldIsUnfunn...
• pabs3 6y ago
  ISA diversity can surface bugs in code, that only shows up in ISAs with different approaches. For example code that works on some arches but is slow due to alignment issues will just fail to run on other arches.
• retrac 6y ago
  > What problem did MIPS solve in a unique way that others didn't? The MIPS R2000 was debatably the first commercial RISC chip. It solved whatever problem you needed a really fast CPU for in 1985. The alternatives on the market were the Intel 386 and the Motorola 68000. The Intel 386 at 16 MHz did about 2 MIPS (heh - millions of instructions per second) with 32 bit integer math. At 16 MHz, the R2000 did about 10 MIPS. Even accounting for RISC code bloat, that's 3 - 4x faster. Note how there were only two competitors selling 32-bit designs in the market they entered. I think that's probably the biggest impact of MIPS. They actually sold the chip! They wanted companies to design their own computer systems around it. Use it in an embedded device. Whatever. That was not the norm c. 1985 - 1988 for high-end silicon. There were machines faster than the 386 or 68020 at that time. You could buy one of the fast microprocessor-based VAXes recently introduced. Or if not too squeezed for office space and with a blank cheque, one of the super-minis like a real VAX or IBM's new "mini-mainframe". After '86, maybe you'd buy one of the other RISC options, like SPARC or PA-RISC. Whatever you bought, it would be the whole system. Take it or leave it. DEC would not sell you something like a CVAX processor all by itself just so you can build it into a product that will compete against them. (Well, they would sell you one, just not at a price you could afford if you aren't a defence contractor.) Both DEC and SGI would use MIPS processors in their workstations of the late 80s, as did some less well-known names. The embarrassment of having to use a competitor's processor to sell a decently fast and affordable UNIX workstation would inspire DEC to create the Alpha. In this vein of "we'll sell it to whoever wants to buy it!" MIPS was also doing ARM-style core IP licensing, before ARM did. That's probably part of why MIPS was so prominent as an embedded architecture in the late 90s and early 2000s, in everything from handhelds to routers to satellites.