Hacker News Reader

Comment by chasil | Hacker News Reader

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.

View on HN

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.

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.

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

Reply on news.ycombinator.com