Hacker News new | past | comments | ask | show | jobs | submit login
MIPS Goes Open Source (eetimes.com)
508 points by walterbell 4 months ago | hide | past | web | favorite | 147 comments

> “Had this happened two or three years ago, RISC-V would have never been born.”

Had RISC-V not been born, MIPS wouldn't have made this announcement.

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.

I don't program in assembler professionally, but I understand that MIPS has some ugly, ugly aspects:


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.

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.

It’s more than just a bit. You need a bit saying “in a delay slot” and a whole word that stores the target of the branch.

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.)

Sun opened the SPARC T2 a decade ago, and it certainly has not become popular

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.

Which is a pity, as currently the SPARC is the only commercial CPU able to tame C.

At least with luck those features are coming to ARM v8.3+ as well.

> Which is a pity, as currently the SPARC is the only commercial CPU able to tame C.

What do you mean? That it includes protection modes which make C "safe"?

SPARC has memory tagging support since M7.



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.

A minor nit, but memory tagging is in ARMv8.5, not 8.3.

Thanks, fixed it.

SPARC has weird register windows that scare C programmers out of playing games with the stack, resulting in safer operation.

SPARC ADI is a bit more than that.

5 minutes of googling hasn't given me anything about SPARC and C. Can you elaborate?

Check my other reply.


You need to be a bit comfortable with Solaris and enterprise web sites to dig it out.

MIPS support is some of the most mature in GCC. The architecture is well understood.

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.

Ah, those mature MIPS routers https://news.ycombinator.com/item?id=18688947

Yep :) They can be fixed with a software update.

Can, but wont.

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).

> https://www.youtube.com/watch?v=DNYvIrI5Bbs

On the other hand, OpenWrt implemented full system-wide ASLR recently. NX and jailfs is still a WIP.

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.

Register windows were copied by MMIX.

> ARM hopelessly balkanized


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.

You can buy MIPS processors starting at 80c. I dont see that as an irrelevance.

Completely right. Also, it's too late.

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 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.

Would you rather it stay closed?

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.

To what extent can RISC-V adopt ideas from MIPS, assuming compatible licenses? Is it not really transferable because of core differences?

From the article:

> 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.”

I've heard a lot of people say RISC-V is very "MIPS Like" as well

Just minus a lot of the "legacy baggage"

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.


> 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.

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).

MIPSR6 does away with the HI/LO registers and have multiplication instructions which return the result to GPR registers.

Pre-R6 MIPS cores have the MUL instruction which hide the usage of the HI/LO registers, but do clobber those registers.

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.

Really? Does RISC-V have delay slots? To me, this is one of the biggest differentiating factors in ISAs.

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.

Yeah, having dispatch order not match retire order is a huge pain in the ass for OoO cores.

Can you not make delay slot a dependent item to retire?

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.

I believe the parent meant that to go under the "less legacy baggage" heading.

IIRC nanomips(?) doesn't have delay slots either?

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.

mindblown.gif :)

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.

MIPS isn't really known for peripherals either.

Modern MIPS implementations usually have AMBA support.

And there's open TileLink->AMBA bridges too if that counts.

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.

And SuperH which patents have expired - http://j-core.org/

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

[2] https://deepspec.org/entry/Project/Kami

> Of course, tooling and C compilers for the non-standard ISA are the main obstacles on this way.

Yup, see the Itanium architecture for how pernicious this can be to the survival of an architecture.

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).

The Itanium failed because Intel signed cross-licensing deals with AMD a couple of years before, and AMD just got lucky with their extensions.

If there was no AMD in the picture we would all be using some form of Itanium by now.

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.

POWER8 is also open now: https://openpowerfoundation.org/ By far the best of those. But IBM, and it's not POWER9.

It's not clear what exactly is open about OpenPOWER. Firmware, sure. But is the ISA actually royalty-free?

>and it's not POWER9

Surely POWER9 is open as well? Otherwise how did Raptor ship their POWER9 CPU?

