Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Addressing Criticism of RISC-V Microprocessors

erik-engheim.medium.com

Post reply on HN
Print view View original

61–70 of 149 posts

Re: Addressing Criticism of RISC-V Microprocessors

#61

Post by ansible »

adrian_b wrote: post #17
FullyFunctional wrote: post #9

Earlier quoted context omitted.

This comes up a lot and I'm sympathetic to your plea, really (I enjoy fantasizing about a different reality where CPUs weren't just "machines to run C programs"), but in computer architecture, what really matters for one application or a class of applications might not be important when viewed across millions of programs. The fact is that integer operations and floating point are two completely different beasts, so m…

Generating the overflow bit and storing it adds a completely negligible cost to a 64-bit adder, so touting this as a cost saving measure is just a lie, even if indeed this claim has always been present in the RISC-V documentation. Most real cases of overflow checking are of the last type. Tripling the number of instructions over a bad ISA that lacks overflow exceptions, like unfortunately almost all currently popular…

> The cost of implementing the 2 overflow bits is absolutely negligible, 2 gates and 2 flip-flops. Much more extra hardware is needed for decoding a few additional instructions for flag testing and clearing, but even that is a negligible cost compared with a typical complete RISC-V implementation.

That's understating things considerably.

ARMv8-A has PSTATE, which includes the overflow bit. This explicit state must be saved / restored upon any context switch.

And there isn't just a single PSTATE for an OOO SuperScalar, there are several.

Everything has a cost.

Re: Addressing Criticism of RISC-V Microprocessors

#62

Post by throwaway81523 »

FullyFunctional wrote: post #9
throwaway81523 wrote: post #4

Fairly lame article (not wrong, but stuff people following the topic have seen before), and I'd still like to hear about integer overflow detection. If the floating point extension is able to do IEEE 754 condition codes including overflow detection, why can't the integer unit do something similar?

This comes up a lot and I'm sympathetic to your plea, really (I enjoy fantasizing about a different reality where CPUs weren't just "machines to run C programs"), but in computer architecture, what really matters for one application or a class of applications might not be important when viewed across millions of programs. The fact is that integer operations and floating point are two completely different beasts, so m…

Yes I've seen that reasoning: they propose bloating 1 integer instruction into 4 instructions in the usual case where the operands are unknown. Ouch. In reality they expect programs to normally run without checking like they did in the 1980s. So this is more fuel for the criticism that RiscV is a 1980s design with new paint. Do GCC and Clang currently support -ftrapv for RiscV, and what happens to the code size and speed when it is enabled? Yes, IEEE FP uses sticky overflow bits and the idea is that integer operations could do the same thing. Integer overflow is one of those things like null pointer dereferences, which originally went unchecked but now really should always be checked. (C itself is also deficient in not having checkable unsigned int types).

Re: Addressing Criticism of RISC-V Microprocessors

#63

Post by throwaway81523 »

adrian_b wrote: post #39
ajb wrote: post #32

Earlier quoted context omitted.

The extra expense is not the generation of the overflow bit, but the infrastructure needed to support a flags register, or for every instruction to be able to generate an exception. On a simple processor like a microcontroller this doesn't cost much, but it's severely hampers a superscalar or out of order processor, as it can't work out very easily which instructions can be run in parallel or out of order. The clean…

One must not forget that on any non-toy CPU, any instruction may generate exceptions, e.g. invalid opcode exceptions or breakpoint exceptions. In every 4-5 instructions, one is a load or store, which may generate a multitude of exceptions. Allowing exceptions does not slow down a CPU. However they create the problem that a CPU must be able to restore the state previous to the exception, so the instruction results mus…

> After that, the design engineers must spend extra efforts into workarounds for the ISA shortcomings.

That is too optimistic. Programs will keep running unchecked and we'll keep getting CVE's from overflow bugs.

Re: Addressing Criticism of RISC-V Microprocessors

#64

Post by Someone »

socialdemocrat wrote: post #53
ribit wrote: post #35

I have difficulty following the points the author is trying to make. - Even with instruction compression the type of code they present will take more space than, say, Aarch64. - The entire section on conditional execution doesn't make any sense. Conditional execution is bad, we know it, that's why modern ARM does not have conditional execution. Overall, author's insistence to compare RISC-V to practically obsolete AR…

Author here: I have tried to clarify this better in the update. The point is that I am talking about AArch32 and AArch64 in the article. Yes, everybody has been going away from conditional instructions, because they don't work well in Out-of-Order superscalar processors, and they are pointless when you got good branch predictors. HOWEVER, an argument in the ARM camp is that they are very useful when dealing with smal…

> There has been ARM fans claiming that conditional instructions make ARM superior for simple chips.

For those following this only from the sidelines, it would help strengthen the article if the article has links to such claims. I couldn’t easily find them, and would be curious as to their age, given that, reading https://en.wikipedia.org/wiki/Predication_(computer_architec..., ARM has made substantial changes to conditional execution a few times since 1994 (over 25 years ago); Thumb (1994) dropped them, Thumb-2 (2003) replaced them by, if I understand it correctly, an instruction “skip the next 4 instructions depending on flags”, and ARMv8 replaced them by conditional select.

