[userbinator]

RISC-V looks like MIPS but with some of the more dubious design decisions of the time (e.g. branch delay slots) fixed. The mix of 16-bit and 32-bit instruction lengths is reminiscent of ARC.

In other words, the characteristics of SoCs using this core will likely be very similar to the many out there using MIPS: cheap and simple, with performance that's acceptable for applications like routers and other embedded devices.

[hajile]

That raises an interesting point -- the original MIPS ISA hasn't been patent encumbered in quite a while (and even then, only two non-essential instructions were patent protected). Why should a person is this unknown ISA instead of MIPS?

[_chris_]

RISC-V started off from a modified MIPS ISA, but we frankly ran out of opcode space. We needed 64b, IEEE floating point, and a ton of opcode space to explore new accelerator and vector ISA extensions.

Even the smallest changes to MIPS to clean up things like branch delay slots means it's a new ISA anyways, so you get zero benefit keeping it "mostly MIPS". You can read a bit more about this in the "history" section in the back of the user-level ISA manual.

[userbinator]

I think it may be to avoid any political/legal issues - despite the patents having expired, MIPS still sells ISA licenses. On the other hand, RISC-V basically is most of MIPS (but most RISC ISAs are very similar anyway).

They also avoided the patented instruction issue completely by removing all alignment restrictions from the regular load/store; probably a good idea, with memory bandwidths being the bottleneck now and buses growing wider - the extra hardware is also negligible, basically a barrel shifter and logic to do an extra bus cycle if needed.

[FullyFunctional]

The specification (http://riscv.org/riscv-spec-v2.0.pdf) clearly states the reasons. It has nothing to do with political/legal issues. There are very good technical reasons for designing a new ISA.

That RISC-V resembles MIPS is a testament to what was good about the MIPS design, however if you look closely you will find the many ways in which RISC-V is different.

Truly, the specification is highly readable and the footnotes enjoyable. Having implemented multiple MIPS cores and so far one RISC-V core, I'm deeply impressed with the care that went into the design.

[renox]

> The mix of 16-bit and 32-bit instruction lengths is reminiscent of ARC.

MIPS has also MIPS16..

[jevinskie]

And now microMIPS, another attempt at 16-bit encodings.

[renox]

Thanks, I didn't know about microMIPS. I read about and was surprised by the LWMx(Load Word Multiple) instruction which doesn't seem in the RISC spirit at all.. That's funny, I think that ARM with its v8 ISA (64bit registers) dropped a similar instruction which it had before.

[sitkack]

I would attempt a nibble based compact instruction representation to reduce external memory bandwidth. Fixed width instructions kinda suck now that memory is such a bottleneck.

[TheLoneWolfling]

I've long wished of a middle ground between FPGAs and CPUs - namely a CPU with user-changable instructions.

Have a CPU that is a CISC (but internally a microcoded TTA), but with a large chunk of the microcode user-writable (So you have push-inst and pop-inst, where push-inst pushes the new instruction microcode into the microcode storage and copies the old instruction microcode onto the stack and pop-inst does the opposite). It keeps the advantages of fixed-width instructions while, depending on how the microcode is encoded, potentially having significant memory savings.

[rst]

The arc processor line from Synopsys does this commercially, I believe. Risc-v seems to be trying to support this sort of thing; there is reserved opcode space for implementation specific extensions

[TheLoneWolfling]

I was under the impression that Synopsys' ARC processors were configurable at design time, not runtime.

Or am I missing something? Have a link?

[sitkack]

JITs could synth new instructions.