MIPS was on its way to irrelevance, first as ARM slowly ate its remaining marketshare, then quickly when Imagination Technology went under and sold it off for a pittance to a relatively obscure "AI" company.
RISC-V may have hastened its demise, but the writing was on the wall for a long time.
It does seem that RISC-V corrects a number of these design eccentricities. SPARC did not move the market an inch with an open release - perhaps MIPS will fail just as spectacularly.
The blog post you link to criticizes MIPS because it has pipeline hazards and branch delay slots. MIPS had hazards in 1985. MIPS II eliminated hazards. No MIPS processor released after 1989 has hazards. Branch delay slots are no big deal once you know they're there. There are a number of equally questionable design decisions in RISC-V, such as variable length instruction encoding and dest, src order of instruction operands. But RISC-V does have momentum.
> Branch delay slots are no big deal once you know they're there.
I disagree. I'm not really a MIPS user, but I've managed to encounter some branch delay slot issues, and, as an x86 system programmer, I can only imagine how unpleasant they must be. Here are some reasons:
- The program counter does not adequately describe the execution state of the CPU. In other words, starting or resuming execution with a given set of register values and a given address will do the wrong thing if you're resuming in a branch delay slot.
- Handling a fault due to an instruction in a branch delay slot seems highly problematic. Suppose you have a load in a delay slot and the load touches swapped-out memory. How is the operating system supposed to page in that memory and resume?
- Linux, and probably other operating systems, will emulate FPU instructions if the CPU doesn't support them. Emulating FPU branch instructions is deeply problematic because of delay slots.
The first two just mean that there's an extra trap state bit in a flags register for "I'm in a bench delay slot currently" and isn't really a big deal.
The third one I imagine is a pain in the ass, but I've been lucky enough to always compile MIPS for the exact CPU I was running it on.
Nah, a delay slot bit is fine. Branches haven't really retired yet (that's the point of a delay slot), so when you reenter the instruction with that bit set the CPU just backs PC up and executes both of them again.
You have to make sure you can map two pages at once in case the branch/delay pair straddles a TLB boundary, but you have to screw up pretty bad to not allow that.
If you try this on hardware that also supports software single stepping (which x86 does, but MIPS seems not to by default), then you have to be extra creative to guarantee forward progress. The same issue arises if you have data breakpoints. And if the branch loads from MMIO space, you have a problem.
I mean, it's MIPS so it's a load/store architecture anyway. Between the pair you're only going to have one memory reference at most, and it's going to be the delay slot.
Variable length instructions are to match Thumb2/SH4 ideas/density. Having written a simple RISC-V emulator, I totatlly agree with you that the operand encoding is non-intuitive, but it's nice for hardware implementations. There's a lot more non-intuitive opportunities for weird sharing in the decode stage that you'd never expect. Particularly that's why the branch offset has such bananas encoding.
such as variable length instruction encoding and dest, src order of instruction operands
One is basically necessary to get decent code density (and thus better cache utilisation and memory bandwidth minimisation, something that x86 was winning at for a long time --- and one of the worst parts of traditional RISC), the other is purely syntactic sugar (see the horrible GAS/AT&T syntax) and an order which I find most sensible (especially considering comparison and subtraction, as well as the direction of the assignment operator in the majority of programming languages that exist.)
There are large numbers of consumer MIPS devices (routers) in existence, which run mature open-source software stacks.
Future iterations of MIPS can be governed by a multi-stakeholder community, avoiding past mistakes and designing for future requirements, including AI/ML and other domain-specific use cases.
MIPS is mature, all the toolchains are here. It's simply that most vendors are too incompetent to care, as it doesn't affect their revenue in any way.
> Security and Hardening by Steven Barth - OpenWrt Summit
> Introducing new and ongoing security improvements to bleeding edge OpenWrt. This talk describes the new default toolchain featuring musl libc, enabled hardening including ASLR, SSP as well as OpenWrt's novel jailing (jailfs and seccomp) and package signing features (based on Curve25519).
Not really. It's still by far the sanest and easiest of all assembly ISA's. And cheap.
SPARC is beyond crazy (esp. with its delays), ARM hopelessly balkanized, Intel more than crazy, RISC-V immature.
POWER is the only other pretty good assembly ISA, but too expensive.
The worst MIPS problem is the softfloat compiler crazyness (executable stack), but that's a gcc/binutils sin from a decade ago.
I'm curious in what way you find ARM balkanized? It's all AArch32 + some variety of soft/hard-float or AArch64 with standardized NEON. In fact, the architecture/ISA is the one thing that is sane about ARM; since Nvidia, Samsung, Qualcomm, Apple, Applied, Cavium, etc all have vastly different use-cases and goals for ARM.
Even with this being true, Wave are clearly open-sourcing MIPS because of the buzz around RISC-V.
In all likelihood, MIPS would have changed hands a few more times then been shelved indefinitely by an ultimate licensor that saw no further value in it.
In any case it's good news - MIPS support in Linux is already fairly decent so having multiple, credible open-source vendors in the space should be good for competition and adoption.
I personally hope this doesn't distract from the hype and progress around RISC-V.
I'm very biased against companies/tech projects that go open source as a last ditch attempt to stay in competition when it's clear that an open source solution is gaining steam/mindshare -- it always seems disingenuous.
I don't know -- the obvious answer is no (more code in full view is better than less), but when I think about it, you have to weigh the benefits against possible damage to RISC-V or more F/OSS aligned competitors.
I have no way of knowing of course, but if MIPS simply went open source but don't actually think the same way RISC-V does, then they might lure enthusiasts that would have worked on RISC-V. That's the point I hoped to make -- if the result is fragmentation and slowed progress on RISC-V because of a muddying of the waters as to who thinks what about F/OSS then that is a bad outcome in my eyes.
> Linley Gwennap, principal analyst at the Linley Group, told EE Times, “MIPS is certainly behind RISC-V in mindshare in the open-source community.” He noted that MIPS was “unable to make this move sooner due to its various ownership transitions.”
RISC-V's integer multiplication extension doesn't do the lo/hi trick MIPS did, and it doesn't specify a latency; that is, the integer multiplication opcode, if your chip has one, returns its value in a normal register, not split into a special lo register for the low bits and hi for the high bits, and it executes in a normal sequence with the others from a software perspective, as opposed to MIPS, where it was specified to execute sychronously with the normal instruction stream, and you'd only stall the pipeline if you tried to read lo or hi too early after the mutiplication opcode had issued, before the actual arithmetic was completed.
> In some processors the integer multiply operation may proceed asynchronously and allow other CPU instructions to
execute before it is complete. An attempt to read LO or HI before the results are written interlocks until the results are ready. Asynchronous execution does not affect the program result, but offers an opportunity for performance improvement by scheduling the multiply so that other instructions can execute in parallel. Programs that require overflow detection must check for it explicitly.
> Where the size of the operands are known, software should place the shorter operand in GPR rt. This may reduce the latency of the instruction on those processors which implement data-dependent instruction latencies.
(MIPS32TM Architecture For Programmers Volume II: The MIPS32TM Instruction Set, mul / mult instrutions)
It's... a bit more low-level than assembly ISAs are typically designed to be these days.
FWIW, if I had to pick the "biggest differences from MIPS" in RISC-V, it wouldn't be the fact that MUL works on GPRs.
More important is the lack of a branch delay slot (i.e. it doesn't bake in a particular pipeline stage design into the ISA), and the existence of hardware paging (MIPS tried to cheat here by letting software handle page faults, and in hindsight made a poor decision).
That is mostly true many of the early RISC share a very common base as most of these people were sitting on top of each other. Sun nearly hired the MIPS guys but they went of and did their own thing so they did SPARC.
However it would be wrong to say it just, removed baggage, it also has and will add a lot of interesting ideas.
They also spend a lot of time fiddling with details, how small you can make the decoder, op code layout for a modular design, how to avoid backing micro-architecture decisions into the ISA.
Delay slots are generally regarded to have been a mistake since they link the ISA to the physical implementation of the processor too closely. That means you end up paying in speed and complexity for architectural choices of past processors in your future processors. RISC-V was designed to be a modern architecture informed by the mistakes of the past.
No the specifically removed it. The RISC-V guys at Berkley said that all their high performance implementations had always major problems with delay slots.
There's a lot of ways around it; there's been several MIPS OoO cores.
It's just a pain and adds complexity to exactly the parts that are hardest to get right as it is. For instance the state unwinding on hardware exceptions and the like.
nanoMIPS doesn't have delay slots IIRC. microMIPSR6 also deprecated delay slots for branches. MIPSR6 got rid of delay slots for a family of branches called 'compact branches' which have 'forbidden slots' which require that back-to-back branches be separated by a nop or other instruction.
I guess the thing that has put me off of RISCV is The emphasis on for peripherals, they’re just doesn’t seem to be a lot. Yeah, there’s a peripheral bus, And I’m sure it works great but…
This is where I could see MIPS going open source to have a serious advantage. There are people out there that already have experience with how MIPS peripherals should work.
That is pretty awesome. So three 'open' RISC architectures (RISC-V, MIPS, SPARC) with varying amounts of ecosystem support.
That the patent stuff seems to be dealt with is key here, one of the challenges with working with MIPS and SPARC was always that their 'parent' organizations (SGI and Sun respectively) were essentially patent trolls when it came to third parties being successful with the architecture. Now that SGI and Sun are just footnotes in the computer industry, perhaps these architectures can flourish.
> challenges with working with MIPS and SPARC was always that their 'parent' organizations (SGI and Sun respectively) were essentially patent trolls when it came to third parties being successful with the architecture.
And that was in part what has killed them.
ARM only got so far thanks to their no questions asked attitude. I heard from people from Chinese fabless companies of ARM DHLing usb sticks to them in the early A8/A9 era, and flying support engineers to them the same day.
Comparing MIPS to them, they had an obviously bad attitude.
First, they barely sold complete solutions, nor worked on their integration (DMA controllers, memory controllers, bus interfaces and PHYs)
Second, they were compete slowpokes. People are telling of them spending weeks to reply to very clear licensing applications, and them nor being able to say a word without going through their lawyers. You were essentially speaking not with sales, or engineers, but their legal department.
Third, patently bad support.
Only when they hit the terminal stage, they seemed to notice that they were doing something wrong
> Only when they hit the terminal stage, they seemed to notice that they were doing something wrong
Sadly this is the motivation for a lot of "correct" decisions. It is the first thing I look for when I read a startup pitch, a misunderstanding of where the value is and what the customer perceived risks are for adoption. Too often I've heard entrepreneurs or senior managers say, "But if we did that, this business model wouldn't work." And I patiently point out to them that if they can't get customer engagement with their current business model, it already doesn't work so they need to change something. Typically it is re-think the business model so they can focus on what is valuable to the customer and what isn't.
ARM Holdings can be disrupted by a business model that can keep software coherence high while not requiring an architecture license to add special sauce. That puts more pressure on the foundation/management entity but it trades value (architecture extension) for adoption. The key is partnering with those who would extend the architecture to keep it aligned with key architectural invariants, and when possible allowing really useful extensions to move into the mainstream.
Maybe the future is not about fixed instruction sets at all [1]. Especially with the rise of high-level hardware synthesis methods, platforms and tools like Kami [2]. Of course, tooling and C compilers for the non-standard ISA are the main obstacles on this way.
[1] "Synthesis of Processor Instruction Sets from High-Level ISA Specifications" IEEE Transactions on Computers 2014, 63(6), 1552-1566
What exactly is the lesson of Itanium is debatable.
> Q: I feel like deja vu - at Hot Chips, Intel introduced VLIW-concept Itanium that pushed complexity onto the compiler. I see traces of that here. What are you doing to avoid the Itanium traps? How will you avoid IP from Intel?
> A: Itanium was in-order VLIW, hope people will build compiler to get perf. We came from opposite direction - we use dynamic scheduling. We are not VLIW, every node defines sub-graphs and dependent instructions. We designed the compiler first. We build hardware around the compiler, Intel approach the opposite.
I don't think that's the way of the future anyway, but C is not the only programming language, fortunately. Generating the ISA, and then CPU from specification, the next logical step is to generate highly optimized lower-than-C-level code from high-level specifications too.
The Itanium folks actually put a lot of effort into tooling and compilers for the architecture, back in the early 2000s - even FLOSS tooling. The problem on that side was that a community never coalesced around Itanium, the way it did around e.g. amd64, or nowadays around riscv.
Indeed, they put lot of effort into it, but the main problem was that they committed to the HW architecture with the expectation that compiler R&D would fix the even by then well-known issue of generating good VLIW code for general-purpose software. Turned out this was a fatal mistake, and compiler tech has yet to advance to the level they expected.
RISC, while older, at least was informed by what real compilers actually liked (lots of GPR's, simple instructions).
patent stuff seems to be deal with....SGI and Sun are just footnotes
Eh... In Sun's case they were acquired by Oracle. I don't think that will have improved the situation.
You'll see lots of bad anecdotes about Oracle here & there. You might wonder "huh, is all that really true?" Well, I've dealt with Oracle. I have yet to see something bad about them that didn't jibe with my own experience: I won't give info that might dox me, but there was a fairly visible lawsuit involved.
> Swift is very familiar with most of the MIPS players in China, “because I worked with them,” he told us.
Well, things change, and if he still thinks about a couple of big vendors, that would fit. But most of the Chinese SoC vendors using RISC-V aren't big nowadays, and most of them probably wouldn't bother with all that corporate memberships and stuff.
In comparing RISC-V vs MIPS, I think people are forgetting that one is a Foundation of member companies driving development, and the other is one company releasing their IP.
There's obvious pluses and minuses to both approaches, but if I were a company trying to choose an ISA for my own IP development, I'd probably want the ISA that has a Foundation I can join and help drive its direction going forward [Ed: it will be interesting to see how MIPS proceeds from here].
I wonder if this will include the MIPS 16e extension (the thumb-like instruction set for MIPS). It would be interesting to me if MIPS can compete with ARM in microcontrollers. As far as I know, only the PIC32 is MIPS.
I used IDT's MIPS IDTR3041 in an embedded system in the mid 90s... I remember compiling gcc for "decstation" to support it.
I think that nanoMIPS would be much more interesting. As I understand it, nanoMIPS is a modern, de-warted variant. For example, nanoMIPS doesn't have branch delay slots!
It would be more likely that nanoMIPS would be considered for open sourcing if that the implementation was to be made open source. Otherwise it would be the fobbing off of releasing the code to the InterAptiv which has MIPS16e(2) support.
The verilog for the UltraSPARC T1 core is GPL. I have my own fork on a dev board they used to make for the purposes of researchers modifying it and giving a modified processor a spin. So... I don’t think so?
I'm talking about the patent licences for the ISA, not a specific core. Does the GPLv2 licence for the T1 confer a patent licence? If not, you'd probably need patent licences for the 64-bit ISA from Oracle to market something, AIUI. Whereas I believe 32-bit SPARC is an IEEE standard and royalty-free.
SPARC V9 (which is the 64 bit version) lies with SPARC International. That doesn't necessarily extend to OSA2011/OSA2017, whose specifications are available from Oracle, but I wouldn't bet on their royalty-freeness.
The article notes the "maturity" of the support software. Indeed when I was writing manuals for SGI in the 90s, I was trying to document what seemed like extremely sophisticated compiler optimization techniques, including link-time optimization. (Due to customer demand there was also a screaming Fortran IV compiler, but it was bought in from a vendor.)
I also remember how one range of the MIPS line (4000?) had the "4K page bug" where a page fault induced by the last instruction on a page caused some nasty problem. IRIX had special code to handle it.
Will this make MIPS hardware virtualization available to the Western market? So far it's only been available in a Russian CPU (Balkal), https://news.ycombinator.com/item?id=18142295
Article says that PRPL foundation may be governing Open MIPS. There was an L4-based hypervisor offered by PRPL, but the website seems to have been reorganized.
Interesting that MIPS includes DSP functionality in the ISA. Does anyone have experience using DSP functionality with a MIPS chip? This seems like something that could be big, since so many of the DSP chips that are out there are totally proprietary, require proprietary compilers, etc. The idea of widely available DSP support that can be built with standard off the shelf OSS compilers / tools seems like something that could be a big win.
These include instructions for saturating arithmetic (arithmetic that give the greatest or lowest possible values, rather than wrapping around), 16 and 32 bit fixed point, fused multiply add instructions, and some SIMD instructions https://en.wikipedia.org/wiki/MIPS_architecture#MIPS_DSP
There's a reason why I said SIMD/vector extension, since RISC-V first started down the SIMD route, but then they took a step back and decided that a vector extension might work better, so from what I can tell more work has been going into the vector extension than SIMD. But neither SIMD nor the vector extension are finalized yet.
I'm unaware of a MIPS vector extension, it seems to just have standard packed SIMD instructions, though I'm not that familiar with MIPS.
This is awesome! It might mean we get a CHERI board without a RISC-V port. The port is still a good idea but a port to highest-end MIPS will probably be cheaper since it reuses toolchain and some hardware stuff.
Then we can make the desktop cases look like SGI’s as a tribute to the best MIPS of the past. Plus, they look cool.
Despite this announcement, RISC-V momentum is not going to stop. Anyone trying to understand why, should watch this presentation by Krste Asanovic, as it sets RISC-V in historical and market context.
It's cool to see such an old and well-used arch still be used in new applications, not just old legacy stuff.
And, gotta love: "Wave, which styles itself as a tech startup poised to bring “AI and deep learning from the datacenter to the edge,” sees MIPS as a key to advancing Wave’s AI into a host of uses and applications.". Hello, fellow kids!
Funny, I would have gone bananas over this a couple years ago. Now, its mix between disappointment and but still support. MIPS exists and will continue to exist, its far to large to ever go away so it is good that it will open up and eventually we can remove property architectures from the market.
I just hope they really commit to that strategy. Remember Docker was once a failing PaaS company who released their tech as open source.
>"Included in MIPS instruction sets are extensions such as SIMD (single instruction, multiple data) and DSP."
I always thought of DSPs as being a specific type of chip i.e a DSP chip. Are Are many DSPs MIPs based then? Is a DSP really just any general purpose CPU whose ISA has optimized DSP instructions then?
MIPS has what's called an Application Specific Extension (ASE) basis for extending a given MIPS core for particular areas.
The MIPS DSP ASE extends the base instruction set with certain instructions applicable to various codecs of the day that the ASE was defined for. It's essentially extending a general purpose cpu to efficiently perform DSP like tasks.
BTW, some official information on MIPS' site[0] which doesn't show a fullscreen modal or split the information across three ad-laden pages ;) Looks like there is a forthcoming site[1] for the initiative as well, which has not launched yet.
If Imagination didn't win, CEVA would have been a much better fit for MIPS. IMG might have been better off focusing on something else ( But judging from their management direction and execution I doubt they would have survived long anyway )
I think only Cavium and Broadcom are the biggest supporter of MIPS, not sure if there are any other heavyweight, but both have in recent years diverged to ARMv8.
I think the most interesting part is open sources includes DSP and SIMD.
The article just says the most recent 32 and 64 bit instruction sets will be open. No mention of open core designs (there are many old versions of MIPS, it has been very fragmented, so excluding these makes sense to get some commonality).
And again, what does it mean for the instruction set to be open? Does that mean that they are releasing circuit schematics and hardware documentation? Surely it means more than releasing documentation for the instruction set like we have for Intel chips.
What about emulators? Did bochs and qemu need to get permission?
I'm not really understanding the legal basis here. Did these companies get patents for the instruction sets? Since instruction sets are really like APIs, can people get patents for APIs?
In the case of ARM you actually have to pay them extra for the privilege to implement your own architecture and there is no guarantee that they will allow you to do it. Furthermore you have to prove to them using their test suite that your implementation is compliant.
What applications is the hierarchical clustering approach MIPS's owner Wave is taking to designing ASICs for machine learning going to work best for? Deep learning?
Anybody with ASIC design experience have a view on whether what they've got will be competitive (along energy or speed dimension) with TPUs or whatever RISC-V solution NVIDIA is working on?
Well it is different, what they are delivering is not based on RISC V but rather a silicon implementation of their NVDLA which will act as a peripheral to a SiFive core.
"Open Source"? As if it really matters for the dozens of computer science courses out there which used MIPS as a base (and some are now switching to RISC-V)... and a lot of unlicensed MIPS-ish/clone cores are also present in various cheap Chinese gadgets. I mean, if the average second-year CS student can make a working MIPS core, what does that say about how much it's worth? It's such a mundane ISA that you can't really squeeze much out of it (and I'm not talking about adding SIMD and such, which you could do for x86 and ARM too) unlike x86 and to a lesser extent ARM.
x86 or ARM going open-source, now that would be interesting...
Is this only for their newest core or will they be releasing old stuff too? Would be really interesting to see the HDL for early MIPS processors like the 3051, 4300, 5900, etc.
Of those cores, MIPS own the direct rights to none of them.
The R3051 (used in the PlayStation 1) was a derivative of the R3000A (which MIPS should have the rights to) made by IDT. I don't think MIPS have the right to the modifications.
The R4300 (A derivative, the NEC VR4300 was used in the Nintendo 64) was designed by Quantum Effect; I think whoever owns what's left of them would own the HDL, if it's still around.
The R5900 (used as the core of the PlayStation 2's Emotion Engine) was designed by Sony and Toshiba; I'm pretty sure Toshiba have the rights to it.
I can't wait for a company to raise $100 million Series A to sell 'Enterprise, Open Source MIPS', then come back in 4 years with a blog post about changing the license due to concerns that large companies are taking advantage of it.
Probably not at this point. If they had done this right when RISC-V was first announced, then maybe, as at that point they had the advantage of much more ecosystem and tooling integration.
However, it's now at the point where there are shipping RISC-V Linux distros, it's supported in GCC and LLVM out of the box, there are more than a dozen open-source RISC-V cores (https://riscv.org/risc-v-cores/, several of which are actually parameterized families of cores), and there are companies like SiFive offering commercially supported proprietary cores. There is hardware that has shipped from multiple different vendors, and that likely means that there are a number of others where it's fairly far in the pipeline.
With MIPS being behind Intel on the desktop and server market, behind ARM on the proprietary embedded core front, and behind RISC-V on the open source ISA and cores front, it's a bit hard to see why someone would buy MIPS who hasn't already invested in it.
If you want something more well established with a wider variety of cores available to purchase, you'd go with ARM. If you want something with no ISA licensing fees and even potentially no charge at all for an open source core, you can go with RISC-V.
I suppose there is some chance that MIPS could win some folks over from RISC-V for already having stable SIMD and DSP extensions, and more overall architectural maturity than RISC-V. But given that this seems to just be opening up the ISA without opening up any cores, and right now is a press release without having decided on the governance structure for the project or released any assets, while RISC-V has a number of fairly mature open cores including Rocket, BOOM, RI5CY, and more, and has a governance structure with a number of different companies involved, it seems like it will be a while if ever for MIPS to catch up on the open ISA front.
> China is rallying around the architecture with perhaps hundreds of RISC-V SoCs and dozens of cores in the works.
> “We are talking hundreds, if not thousands, of [RISC-V–based SoC] projects under way; it’s crazy … probably at least 40 to 50 companies or academic groups are dabbing in core development — some for internal use, some for open-source, and some commercial”
When I mentioned "multiple vendors," I was talking about hardware implementations that have actually shipped.
I've been looking for RISC-V chips that I can buy right now, and from what I can tell, there are only a handful. Two from SiFive (the E310 embedded processor, and U540 supervisor mode/Linux capable processor), one from GreenWaves (the GAP8). Turns out since I last looked (around the beginning of October) it looks like the Kendryte K210 has been released, also available in the Sipeed M1 module (https://www.cnx-software.com/2018/10/22/sipeed-m1-risc-v-com...). Anyhow, that makes 3 vendors shipping hardware implementations.
It's possible there are other special purpose chips not widely available for sale, or not advertised to English speaking customers, but I haven't found much evidence of them.
There certainly are a lot of RISC-V projects under way, which was what I was referring to by "that likely means that there are a number of others where it's fairly far in the pipeline." I think the "hundreds" from the article you quote is about total number of projects, not total number of vendors.
Some of these are just academic projects, some are multiple projects at the same vendor, and so on. I wouldn't be surprised if it was dozens of vendors that have projects at various stages of completion, however. I can imagine we'll be seeing a lot of releases over the next couple of years.
And there are a number of cores you can run on FPGAs, from high-end cores like BOOM that can be run on big expensive Xilinx FPGAs (or on Amazon's cloud FPGAs), to low-end like PicoRV32 that you can run on a $5 Lattice ICE FPGA.
> It's possible there are other special purpose chips not widely available for sale, or not advertised to English speaking customers, but I haven't found much evidence of them.
Take any established Chinese IT company, there are chances they are working on RISC-V based SoC or two. Alibaba - CK902, Huami - Huangshan No. 1, not talking about less known at the West vendors.
But it seems there are some considerations among established IT companies about not announcing RISC-V products very loud, especially in English.
> The Western executive, speaking on condition of anonymity, told us, “A lot of the biggest companies doing this are being very discrete indeed: perhaps they cannot afford to upset Arm.” He said they fear being told by Arm, “‘Oh, the core for your new smartphone is two weeks late.’”
That's a good question. Did OpenSPARC slow down RISC-V?
It's worth noting that, as the article points out, MIPS remains patent encumbered, the ownership situation of these patents is itself quite complex, and all in all, it's not quite clear how the new "Open" licensing will work.
In my totally non-expert option, no, it will not slow down RISC-V.
The RISC-V instruction set family does benefit from the decades of research since MIPS was first created.
Also, a lot depends on the ecosystem surrounding whatever MIPS cores are available. Memory crossbars, interrupt handling, etc. There's a lot that goes into a system-on-chip.
It depends on bunch of small and medium-size Chinese SoC vendors, would they jump to MIPS now, or not. RISC-V is pretty much default ISA among them nowadays.
They will not. Important RISC-V companies like SiFive already ship commercial RISC-V that they helped develop. The same for Andes. Esperanto has a RISC-V core that is competitive with top ARM cores already. Western Digital has already committed to RISC-V and released open source cores, invested in RISC-V companies and has multiple products deep in the pipeline.
Academic research from Berkley, MIT, ETH and many others is already on RISC-V and they would be crazy to switch, RISC-V is perfect for them.
Not to mention that RISC-V is a better instruction set overall.
It depends if they truly open source their stuff, or if they just do their newest items. Their definition of open source and ours might be different as well.
I would take everything with a grain of salt until it is truly open sourced and then revisit the question.
I'm curious to hear the answer for this as well. Given the MIPS and RISC-V are similar in nature, I'm not sure what the impact of making an already widely used and quite mature RISC ISA open source when this was basically the entire premise behind RISC-V.
Had RISC-V not been born, MIPS wouldn't have made this announcement.