Power9 only has open firmware and ISA, but not the verilog. They just resell it, to Raptor and Google-Rackspace mostly.

Don't they just resell the CPUs? I think the mainboards are designed and produced by them, but not the CPUs.

What licence?

Their FAQ certainly reads more like "source available" than "open source". You have to be a registered MIPS Open Member to even see anything.


> 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.

I think this might change. They are participating at least a bit for now.

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].

MIPS is involved in this foundation: https://prplfoundation.org/current-members/

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.


Will Sparc follow? I used the LEON4 SPARC processor in Intel / Movidius Myriad recently, was surprised to see Sparc...

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.

> Will Sparc follow?

SPARC is already open, as in it can be used royalty free and there are open source implementations.

And even such things as

> Heterogeneous-ISA with RISC-V and SPARC FPGA Soft-cores


My understanding is that only 32-bit SPARC is open. The 64-bit extensions are still proprietary, aren't they?

The T1 and T2 are both 64-bit, the Verilog for them is GPLv2.

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.

Virt whitepaper: https://prplfoundation.org/wp-content/uploads/2018/07/prpl-s...

Lol, the story with them choosing MIPS over ARM is that ARM was too afraid to get slapped with sanction, and they went to MIPS instead.

After ARM saw that the sky is not falling on MIPS, they decided to license them their cores as well.

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

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.

They are trying to support vector machines as well as SIMD instructions.

You mean RISC-V or MIPS?

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.


That would be industry-changing for desktop security - capabilities in open hardware.

Does the MIPS ecosystem have an equivalent to coreboot?

For what? There is https://en.wikipedia.org/wiki/Das_U-Boot and https://www.linux-mips.org/wiki/PMON_2000 I bet "Das U-Boot" is more of an "ecosystem" than coreboot when you zoom far out and see the installed base of embedded devices. Coreboot unfortunately not so much in comparison.

Currently I am looking into the Arm v8.3+ memory tagging instructions.

It still isn't SPARC ADI, but at least we might get some additional safety along the OS stack that way.

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.


edit: added link to presentation.

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!

As opposed to the 8080 variant most people have in their PCs?

68000 was the better CISC architecture.

The devil lies in the details: it all depends on the actual license that Wave Computing will use for MIPS.

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.

The article states:

>"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.

[0] https://www.mips.com/mipsopen/ [1] https://mipsopen.com/

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.

what does open source mean in this context?

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.

It means that you are allowed to design/produce a chip using this instruction set without getting sued.

Just that? With no extra help from them? No schematics or diagrams or documentation? Do you still have to reverse-engineer their work?

Did AMD have to get permission from Intel to implement the i386 instruction set?

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.


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?

Till the silicon comes nobody can really say much. Also NVIDIA is only using RISC V for the system controller for their future GPUs.

NVIDIA is also working with SiFive to deliver some of their stuff on RISC-V.

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.

From what I gather they are also holding Lexra core IP.[1]

Hopefully they will be releasing the Lexra IP too. I have stumbled upon many routers that utilize Lexra cores.


Hearing news like this I wonder, what happened to Transmeta's processor architectures?

Similar capabilities are shipping in some Nvidia CPUs, https://hothardware.com/news/nvidias-64bit-tegra-k1-the-ghos...

Transmeta's founder is working on RISC-V AI/ML chips at Esperanto.

Their patents ended up getting bought up by a patent troll. I assume that was the end of their architectures.

"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.

Yeah I know there's licensing issues for those exact processors, it would still be cool to see the stuff they were derived from.

Only ISA? I must have missed something, but I cannot see if they are going to open-source its implementation though.

I wish they could opensource mipspro

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.

Will it slow down RISC-V?

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.

> from multiple different vendors


> 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.

> The RISC-V instruction set family does benefit from the decades of research since MIPS was first created.


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.

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.

That basically comes down to whether RISC-V's current partners decide to jump ship for something more well-known.

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.

RISC-V is not just to have an open ISA but to have an ISA that is modular and designed in an open process.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact