Hacker News Reader

Comment by jf | Hacker News Reader

> “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:

https://www.jwhitham.org/2016/02/risc-instruction-sets-i-hav...

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

https://www.oracle.com/technetwork/systems/opensparc/openspa...

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.

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.

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

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.

> ARM hopelessly balkanized

???

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.

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.

shudder

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.

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

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.

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

SPARC has memory tagging support since M7.

https://swisdev.oracle.com/_files/What-Is-ADI.html

https://swisdev.oracle.com/_files/M7_Preso.pdf

This is enabled by default in Solaris since version 11.

"Secure Software - Made Simple with Software in Silicon"

https://www.youtube.com/watch?v=krOhcjF5Fsw

https://lazytyped.blogspot.com/2016/12/hardware-buffer-overf...

ARM v8.5 memory tagging extensions aims to try to achieve parity with it.

https://www.youtube.com/watch?v=IbisEjzoxTY

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.

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

Check my other reply.

https://news.ycombinator.com/item?id=18705340

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

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.

https://stackoverflow.com/questions/27893526/mips-are-some-a...

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

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

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.

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.

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.

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.

Reply on news.ycombinator.com