Had RISC-V not been born, MIPS wouldn't have made this announcement.
RISC-V may have hastened its demise, but the writing was on the wall for a long time.
Sun opened the SPARC T2 a decade ago, and it certainly has not become popular:
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.
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 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.
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.
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.)
I'm not saying it would have become any more popular without this, but the fact that Oracle purchased Sun probably didn't help adoption here, at all.
At least with luck those features are coming to ARM v8.3+ as well.
What do you mean? That it includes protection modes which make C "safe"?
This is enabled by default in Solaris since version 11.
"Secure Software - Made Simple with Software in Silicon"
ARM v8.5 memory tagging extensions aims to try to achieve parity with it.
Google is planning to make use of them on the native layer of Android when they eventually became available.
Meanwhile Intel has decided to remove MPX from x86/x64 because no one is adopting them on Intel/AMD CPUs.
EDIT: Got the ARM version wrong.
You need to be a bit comfortable with Solaris and enterprise web sites to dig it out.
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.
> 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).
On the other hand, OpenWrt implemented full system-wide ASLR recently. NX and jailfs is still a WIP.
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.
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.
The people who think "there's still time" completely misread the situation. Same with the "maturity" argument.
None of these plans are a surprise to anyone. MIPS has been working on this for quite a while.
Yet they have exactly zero announcement partners saying they plan on doing something with it.
That's because none of them care at this point.
(Also, it will take a year or two before any of this is real in a way a partner might be able to use/contribute to/care about etc)
The only meaningful thing that will happen here is people will try to use it to leverage the stuff they want out of risc-v to happen.
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 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.”
Just minus a lot of the "legacy baggage"
> Programming Notes:
> 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.
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).
Pre-R6 MIPS cores have the MUL instruction which hide the usage of the HI/LO registers, but do clobber those registers.
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.
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.
IIRC nanomips(?) doesn't have delay slots either?
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 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.
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
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.
 "Synthesis of Processor Instruction Sets from High-Level ISA Specifications" IEEE Transactions on Computers 2014, 63(6), 1552-1566
Yup, see the Itanium architecture for how pernicious this can be to the survival of an architecture.
> 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.
RISC, while older, at least was informed by what real compilers actually liked (lots of GPR's, simple instructions).
If there was no AMD in the picture we would all be using some form of Itanium by now.
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.
Surely POWER9 is open as well? Otherwise how did Raptor ship their POWER9 CPU?
Their FAQ certainly reads more like "source available" than "open source". You have to be a registered MIPS Open Member to even see anything.
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.
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 used IDT's MIPS IDTR3041 in an embedded system in the mid 90s... I remember compiling gcc for "decstation" to support it.
Will Sparc follow? I used the LEON4 SPARC processor in Intel / Movidius Myriad recently, was surprised to see Sparc...
SPARC is already open, as in it can be used royalty free and there are open source implementations.
> Heterogeneous-ISA with RISC-V and SPARC FPGA Soft-cores
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.
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.
Virt whitepaper: https://prplfoundation.org/wp-content/uploads/2018/07/prpl-s...
After ARM saw that the sky is not falling on MIPS, they decided to license them their cores as well.
Basically your usual DSP fare.
ARM has a similar extension; see https://en.wikipedia.org/wiki/ARM_architecture#DSP_enhanceme... for a reference to it, or http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.... for details.
I don't think that RISC-V has a DSP extension yet; they are still working on nailing down their SIMD/vector extension story.
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.
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.
Does the MIPS ecosystem have an equivalent to coreboot?
It still isn't SPARC ADI, but at least we might get some additional safety along the OS stack that way.
edit: added link to presentation.
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!
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?
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.
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.
Did AMD have to get permission from Intel to implement the i386 instruction set?
Yup, and Intel needed permission from AMD to implement the x86_64 instruction set.
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?
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?
Hopefully they will be releasing the Lexra IP too. I have stumbled upon many routers that utilize Lexra cores.
Transmeta's founder is working on RISC-V AI/ML chips at Esperanto.
x86 or ARM going open-source, now that would be interesting...
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.
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”
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.
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.’”
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.
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.
Also, RISC-V has a business model built around open source, it isn't a desperation move, which is what the MIPS move smells like.
Also, RISC-V has mind share right now -- implementing RISC-V variations is now homework sets for MIT 6.004. MIPS is day-old bread.
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.
I would take everything with a grain of salt until it is truly open sourced and then revisit the question.