Ask HN: Does anyone have something negative to say about RISC-V?

It’s hard to critique a design that’s mostly hypothetical (implementations exist, but those parry critiques such as “it is slow” or “it doesn’t have vector instructions” with “it’s only the first version”).

So, the only thing one can readily critique is the instruction set. Here, they made trade offs that some would argue are bad. For example

- They deliberately choose to leave parts of the instruction space open. That’s good for extensibility, but must have a negative effect on code density.

- They are extremely liberal in allowing implementations to mix and match instruction set extensions. There already are 13 different extensions, potentially allowing for 8,192 different instruction sets (many of them quite silly), and they are already thinking on how to handle over 26: “Since single letters will run out someday, it is currently discussed to use a new naming scheme with Zxxx for standard instruction extensions and Yxxx for non-standard (vendor specific) instruction extensions” (https://en.wikipedia.org/wiki/RISC-V#ISA_Base_and_Extensions)

rv32 and rv64 are incompatible. this is unfortunate, and it's not clear to me what the tradeoff for that is.

Integer divide by zero does NOT raise an exception.

From the Spec: We considered raising exceptions on integer divide by zero, with these exceptions causing a trap in most execution environments. However, this would be the only arithmetic trap in the standard ISA (floating-point exceptions set flags and write default values, but do not cause traps) and would require language implementors to interact with the execution environment’s trap handlers for this case. Further, where language standards mandate that a divide-by-zero exception must cause an immediate control flow change, only a single branch instruction needs to be added to each divide operation, and this branch instruction can be inserted after the divide and should normally be very predictably not taken, adding little runtime overhead.

I do, they smell like teen spirit. Yuk.

The only thing I have against RISC-V is that I do not have a real RISC-V server up and running.

There is this 'SiFive unleashed'[1] but there could be something more real than that. I am ready to put down a lot of money on getting myself some real hardware. I am totally fed up with x86, its management engine and insanely bloated ISA. It is time for open hardware to take over my server closet.. and desktop.. and laptops.. and so on.

Now, not later!!!

[1]: https://www.crowdsupply.com/sifive/hifive-unleashed

Yes, I do.

Turing completeness means that instruction sets simply do not matter. In fact, you cannot buy a "native" x86 processor today. Every modern x86 processor actually has hardware to run some highly optimized microcode instruction set, plus an x86 emulator in software that runs on top.

ARM is the current viable alternative to x86. You could put an ARM chip in a desktop and it would be cheaper and faster than RISC-V for the foreseeable future. RISC-V is even more experimental than that and it has nothing to offer even in theory. The only standard for an ISA is performance. Any other features can and should be built on top.

I set the bozo bit on anyone crowing about RISC-V. Don't get me started on the Mill, it's just a shitty GPU.

I work for one of the big semicon and there is effort in the industry/our company to replace ARM with RISC-V. It is currently in the trial phase right now where I think the low-end would be tackled first to do a pipe-cleaning of the design flow and as a proof of concept. Once that's done (don't know how long) the big desktop cores will probably follow and then server. I don't know if it will play out that way but that's probably how it's being sold by VPs in order to get funding.

As I understand it, if you are going to go out of order, a large number of architectural registers is actually a handicap; it costs more resources to map them to physical registers.

Given that, was it the right choice to go with thirty-two architectural integer registers? Sixteen registers would be mostly adequate, and would seem to make it easier to implement out of order. What am I missing?

1. It fully subscribes to the Stanford Orthodox RISC propaganda. (E.g. "RISC is the best, CISC sux ") and this leads to some rather questionable ISA choices, e.g. No condition codes, poor vector instruction implementations, excessive architectural registers, bad code density, too many ISA extensions, lack of exceptions on many things, etc.

The other general point I really dislike is their focus on ISA as if that matters so much compared to uArch.

I have been following the main RISC-V ISA design mailing list for a while, and of course there has been criticism of some design decisions there.

My personal criticism would be that there are still missing parts: the B extension (bit operations like count leading zeros/count trailing zeros/popcount/byte swap), the V extension (extensible vector operations), and the P extension (packed SIMD) aren't ready yet. If your problem domain needs these, you'll have to either wait until they're specified, or use a non-standard extension (of course, a benefit of the RISC-V ISA design is that it makes easy to use non-standard extensions when you need to).

Other criticisms I've seen in the mailing list:

- As already mentioned by someone else here, the RV32 and RV64 variants (32-bit and 64-bit registers) are incompatible, that is, code written for RV32 won't run on RV64, while with some small tweaks to the instruction encoding, it could;

- Some have argued that the C extension (compressed 16-bit instructions - normal instructions are 32-bit) could have been done in a better way;

