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

121–130 of 149 posts

Re: Addressing Criticism of RISC-V Microprocessors

#121

Post by socialdemocrat »

wmanley wrote: post #100
zozbot234 wrote: post #93

Earlier quoted context omitted.

The only part of RISC-V that is "locked in" to any extent is the minimal set of basic integer instructions. Everything else is defined as part of standardized extensions, and can be superseded simply by defining new custom extensions. Actually even the minimal instruction set admits of some variation, such as the 'E' architectures that dispense with registers R16 to R31, thus saving area in the smallest implementatio…

Things get locked in not by standards, but by usage. If your software depends on particular instructions being present you’re not going to buy a processor that has superseded those instructions, even if the new instructions conform to a theoretically cleaner design. Everything being an extension (and thus removable) is a strength in some specific circumstances, but is a weakness in most.

That doesn't make any sense. Because RISC-V has kept instructions to such a bare minimum, there will be very little you will be dependent on and which new designs have to take into account. What you describe is a problem for x86 and ARM not for RISC-V. You got it all in reverse.

General-purpose CPUs for desktop computers and such will not be willy nilly adding extensions. They will standardize on something like RV64GC. However for specialized hardware which you only ever deal with through drivers, nobody will care whether extensions come and go. Are you worried that the processor in your keyboard or mouse isn't backwards compatible with the processor you used in your previous mouse or keyboard?

Anyway code today can already check what extensions you have and generate different code paths. You can ship operating systems which have fallback code for most extensions so they can be be removed in the future. You also got traps so RISC-V can jump to a software implementation of unsupported instructions.

Re: Addressing Criticism of RISC-V Microprocessors

#122

Post by socialdemocrat »

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…

I loved the 68k. It was what got me started with Assembly. But one of the key reasons I have an interest in RISC-V today is for its educational potential. I know how x86 killed my interest in assembly coding. ARM honestly isn't all that much better.

RISC-V gives people a way to learn and understand what a modern CPU is like. Remember Donald Knuth's books. He teaches algorithms on an imaginary CPU. As CISC architecture got superseded by RISC, he started using an imaginary RISC CPU in teaching.

His point is that people implementing stuff need to have some sense of how the hardware works to understand tradeoffs. RISC-V is in my view a great CPU arch to give that kind of understanding for somebody who is not necessarily interested in writing assemblers, compilers or what not.

Beyond that RISC-V really fits well with the heterogenous computing trend we are moving towards where specialized hardware is increasingly doing more and more of our tasks. I would say it is and advantage that these different specialized chips have some commonality between them. RISC-V is giving people a way of creating a whole ecosystem of chips for a variety of purpose which share a lot of instructions, debuggers, profilers, compilers and other tools.

There is no way x86 could be part of that revolution. x86 is stuck as a general purpose CPU. RISC-V on the other hand will power desktop computers, smart phones, micro-controllers, AI accelerator cards, super-computers and just about anything.

Re: Addressing Criticism of RISC-V Microprocessors

#123

Post by throwaway81523 »

zozbot234 wrote: post #82
adrian_b wrote: post #17

Earlier quoted context omitted.

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 typical overhead of overflow checking in compiled languages (which, as a reminder, is in the low single-digit %'s at most ) has nothing to do with the lack of hardware-sprcific extensions. It's a consistent pattern of missing optimization opportunities, because the compiler now needs to preserve the exact state of intermediate results after some operation fails with an overflow. Adding these new opcodes to your p…

I don't understand what you are saying with this comment. Every general purpose ISA that I know of other than Risc-V has a means of detecting overflow, such as a carry bit that you can branch on, and usually an ADDC instruction. Risc-V decided to have no method at all, other than expanding 1 instruction to 4 instructions. Integer overflow in C is undefined behaviour and we get a lot of CVE's from overflow bugs because of that. Ideally there should be a (hardware or software) overflow trap, as safer compiled languages like Ada require. Dynamic languages with bignums are another matter, though the instruction mix is likely a lot different.

Re: Addressing Criticism of RISC-V Microprocessors

#124

Post by znwu »

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.

Yes, the author's defence for Myth #1 does not strike me as a correct defence from the RISC-V perspective. Going to compressed instruction and compressed macro-op fusion is way overkill for the very basic indexed load/store problem.

Re: Addressing Criticism of RISC-V Microprocessors

#125

Post by zik »

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.

The problem is that those criticisms are almost always wrong. For instance the ARM proponents criticise RISC-V for having long instruction encodings and then they quote a few carefully cherry picked examples. But if you look at actual compiled programs RISC-V is nearly always 10-15% smaller than ARM.

Re: Addressing Criticism of RISC-V Microprocessors

#126

Post by zik »

dontlaugh wrote: post #23

It’s nice to have an open ISA, don’t get me wrong. However, trade offs matter. Compressing instructions may improve density, but it makes them variable length. This is a big barrier to decoding in parallel, which is very important to high performance cores.

I've implemented RISC-V in verilog for fun and it has a parallel decoder. The ISA's cleverly designed to make it pretty easy. Honestly it was no big deal.

Re: Addressing Criticism of RISC-V Microprocessors

#127

Post by snvzz »

klelatti wrote: post #97
zozbot234 wrote: post #94

Earlier quoted context omitted.

Because the fastest cache levels are tiny, even in the largest and most advanced CPU's. There's plenty of evidence for the performance benefits of improved density and terseness in both code and data.

The M1 has a 192k instruction cache for performance cores which is not ‘tiny’. If there is lots of evidence for the performance benefits of improved density vs the alternative of fixed instruction width in real world CPUs then I’m sure you’ll be able to cite it.

>The M1 has a 192k instruction cache for performance cores which is not ‘tiny’.

ARMv8 and ARMv9 have poor code density. These cache are large as a workaround to that.

This isn't free, as besides making the die larger (and thus lower yields), the L1's clock speed is limited due to its size.

Re: Addressing Criticism of RISC-V Microprocessors

#128

Post by snvzz »

znwu wrote: post #124
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.

Yes, the author's defence for Myth #1 does not strike me as a correct defence from the RISC-V perspective. Going to compressed instruction and compressed macro-op fusion is way overkill for the very basic indexed load/store problem.

The actual hardware cost of this case of "macro-op fusion" is negligible.

Re: Addressing Criticism of RISC-V Microprocessors

#130

Post by ncmncm »

ajb wrote: post #32
adrian_b wrote: post #17

Earlier quoted context omitted.

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

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

This is an old myth, endlessly parroted. On current x86, the status register is renamed just like other registers, as could easily have been done in a better RISC-V design. Lack of status flags will be RISC-V's equivalent of delay slots, that once felt like an optimization but has already aged badly.

The unreliable presence of POPCNT and ROT instructions was a worse failing, apparently mitigated lately.

Post reply on HN