(In general, providing links to articles claiming each proclaimed myth to be true would strengthen this article. I think I’ve only ever read about #1, and not with as strong a wording as “bloats”)

Re: Addressing Criticism of RISC-V Microprocessors

#65

Post by socialdemocrat »

IshKebab wrote: post #24

Dubious. How is "you have to use this magic combination of instructions that compress & execute well" better than having a dedicated instruction? Also no mention of the binary compatibility issues - which `-march` do you compile your code for? On x86 you have a choice of 3. For RISC-V as far as I can tell there are 96 valid targets.

Because dedicated instructions suck up valuable encoding space, and the more instructions you have, the more instruction you have which potentially become obsolete with new advances in microarchitecture.

Not to mention that by sticking with simple single purpose instructions you make the CPU easier to teach to students. That is after all one of the goals of RISC-V in addition to creating a good ISA for industry.

Have we learned nothing about why we abandoned CISC in the first place? Those CPUs got riddled with instructions that never got used much.

Re: Addressing Criticism of RISC-V Microprocessors

#66

Post by snek_case »

saagarjha wrote: post #12
FullyFunctional wrote: post #11

Earlier quoted context omitted.

EDIT: Hmm, I seem to have picked a bad example. Try this one: int get(int *base, unsigned index) {return base[index];} Arm64: update: ldr w0, [x0, w1, uxtw 2] ret RV64GC (vanilla): update: slli a5,a1,32 srli a1,a5,30 add a0,a0,a1 lw a0,0(a0) ret RV64GC+Zba: update: sh2add.uw a0,a1,a0 lw a0,0(a0) ret Arm64 is able to do some indexed loads in a single instruction that might take two in RISC-V w/Zba (and up to 4+ in reg…

> 25% fewer bytes has only very marginally impact on a high-performance implementation Instruction cache doesn't come for free, and is usually pretty small on most shipping processors. It's not a big deal for smaller benchmarks, but in real-world programs this can become a problem.

Not only that, but CPUs have a maximum number of instructions they can dispatch per cycle (typically 4 or 6). Even in microbenchmarks, the difference there could show up.

Re: Addressing Criticism of RISC-V Microprocessors

#67

Post by monocasa »

IshKebab wrote: post #36
mhh__ wrote: post #30

Earlier quoted context omitted.

No. Firstly -march (or similar, e.g. -mcpu in LLVM land) should target a chip not individual instruction sets. Secondly, AVX-512 alone has a handful of different extensions. There are a bunch of different SSE variants, and similarly instructions are still being added to the VEX prefix (normal AVX). There is more potentially for getting it wrong with riscv but 64 bit implies a number of extensions too so it's too far…

What do you mean "no"? My comment was entirely factual. > Firstly -march (or similar, e.g. -mcpu in LLVM land) should target a chip not individual instruction sets. LLVM still uses -march. And no you shouldn't target a specific chip unless you know your code will only run on that chip. That's the whole point I'm making. Sometimes you do know that (in embedded situations) but often you don't . Desktop apps aren't comp…

> Yes but these are generally linear - if an x86 chip supports extension N it will support extension N-1 too. Not true for RISC-V.

Not if you include AMD and Intel cores in that.

Re: Addressing Criticism of RISC-V Microprocessors

#68

Post by monocasa »

albanread wrote: post #55

People should zoom right out and think about the whole RISC-V project. When our phones have billions of transistors, are we seriously supposed to believe that RISC philosophy still matters. Personally I greatly prefer the user programmable 68000 family of processors. The marketing of RISC-V is perhaps the most impressive thing about it. Each to their own, I can see why giant SSD manufacturers want to use a license fr…

> When our phones have billions of transistors, are we seriously supposed to believe that RISC philosophy still matters.

The point isn't just saving gates because it's cheaper. Less gates means less critical path length, meaning less power consumption, and/or higher overall performance when compared apples to apples.

Re: Addressing Criticism of RISC-V Microprocessors

#69

Post by damageboy »

FullyFunctional wrote: post #11
abainbridge wrote: post #10

Earlier quoted context omitted.

I'm guess that your assembly code is RISC-V with the Zba extension. Is the non-Zba version worse than Arm64? Compiling your function with Godbolt, I get: RISC-V (no Zba) Clang - 7 instructions - https://godbolt.org/z/7znnrzxKq Arm64 Clang - 7 instructions - https://godbolt.org/z/Trv8scxad Annoyingly I can't see the code size for the Arm64 case because no output is generated if I tick the "Compile to binary" option in…

EDIT: Hmm, I seem to have picked a bad example. Try this one: int get(int *base, unsigned index) {return base[index];} Arm64: update: ldr w0, [x0, w1, uxtw 2] ret RV64GC (vanilla): update: slli a5,a1,32 srli a1,a5,30 add a0,a0,a1 lw a0,0(a0) ret RV64GC+Zba: update: sh2add.uw a0,a1,a0 lw a0,0(a0) ret Arm64 is able to do some indexed loads in a single instruction that might take two in RISC-V w/Zba (and up to 4+ in reg…

Thank you for writing the obvious. Instruction Byte count is the wrong metric here 100%. Instruction Count (given reasonable decoding/timing constraints) is the thing to optimize for and indeed variable length encoding is very bad.

Re: Addressing Criticism of RISC-V Microprocessors

#70

Post by marcosdumay »

snek_case wrote: post #66
saagarjha wrote: post #12

Earlier quoted context omitted.

> 25% fewer bytes has only very marginally impact on a high-performance implementation Instruction cache doesn't come for free, and is usually pretty small on most shipping processors. It's not a big deal for smaller benchmarks, but in real-world programs this can become a problem.

Not only that, but CPUs have a maximum number of instructions they can dispatch per cycle (typically 4 or 6). Even in microbenchmarks, the difference there could show up.

The bottleneck on that is data interdependency of your algorithm. If you break it in 6 or 10 instructions, the data dependency stays the same.

(Of course, you can add unnecessary dependency with a badly designer ISA. But it's not a necessary condition.)

Post reply on HN