Hacker News Reader

Comment by musicale | Hacker News Reader

There's a lot to like about MIPS. It's a perfectly usable RISC architecture that:

- is easy to implement

- is supported by Debian, gcc, etc..

- is virtualizable

- scales from embedded systems (e.g. compressed MIPS16 ISA) up to huge shared-memory multiprocessor systems with hundreds of CPUs

Like RISC-V, MIPS traces its lineage to the dawn of the RISC revolution in the 1980s, though on the Hennessy/Stanford side rather than the Patterson/Berkeley side.

And it was supposed to go open source: https://www.mips.com/mipsopen/

but that effort sadly seems to be dead: http://mipsopen.com

That's really too bad. MIPS doesn't deserve to die.

Fortunately as mentioned above it will live on as long as there are PS2 consoles or emulators around.

View on HN

There is no, one, MIPS ISA. They've been through a number of incompatible changes over the years. MIPS r6 added some things more like RISC-V. NanoMIPS loops even more like RISC-V, though with its own twist (and with some 48 bit instructions, which RISC-V doesn't have yet).

In many ways modern MIPS and RISC-V are pretty much just different binary encodings of the same ideas.

In 2010 MIPS wanted $2 million from Berkeley to allow them to use the MIPS instruction encodings for processor cores that Berkeley would design entirely themselves. So they made up their own encodings instead.

The rest is history.

Excellent point. MIPS overplayed its hand.

It's funny how this story repeats itself over and over again, yet companies never seem to learn.

The flipside of this is when companies like Apple, Microsoft and Adobe, like it or not, become part of the de facto tech learning arc for college students, who one day grow up to be senior engineers, lead engineers, architects and principal engineers.

- the NOP instruction is 0x0

I don't know if MIPS is the same, but I worked on an other architecture where NOP is 0x0, and it had an interesting effect. If you called an uninitialized function pointer, and it happened to point into zero:ed out memory, the CPU would execute NOPs for a good while until it hit something else. If that something else was code, it would start executing some function from the start, but with garbage arguments. It would often get quite far in and several functions calls down before something crashed. Made for fun stack traces and interesting debugging :-)

Seems like a better design choice would be to have instruction 0x0 throw some kind of page fault violation or other exception the OS can catch then.

Shades of the 6502, where 0 was BRK

It is and on RISC-V 0 (16-bit bits and 32-bit) are an illegal instruction. Jumping to zeroed page is obviously a bug so this is the correct behavior.

AVR does this. I can attest to the “interesting” debugging...

nanoMIPS (the last compressed MIPS ISA that sadly never made it across the whole product line) re-encoded nop(32) for much the same reason.

RISC-V deliberately made sure both all 0s and all 1s are forever illegal instructions, in all instruction lengths.

Wasm too. Bytecode 0 is "unreachable" and executing it produces a trap.

Specifically to avoid infinite loops?

To make hitting uninitialised RAM or Flash or OTP (or others) stop the program immediately.

Reply on news.ycombinator.com