- All Linux distributions have converged on RV64GC as their base ISA, which includes the C extension, and some have complained about this choice;

- There have been some complaints of possible interrupt latency on embedded systems due to having to save/restore registers without hardware help.

It is not really something negative (because it will have to be seen in the future), but to me the biggest point about RISC-V is whether it will deliver its promise of eventually giving birth to completely open and high quality CPUs. The experiments so far are interesting and the people and firms working on it seems (to me) to be trustworthy, but the implementations so far are still lacking: the HiFive Unleashed board has a lot or proprietary IP inside and I am told that it has some stability problems. I understand and agree that things take time, but in the end we will have to see if a good and open ecosystem develops around RISC-V or not.

There's nothing particular interesting about RISC-V. It's a simple, clean, boring MIPS-like ISA.

A lot of their freedom to keep it simpler and cleaner than older RISC ISAs comes from the fact that they aren't responsible for engineering real implementations; whereas the MIPS and SPARC and ARM folks ended up with delay slots and register windows and conditional execution because it helped them get high speed CPUs out with the processes of the day, the RISC-V people just say "well, those eventually turn out to be bottlenecks for high speed-implementations, so we won't have them" - never mind that these hypothetical high-speed implementations will require enormous engineering efforts and will require piles of money to actually build. We're not quite talking "Sufficiently Smart Compiler", because the technology does exist - but it's not totally far off.

People have been comparing it to Linux, but it's just an instruction set, not an implementation of one - so it's really more like POSIX - just a theoretical standard of compatibility that'll allow an ecosystem to build around it.

The problem is that, as Someone mentions in this thread, there's lots of officially codified extensions, and no restrictions (as far as I know?) to keep implementors from devising their own. We'll see how this turns out; my guess is, if RISC-V catches on, we're going to end up with mutually incompatible extensions, balkanization, and proprietary extensions becoming accepted "standards" in the "embrace, extend, extinguish" style.

What I have negative to say has more to do with those producing implementations than the architecture or RTL. In order to have the security afforded by being open, every part of the process must be open from the spec to the silicon. The entities producing RISC-V devices are simply passing forward the RTL along with their additions and changes. They are not releasing the work product of any of the steps between there and silicon. There are many differences between RTL and the gate-level representation, many of which represent potential security issues (testability features, for instance.) Between gates and physical design more changes can be made and between physical design and mask, even more. Some of those could result in sloppy security holes or some could even be maliciously introduced security holes. With any of the current providers there is no way to know or test for these potential issues.

There is no RISC-V-based computer commercially available.

Well, compared to Intel's chips it lacks a lot of advanced tech like SGX, TSX, MPK etc.

Compared to the Mill it's a rather boring design that doesn't try to do anything new. The Mill is even more hypothetical than RISC-V but at least it is a genuinely interesting architecture.

Note that the following are just my impressions from reading though the spec about a year ago. I did not do any deeper investigation beyond that and might misremember some details.

* IMO they were a bit too generous with using up 32-bit instruction encodings, only 3 of 28 major opcodes (blocks of instructions) are still reserved, though there is still some space for individual instructions within several of the used blocks. Using 4 major opcodes for 4 different sign variants of fused multiply-add seems particularly wasteful. (Of course there is still plenty of space in 48-bit and longer instruction spaces)

* Integer overflow handling code is quite verbose and might also result in lowered performance (at least in simple implementations). I'm unhappy that many languages choose silent wrapping over trapping on overflow out of performance concerns (e.g. Rust and C#), so efficient overflow checking is quite important to me. (Efficient overflow checking is also useful for seamlessly switching to big integers on overflow, which is my preferred approach for high level programming languages)

* Their approach to atomics is elegant but also unconventional. This might make porting existing code difficult. In particular the lack of double wide compare-and-swap looks like a pain point.

* Their approach to SIMD/vector instructions only seems a like a good approach for floating point arithmetic, but might struggle with common integer tasks. For example I'm not sure how shuffles fit into their variable length vector model.

* I don't like their choice of sign extending unsigned integers in the ABI.

RISC-V is a something one might even learn somethings from, maybe. But it will never be a viable commercial alternative.

-- ARM

I question if RISC-V went far enough.

Having human readable and understandable instructions seems unnecessary in the days of optimizing compilers.

Instead, the CPU should have a bunch of hardware, and then allow the compiler to define it's own instruction set via a large control blob. Each software binary should begin with "here are all the instructions I'm going to use, and here is what actions should be taken for each".

The mapping the applications desires for each possible instruction to the actual hardware should then be left to some OS component which is easily upgradable. It is the component which will have by far the biggest performance impact.