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

101–110 of 149 posts

Re: Addressing Criticism of RISC-V Microprocessors

#101

Post by mst »

FullyFunctional wrote: post #87
avianes wrote: post #21

Earlier quoted context omitted.

Variable instruction sizes have a cost, but with only 2 instruction sizes like current RISC-V that cost remains very low as long as we don't have to decode a very large number of instructions each cycle, and it gives a huge code density advantage.

This biggest issue is one instruction spanning two cache lines, and even two pages. This means a bunch of tricky cases that is the source of bugs and overheads. It also means you cannot tell instruction boundaries until you directly fetch instructions, so you cannot do any predecode in the cache that would help you figure out dependencies, branch targets, etc. These things matter when you are trying to fetch 8+ instr…

Given the compression stuff is an extension (and so far as I can tell the 16-bit alignment for 32-bit instructions that can result in that sort of spanning is part of that extension), so far as I can tell you could implement said extension for tiny hardware where every byte counts, and then for hardware where you're wanting to fetch 8+ instructions per cycle just ... not implement it?

Wait (he says to himself, realising he's an idiot immediately -before- posting the comment for once). You said upthread the C extension is specified as part of the standard UNIX profile, so I guess people are effectively required to implement it currently?

If that was changed, would that be sufficient to dissolve the issues for people wanting to design high performance implementations, or are there other problems inherent to the extension having been specified at all? (apologies for the 101 level questions, the only processor I really understood was the ARM2 so my curiosity vastly exceeds my knowledge here)

Re: Addressing Criticism of RISC-V Microprocessors

#102

Post by tsmi »

wmf wrote: post #91
socialdemocrat wrote: post #84

Earlier quoted context omitted.

I think you are really missing the point here. Of course RISC-V has negatives but most of those negatives exist for good reasons. It is a question of tradeoffs. One of the most important goals of RISC-V is to make an architecture which can stand the test of time. In this space adding the wrong kind of instructions is a bigger problem than not adding particular instructions. Whether you look at x86, HTML or just about…

Most of the complaints about RISC-V are extremely basic things like array indexing and conditional execution. These will never not be needed.

I’m sure that’s what the team that invented segment registers said too.

The question is does it make sense to add these to the ISA long term? In the short term, given die density and how memory works today, it has advantages. But die density increases, making OoO cores cheaper, and memory technology changes. It’s not obvious that these are long term improvements.

Re: Addressing Criticism of RISC-V Microprocessors

#103

Post by klelatti »

avianes wrote: post #95
klelatti wrote: post #86

Earlier quoted context omitted.

You say that the benefit is 'huge' but why should I care about code density on a modern CPU with gigabytes of memory and large caches? From a performance perspective what is the evidence that this actually provides an advantage?

To clarify, I'm not saying that RISC-V code density of C extension is a big advantage over its competitors, but it is a huge benefit for RISC-V. You are right, code density is perhaps not that critical today. And it is difficult to quantify its relevance as code density is always related to other variables such as instruction expressiveness, numbers of uop emitted, etc. But I still think that code density is importan…

Thanks for clarifying - interesting to see a different philosophy being tried.

Re: Addressing Criticism of RISC-V Microprocessors

#104

Post by mst »

okl wrote: post #51
audunw wrote: post #47

Theres so many armchair specialists when it comes to criticizing RISC-V. I've seen people claim an ISA is better because it has branch delay slots.. which seems clever to someone who knows enough technical details about CPUs to understand what the benefit of that feature is ("free" instruction execution for every branch taken), but is a terrible idea for a truly scalable ISA (huge PITA for out-of-order architectures…

First you complain about "armchair specialists", then you make a blanket assertion about branch delay slots. Believe it or not, there are ISAs for applications where branch delay slots are useful, for example TMS320 DSPs with up to 5 delay slots.

My very much non-expert understanding was that branch delay slots where enough details of the target processor design are known at ISA design time to have the 'right' number of slots can be a neat optimisation.

OTOH if one is designing an ISA that will have a bunch of different implementations - and this includes later implementations wanting to be ASM compatible with earlier ones - they tend to eventually become a footgun for the processor designers. (if I remember correctly and didn't completely misunderstand, MIPS' branch delay slots were absolutely a neat optimisation for the early models, but when they went to a deeper pipeline for later chips required a bunch of extra design effort to maintain compatibility with, without being helpful anymore)

(explicit disclaimer that I'm an armchair amateur here, so if you're a fellow non-expert reading this comment before it attracts better informed replies please default to joining me in the assumption that I've made at least one massive error in what I'm saying here)

Re: Addressing Criticism of RISC-V Microprocessors

#105

Post by IshKebab »

monocasa wrote: post #67
IshKebab wrote: post #36

Earlier quoted context omitted.

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.

Why do you say that? Look here:

https://clang.llvm.org/docs/UsersManual.html#x86

Re: Addressing Criticism of RISC-V Microprocessors

#106

Post by avianes »

FullyFunctional wrote: post #92
avianes wrote: post #19

Earlier quoted context omitted.

Why using an unsigned? It is obvious here that RISC-V without Zba takes 4 instructions because it manages special cases related to unsigned. If you use a simple int for index: slli a1,a1,2 add a0,a0,a1 lw a0,0(a0) And isolating this code in a small function puts constraints on register allocation, but if we remove this constraint then we can write: slli a1,a1,2 add a1,a1,a0 lw a1,0(a1) Which is very suitable for macr…

Indeed why use unsigned? Go take a look at a lot of C code (hint, look at SPEC benchmarks). They do that. Decades of pointer == int == unsigned have let to a lot of horrific code. But we still compile it. The sins of the original RISC-V was spending too much time looking at RV32 and not realizing how big a problem this is in practice. Zba (slipped in as it’s not really “bit manipulation”) fixes the worst of this. ADD…

> Go take a look at a lot of C code (hint, look at SPEC benchmarks). They do that.

This does not really justify isolating that snippet if you admit yourself it's a bad one.

> The sins of the original RISC-V was spending too much time looking at RV32 and not realizing how big a problem this is in practice.

But indeed, my previous message shows that even without Zba the problem is erased by a good register allocation and macro-op fusion.

I think you are trying too hard to find special cases that "trick" RISC-V, you didn't even pay attention to the use of unsigned which is non-optimal (unsigned has an undesirable overflow semantic here).

Re: Addressing Criticism of RISC-V Microprocessors

#107

Post by modeless »

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…

> I'm assuming that you aren't asking for exceptions which literally nobody wants

I want exceptions. Why would they be a bad idea? Besides the fact that software doesn't utilize them today (because they're not implemented, chicken and egg problem)? IMO they would be as big a security win as many other complex features CPU designers are adding in the name of security, e.g. pointer authentication.

Re: Addressing Criticism of RISC-V Microprocessors

#108

Post by pxeger1 »

TazeTSchnitzel wrote: post #2

The conditional execution section makes no mention of the fact AArch64 doesn't have this feature either, and bizarrely lists a “64-bit” ARM code example that isn't. This doesn't inspire confidence in the author's understanding.

I thought it was only supposed to be pseudo-assembly?

Re: Addressing Criticism of RISC-V Microprocessors

#109

Post by bigcheesegs »

google234123 wrote: post #78
socialdemocrat wrote: post #65

Earlier quoted context omitted.

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…

With every node shrinkage those legacy instructions take up less space

Encoding space, not die space.

Re: Addressing Criticism of RISC-V Microprocessors

#110

Post by [deleted] »

IshKebab wrote: post #105
monocasa wrote: post #67

Earlier quoted context omitted.

> 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.

Why do you say that? Look here: https://clang.llvm.org/docs/UsersManual.html#x86

[deleted]
Post reply on HN