AFAIK MIPS still hasn't shipped a high-end processor competitive with the XuanTie 910 that article is about. And I think the billions of RISC-V microcontroller cores that have shipped already (10 billion as of 02022 according to https://wccftech.com/x86-arm-rival-risc-v-architecture-ships...) are also mostly not from MIPS.

Lots of companies had their own mips implementation, but still might use an implementation from mips-the-company because even if you have your own team, you probably don't want to implement every core size that you might need. But then for some reason lots of them switched to using ARM, within a few years (in some cases getting an architecture licence and keeping their CPU team).

It seems like RV has a more stable structure, as the foundation doesn't licence cores, so even if one or two of the implementors die it won't necessarily reflect on the viability of the ecosystem

Keep in mind that your iphone only has very few chips in <10nm technology. The rest is using much larger groundrules, even the memory.

Glo-flo is leading edge for anyone without EUV.

Stanford MIPS was extremely influential, which was undoubtedly a major factor in many RISC architectures copying the delay-slot feature, including SPARC, the PA-RISC, and the i860. But the delay slot really only simplifies a particular narrow range of microarchitectures, those with almost exactly the same pipeline structure as the original. If you want to lengthen the pipeline, either you have to add the interlocks back in, or you have to add extra delay slots, breaking binary compatibility. So delay slots fell out of favor fairly quickly in the 80s. Maybe they were never a good tradeoff.

One of the main things pushing people to RISC in the 80s was virtual memory, specifically, the necessity of being able to restart a faulted instruction after a page fault. (See Mashey's masterful explanation of why this doomed the VAX in https://yarchive.net/comp/vax.html.) RISC architectures generally didn't have multiple memory accesses or multiple writes per instruction (ARM being a notable exception), so all the information you needed to restart the failed instruction successfully was in the saved program counter.

But delay slots pose a problem here! Suppose the faulting instruction is the delay-slot instruction following a branch. The next instruction to execute after resuming that one could either be the instruction that was branched to, or the instruction at the address after the delay-slot instruction, depending on whether the branch was taken or not. That means you need to either take the fault before the branch, or the fault handler needs to save at least the branch-taken bit. I've never programmed a page-fault handler for MIPS, the SPARC, PA-RISC, or the i860, so I don't know how they handle this, but it seems like it implies extra implementation complexity of precisely the kind Hennessy was trying to weasel out of.

The WP page also mentions that MIPS had load delay slots, where the datum you loaded wasn't available in the very next instruction. I'm reminded that the Tera MTA actually had a variable number of load delay slots, specified in a field in the load instruction, to allow the compiler to allow as many instructions as it could for the memory reference to come back from RAM over the packet-switching network. (The CPU would then stall your thread if the load took longer than the allotted number of instructions, but the idea was that a compiler that prefetched enough stuff into your thread's huge register set could make such stalls very rare.)