Some Criticisms of RISC-V | Hacker News Reader

Some Criticisms of RISC-V

gist.github.com

To these I would add: lack of a rotate instruction in the base ISA, and unix standard extension groups. This makes symmetric key encryption and most hash functions much slower. The Bitmanip extension has a rotate instruction, but it should have been in the base ISA.

I'd also emphasise the lack of indexed load/store instructions again. It is a disaster for any sort of array indexing where you're addressing >1 array using the same index. I found this in the context of multi-precision arithmetic for crypto, but examples come from all over.

On the author's point about multiply and divide in the same extension: crypto is another good example. Lots of crypto really benefits from multiply, but doesn't need divide.

The most important thing about RISC-V is the idea behind it's openness as a standard and the ecosystem around that standard. The engineering of the ISA itself is not what makes it remarkable, and actually leaves a lot to be desired.

I see the word "crypto" in each of your objections. While crypto is important, it's not the whole world and not everyone needs the absolute fastest crypto possible. If you do, then use a processor with crypto instruction extensions. If not, you can get by just fine with the operators C gives you.

Most software doesn't use rotate operations. When you do need one, it takes three instructions to synthesize it if the shift count is a constant, or four otherwise. Unless you're doing nothing but rotates you're not going to notice it. If you're doing any memory loads that miss in the L1 cache to get the data you're rotating then you're also not going to notice it.

The same goes for the indexed loads and stores. Measure it, don't just go on your feels.

The main problem with the the original post is that the author criticizes things based on his sense of aesthetics, and what he's used to, not on any kind of actual scientific experimentation and measurement of different options.

The whole premise of H&P's "Computer Architecture: A Quantitative Approach" is that you should base decisions about what to put into your hardware and what to leave out based on actual data, not on what seems prettier or more orthogonal to you.

It does neglect that one overarching design goal was to not be encumbered by any IP. That means you have to pick your solutions exclusively from expired patents and, no, you don't get to be clever and come up with new things along the way because, again, you risk one of the behemoths raining hellfire down on you.

Alibaba crafts world's 'fastest' 'open-source' RISC-V processor yet: 16 cores, 64-bit, 2.5GHz, 12nm, out-of-order exec

https://www.theregister.co.uk/2019/07/27/alibaba_risc_v_chip...

"The aforementioned RV64GCV designation means the Xuantie 910 implements the base 64-bit RISC-V ISA (RV64G), supports compact 16-bit-wide instructions (C) as well as the usual 32-bit-wide instructions, and supports still-in-development vector math operations (V). Interestingly enough, though, it is also said to include 50 non-official instructions for assisting and accelerating various tasks, from memory management and CPU core wrangling to storage access."

Having one instruction that can be a branch, call, or return seems super weird, what’s the reasoning for it?

The basic idea is that the unconditional jump instructions can optionally write the address after the jump to a register, which allows reusing them as call instructions (it stores the return address in the register). Since calls don't manipulate the stack, return becomes equivalent to an indirect jump to the return address. Thus indirect call, indirect jump and return all become the same instruction.

I think this is elegant, at least superficially. However this ambiguity makes tracking the callstack harder, which RISC-V solves by introducing the convention that the x1 register is used for the return address. Which means that the normally irrelevant choice of register suddenly has performance implications, which is not so elegant.

I'm guessing some misguided attempt at unifying: "They're all a kind of branch". The instruction here is JALR rd,rs1,offs.

It takes three arguments: rd, the destination register to put the return address in (it should always be the ABI-defined link register, e.g. t1), rs1, the source register that jump should be relative to (it should always be the link register for a return, and 0 for a call/branch). To a software guy, there's elegance in unifying the three cases, but there's really no such principle in hardware. It just makes the implementation more complex, since branch/call/return all greatly differ for prediction, prefetching, etc.

I would argue that it's not that elegant in software either. By unifying the instruction, you lose semantic information about what the program is trying to do.

It is unfortunate that they are locking down choices so early, before anybody has enough experience to know if they are right; and we know some are wrong.

I was astonished that they didn't consider bitwise anything -- including rotate and popcount -- worth bothering about. It is sad they settled on 1, not ~0 for their bool true value, in the ABI. Do they even have short load-immediate -1, 0, and 1 instructions?

Micro-op fusion is great, but only if you can keep your instruction decoder sated.

The RISK instruction set was made based on the idea that the compiler could do most of the work, so make the hardware instructions simple. But was coming from a time when processor bus speed and memory speed were the same, and microcode was fairly simple. The assumptions didn’t pan out.

I remember 25 years ago grumbling that RISK processors couldn't be fed instructions fast enough to keep the pipelines full.

I also remember a friend that worked at a failed processor company in the 1990's. Said the real reason the company went under was the academic designers thought programs 'do integer math' when modern programs 'do string manipulation'.

I forget, what does ARM stand for again? :)

Historically Acorn RISC Machines that ran an OS called RISCOS.

> I forget, what does ARM stand for again? :)

What do you believe is the reason that ARM does no market this acronym anymore? ;-)

"Acorn" not being relevant? :D

Obligatory Dilbert: https://dilbert.com/strip/1994-07-11

(Obviously not saying OP is an uninformed pundit — topic just sparked a funny memory)

Reply on news.ycombinator.com