14 ms·

Addressing Criticism of RISC-V Microprocessors

176 points by nnx 5y ago

TazeTSchnitzel 5y ago
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.
- fay59 5y ago
  All of the ARM assembly is wrong. AArch64 uses “x” or “w” to identify general purpose registers, “r” isn’t a thing.
- solarexplorer 5y ago
  In the same section the part about the SiFive optimization is also misleading. The goal of the optimization is obviously to avoid interrupting the instruction fetch. But he makes it sound like the goal was to reduce instruction count by fusing two instructions to get a single monster op with five (!) register operands. That just doesn't make sense.
  - brucehoult 5y ago
    They don't fuse it. They have the branch and the following instruction both go down one integer pipeline just as they would if the branch was predicted "not taken. They are linked/tagged together such that if the branch actually happens then the result from the second instruction is simply not written back instead of taking a branch mispredict. So the four input operands and one output operand are not a problem because that's just what two pipelines do all the time anyway.
- pxeger1 5y ago
  I thought it was only supposed to be pseudo-assembly?
- znwu 5y ago
  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.
  - snvzz 5y ago
    The actual hardware cost of this case of "macro-op fusion" is negligible.
    - znwu 5y ago
      Yes it is negligible. The problem is that indexed load/store is a non-issue. There are ready-to-use simulation data that shows indexed load/store has minimal impact on dynamic code size.If someone uses an overkill feature to explain a non-issue, then it seems like nonsense. Imaging someone uses quantum gravity to explain why Australians stand upside down on a globe.
      - snvzz 5y ago
        macro-op fusion is not rocket science.
        znwu 5y ago
        Then write up an actually meaningful array processing function and translate it into asm is even less rocket science. The author starts with a apparently meaningless `int x = a[i];`, but did not ask an obvious question before digging in: what usually goes before and after this statement and together what will they produce? A formal RISC-V code analysis usually does not go like this. `int x = a[i];` is the kind of expression that strikes you as useful at the first glance, but then nothing. If you visit an array, then on x64/ARM/RISC-V, they are all compiled down to 2 instructions per iteration. Not 1 vs 2 vs 3 as suggested by the article. RISV-V may have one or two more instructions outside the loop but that's it.
FullyFunctional 5y ago
I'm heavily invested in RISC-V, both personally and professionally, and I think the story is much more complicated than this makes it out to be, but I'm not going to rehash the discussion yet again. However, I do want to point out that a real issue (especially with legacy code) is the scaled address calculation with 32-bit unsigned values. Thankfully the Zba extension adds a number of instructions that help a lot, but still would require fusion to get complete parity with Arm64 For int update(int *base, unsigned index) { return base[index]++; } We get update: sh2add.uw a1,a1,a0 lw a0,0(a1) addiw a5,a0,1 sw a5,0(a1) ret Zba is included in the next Unix profile and will _likely_ be adopted eventually by all serious implementations. EDIT: grammar and spacing
- abainbridge 5y ago
  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 "Output". I have to use GCC instead: RISC-V (no Zba) Clang - 20 bytes - https://godbolt.org/z/eWfPaorcj Arm64 GCC - 24 bytes - https://godbolt.org/z/bzsPzov5h
  - FullyFunctional 5y ago
    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 regular RISC-V). However, calling that a win for Arm64 is not so clear as the more complicated addressing modes could become a critical timing path and/or require an extra pipeline stage. However, as a first approximation, for a superscalar dynamically scheduled implementation, fewer ops is better so I would say it's a slight win. I don't understand the obsession with bytes. 25% fewer bytes has only very marginally impact on a high-performance implementation and the variable length encoding has some horrendous complications (which is probably why Arm64 _dropped_ variable length instructions). Including compressed instruction in the Unix profile was the biggest mistake RISC-V did and I'll die on that hill. ADD: Don't forget that every 32-bit instruction is currently wasting the lower two bits to allow for compressed, thus any gain from compress must be offset by the 6.25% tax that is forced upon it.
throwaway81523 5y ago
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?
- FullyFunctional 5y ago
  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 much so that we have different benchmark suites for each. Integer operations are critically latency sensitive and bagging on extra semantics doesn't come for free and for most code this would be a tax. The "overflow bit" represents an implicit result that would have to be threaded around (I'm assuming that you aren't asking for exceptions which literally nobody wants). For FP we do that, but the cost and latency of FP ops is already high so it doesn't hurt quite as much. The RISC-V spec [1] (which I assume you have seen) already discusses all these trade offs: "We did not include special instruction-set support for overflow checks on integer arithmetic operations in the base instruction set, as many overflow checks can be cheaply implemented using RISC-V branches. Overflow checking for unsigned addition requires only a single additional branch instruction after the addition: add t0, t1, t2 bltu t0, t1, overflow For signed addition, if one operand’s sign is known, overflow checking requires only a single branch after the addition: addi t0, t1, +imm blt t0, t1, overflow This covers the common case of addition with an immediate operand. For general signed addition, three additional instructions after the addition are required, leveraging the observation that the sum should be less than one of the operands if and only if the other operand is negative. add t0, t1, t2 slti t3, t2, 0 slt t4, t0, t1 bne t3, t4, overflow In RV64I, checks of 32-bit signed additions can be optimized further by comparing the results of ADD and ADDW on the operands." I do think that it might have been worth adding an single instruction version for the last one (excluding the branch), but I'm not aware of it getting accepted. [1] https://github.com/riscv/riscv-isa-manual https://github.com/riscv/riscv-isa-manual
VariableStar 5y ago
It is amusing and sobering to get a glimpse of some of the compexities going on inside a processor and how design philosophies may affect them. Those are things the user or even your normal programmer seldom thinks about.
stonogo 5y ago
It doesn't matter how convincing the sales pitch is when the product is not actually for sale. One thing ARM and x86 got right that SPARC and POWER got wrong is widely-available machines available at reasonable prices. All the 'being right' in the world won't help if developers need a five-figure hardware budget to port to your platform. VMs don't cut it for bringup.
- rwmj 5y ago
  There's lots of RISC-V hardware these days, from embedded RV32 chips up to machines you can run Linux on. It's nothing at all like SPARC/POWER.
- johndoe0815 5y ago
  At least PowerPC machines were available for reasonable prices from Apple for about a decade - and Linux was quite well supported in addition to OS X. But with Motorola’s loss of interest in the PC and server market and IBM’s focus on processors for consoles, there was no future for Apple in the growing mobile market. After all, we’re still waiting for the G5 Powerbook :).
- BirAdam 5y ago
  $17 64 bit RISC-V https://linuxgizmos.com/17-sbc-runs-linux-on-allwinner-d1-risc-v-soc/ https://linuxgizmos.com/17-sbc-runs-linux-on-allwinner-d1-ri... $29 64 bit RISC-V in the same form factor as an RPi CM3 https://www.clockworkpi.com/product-page/copy-of-clockworkpi-core-r-01 https://www.clockworkpi.com/product-page/copy-of-clockworkpi... If you never look for it, you will believe it doesn’t exist. I was very skeptical of ARM back in the day thinking that it was great for crappy little iTrinkets and Androids but not for “real computing”. I was clearly wrong. I was very skeptical of RISC-V until I recently heard Jim Keller explain why RISC-V has a bright future. He was rather convincing. This is especially true given his track record of straight-up magical results. Looking at different RISC-V machines, I think that the greatest advantage is that it is simple and can therefore be optimized more easily than complex designs, and due to being open, it has very low cost which will encourage more eyes trying more and different optimizations. EDIT: Link to Jim Keller interview https://www.anandtech.com/show/16762/an-anandtech-interview-with-jim-keller-laziest-person-at-tesla https://www.anandtech.com/show/16762/an-anandtech-interview-...
erosenbe0 5y ago
What are these r registers for AArch64? Author hasn't likely bothered to run any of the examples through an actual 64-bit ARM assembler. Dubious.
dontlaugh 5y ago
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.
- avianes 5y ago
  You are right but RISC-V variable instruction size is indeed a good trade-off. Unlike x86 where instructions can range from 1 up to 15 byte, current RISC-V ISA only has 2 instruction sizes. Today x86 decoding is limiting because we want to decode more than ~4 instructions each cycle, for RISC-V to cause same decoding difficulty it would probably be required to decode more than ~20 instructions each cycle
  - dontlaugh 5y ago
    I don’t know that it’s a good tradeoff. ARM64 has fixed length instructions with decent density and has proven to allow highly parallel decoding.
- audunw 5y ago
  Regular base instructions are always 32-bit, compressed are always 16-bit, and they're always aligned. I don't think there's a problem decoding them in parallel. You always know where the opcodes will be located in a 32-bit word - or set of 32-bit words - you're trying to decode. What I've been wondering is how difficult it is to fuse instructions when the compressed instructions you're trying to fuse isn't aligned to a 32-bit word.
  - renox 5y ago
    > ou always know where the opcodes will be located in a 32-bit word - or set of 32-bit words - you're trying to decode. Uh? In RISC-V with the C extension, 32bit instructions are 16-bits aligned, so no you don't.
- brucehoult 5y ago
  This is really not a big deal with RISC-V's 2 instruction lengths and the encoding they use. If decoding 32 bytes of code (256 bits, somewhere between 8 and 16 instructions) You can figure out where all the actual instructions start (yes, even the 16th instruction) with 2 layers of LUT6. You can then use those outputs to mux two possible starting positions for 8 decoders that do 16 or 32 bit instructions, plus 8 decoders what will only ever do 16 bit instructions from fixed start positions (and might output a NOP or in some other way indicate they don't have an input). OR you can use those outputs to mux the outputs of a 8 decoders that only do 32 bit instructions and 8 decoders that do 16 or 32 (all with fixed starting positions), plus again 8 decoders that only do 16 bit instructions from fixed start positions (possibly not used / NOP). The first option uses less hardware but has higher latency. That, again, is for decoding between 8 and 16 instructions per cycle, with an average on real code of close to 12. That is more than is actually useful on normally branchy code. In short: not a problem. Unlike x86 decoding.
IshKebab 5y ago
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.
- mhh__ 5y ago
  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 off what amd64 originally meant for X86 (e.g. implies SSE2)
  - IshKebab 5y ago
    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 compiled for specific chips. > Secondly, AVX-512 alone has a handful of different extensions. 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.
    - mhh__ 5y ago
      The LLVM tools (like llc) use -mcpu. Clang mimics GCC. My point about the specific chip is that you have to know it anyway if you're planning on targeting a combination of extensions so you might as well use it. As for linearity, the "generally" bit will apply to RISC-V by the time we have real desktop class chips using the ISA. We still can't assume AVX support for most programs, I don't view this as any different to RISC-V extensions. Just this ~year Intel added VEX-coded AI NN acceleration instructions, I assume RISC-V has similar plans.
jfkimmes 5y ago
I get "To keep reading this story, get the free app or log in. (With Facebook or Google)" on mobile. No thanks, Medium. These dark patterns crop up everywhere lately...
- math-dev 5y ago
  That’s a shame…it was the most annoying thing about Quora to me. As a Medium writer, I’m annoyed now! They already stopped paying me my ~0-10$ per month because I refused to beg everyone to get to their new minimum 100 followers requirement for getting paid.
- aw1cks 5y ago
  https://scribe.rip https://scribe.rip
- Eduard 5y ago
  https://archive.is/BqS0n https://archive.is/BqS0n
- throwaway81523 5y ago
  12ft.io got past that for me.
- socialdemocrat 5y ago
  It is for authors like me writing on Medium, to have a way of getting paid. There is a need for both paid and free content. But reality is that you cannot produce quality content if everything has to be free. Advertisement is one solution, but one not without its own serious drawbacks. Medium is a like a magazine with a very large number of journalists which it pays to write for it. Naturally it needs to charge subscribers to make an income.
btdmaster 5y ago
https://scribe.rip/addressing-criticism-of-risc-v-microprocessors-803239b53284 https://scribe.rip/addressing-criticism-of-risc-v-microproce...
mhh__ 5y ago
> Easily out-perform ARM in code density > No data [that I can see at least]
- brucehoult 5y ago
  Some data from Ubuntu 21.10 for amd64, arm64, and riscv64: https://www.reddit.com/r/RISCV/comments/tik718/addressing_criticism_of_riscv_microprocessors/i1fqqxs/ https://www.reddit.com/r/RISCV/comments/tik718/addressing_cr...
ribit 5y ago
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 ARMv7 when ARMv8 has been available for over a decade is... odd. - Regarding SIMD... it's a very complex topic, but personally, I don't see any fundamental problem with vector-style ISA. I think it's a great way of allowing scalable software. But vector ISA does not replace basic SIMD as they solve different problems. Vector stuff is great for throughput, SIMD is great for latency. There are many tasks such as geometry processing, modern data structures etc. where fixed-size 128-bit SIMD is an excellent building block. That's why ARM has both NEON and SVE2, the latter does not make obsolete the former. And that bit about GPUs and how they are not good for vector processing... not even sure how to comment on it. Also, at the end of the day, specialised devices will vastly outperform any general-purpose CPU solution. That's why we see, say, Apple M1 matrix accelerators delivering matmul performance on par with workstation CPU solutions, despite using a fraction of power. Overall, my impression is that the article is grasping at straws, ignores modern technology and ultimately fails to deliver. I aolso remain unconvinced by the initial premise that RISC-V follows the principle "not painting yourself into a corner due to choices which have short term benefit". I do think that choices like keeping instructions as simple as possible (even though it makes expression of common patterns verbose), avoiding flags registers, disregarding SIMD etc. could be characterised as "painting oneself into a corner". A usual disclaimer: I do think that RISC-V is a great architecture for many domains. Simple low-power/low-cost controllers, specialised hardware, maybe even GPUs (with extensions) — the simplicity and openness of RISC-V makes it a great point of entry for basically anyone and invites experimentation. I just don't see much merit of RISC-V in the general-purpose high-performance consumer computing (laptop/desktop). In this space RISC-V does not have any notable advantages, it does have potential disadvantages (e.g. code density and lack of standard SIMD — yet). Most importantly, the CPU microarchitecture becomes the decisive factor, and designing a fast general-purpose CPU requires a lot of expertise and resources. It's not something that a small group of motivated folk can realistically pull off. So all the great things about RISC-V simply do not apply here.
- 5y ago
devit 5y ago
I think the biggest issue is the lack of arithmetic with overflow checking, especially with a variant that calls a location in a control register on overflow. This makes it very inefficient to compile languages that would like overflow checks on all arithmetic.
- audunw 5y ago
  A comment elsewhere here pointed out that RISC-V can do it with two fused compressed instructions for the most common operations. So seems like they did the right trade off to me.
KSPAtlas 5y ago
I am personally a fan of RISC-V, and I have written low level code for it before.
brucehoult 5y ago
I am so bored with people criticising RISC-V based on tiny code snippets of things that basically never happen in real code. A function that does nothing but return an array element from an array base address and index passed to it? Really? Do you actually write junk like that? And if you write it does your compiler really not inline it? Why? Do you like big slow code? Once it's inlined, it's probably in a loop, and strength-reduced. It's very easy to verify that in the real-world RISC-V code is more compact than amd64 and arm64. Just download the same version of Ubuntu or Fedora (etc) for each one and run the "size" command on the binaries. The RISC-V ones are consistently significantly smaller. You can also, with quite a bit more work, count the number of µops each ISA executes. RISC-V executes slightly more instructions, but they are each simple and don't need expanding. Lots of x86 instructions get expanded into multiple µops and many 64 bit ARM instructions do too. In the end the number of µops executed by each is very similar. Trying to judge the goodness of a modern ISA by looking at two or three instruction snippets is as silly as using Dhrystone as your only benchmark program.
audunw 5y ago
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 if I've understood correctly) I'm sure there are some bad decisions in RISC-V, but I've yet to see one that isn't in the process of being remedied. There was a good argument for a lack of POPCOUNT instruction being bad, but I think that's being added soon
- okl 5y ago
  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.
  - __s 5y ago
    You shouldn't assess RISC-V from the viewpoint of a single chip. It's an ISA first. Branch slots are highly target specific
  - mst 5y ago
    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)
albanread 5y ago
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 free design and share the cost of compiler development. Is there really anything else?
- monocasa 5y ago
  > 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.
- kortex 5y ago
  Yeah, absolutely. Personally, when I zoom out, and look at the trends of engineering in general: simpler modular systems that compose well together vs bespoke solutions, RISC-V precisely follows the trend. Reduce global state. Make it easier (for humans and algos) to reason about control flow. Have a simple core with optional extensions. This all makes building multi-core solutions way simpler. We are fast running out of transistor density improvements. But we are getting way better at building coprocessors. There's clear value in "doing more simple things in parallel".
- socialdemocrat 5y ago
  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.
sylware 5y ago
RISC-V is technically not bad enough to select arm64 or x86_64 over it, since those have beyond toxic IP tied to them. From what I read in the comments, I don't expect compressed instructions on future high performance desktop/servers RISC-V CPU cores to be there.
panick21_ 5y ago
People over argue these minimal difference. Lets be honest, never in the history of ISA were these things the primary reason for success or failure of instruction sets been a slightly better code size. Even if by <insert objective measurement> RISC-V is 10% worse then ARM, it wouldn't actually matter that much for adoption. Adoption happens for business reasons and what is differentiating RISC-V far more then anything else is the chance in license, governance and ecosystem. RISC-V being better at hitting different verticals optimally because of the molecularity is likely another thing that matters more overall then how perfectly it fits for each vertical.
- wmf 5y ago
  Agreed, but I think the purpose of these kind of criticisms is to "fix" RISC-V before it becomes yet another worse-is-better design locked in for 50 years.
  - socialdemocrat 5y ago
    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 anything the problem is nearly always about having to support old junk which no longer makes sense to support, or lacking the ability to grow. Remember 640K is enough for everyone? RISC-V has a lot of room to grow. If you want an architecture for the future you would want a minimalist one with room to grow a lot. By keeping the instruction count very low and building in a system for extensions they have made a future proof ISA. Okay we cannot know the future, but it is more likely to survive for decades than something like x86 or maybe even ARM.
    - wmf 5y ago
      Most of the complaints about RISC-V are extremely basic things like array indexing and conditional execution. These will never not be needed.
zozbot234 5y ago
> Every 32-bit word in the instruction cache will contain either a 32-bit uncompressed instruction or two 16-bit compressed instructions. Thus everything lines up nicely. This is not really accurate AIUI, since the RISC-V C extension allows 32-bit insns to be 16-bit aligned. (This would also happen if 48-bit insns were enabled by some other future extension). It's nonetheless a lot simpler than whatever x86 has to do, since insn length is given by a few well-defined bits in the insn word.
jhgb 5y ago
> In RISC-V the equivalent would require a whole 3 different instructions I'm surprised that it wasn't pointed out that this should probably be eliminated by a compiler transformation. Rather than loading from r0+r1<<2 and incrementing r1 by one every loop iteration, surely it might be possible to load from just r0 and increment it by 4 every loop iteration?
- avianes 5y ago
  We don't need indexed loads only for loops. But even within loops, you may need indexed load. One simple example: when you do loop unrolling, you must access elements n+4, n+8 and n+12 etc.
  - jhgb 5y ago
    True, there are other uses. However some people seem to be pointing out that on average, the RISC-V code is still smaller on average. As for unrolling, isn't this a job for RV64V?

176 points by nnx 5y ago

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.

fay59 5y ago
All of the ARM assembly is wrong. AArch64 uses “x” or “w” to identify general purpose registers, “r” isn’t a thing.
solarexplorer 5y ago
In the same section the part about the SiFive optimization is also misleading. The goal of the optimization is obviously to avoid interrupting the instruction fetch. But he makes it sound like the goal was to reduce instruction count by fusing two instructions to get a single monster op with five (!) register operands. That just doesn't make sense.
- brucehoult 5y ago
  They don't fuse it. They have the branch and the following instruction both go down one integer pipeline just as they would if the branch was predicted "not taken. They are linked/tagged together such that if the branch actually happens then the result from the second instruction is simply not written back instead of taking a branch mispredict. So the four input operands and one output operand are not a problem because that's just what two pipelines do all the time anyway.
pxeger1 5y ago
I thought it was only supposed to be pseudo-assembly?
znwu 5y ago
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.
- snvzz 5y ago
  The actual hardware cost of this case of "macro-op fusion" is negligible.
  - znwu 5y ago
    Yes it is negligible. The problem is that indexed load/store is a non-issue. There are ready-to-use simulation data that shows indexed load/store has minimal impact on dynamic code size.If someone uses an overkill feature to explain a non-issue, then it seems like nonsense. Imaging someone uses quantum gravity to explain why Australians stand upside down on a globe.
    - snvzz 5y ago
      macro-op fusion is not rocket science.
      - znwu 5y ago
        Then write up an actually meaningful array processing function and translate it into asm is even less rocket science. The author starts with a apparently meaningless `int x = a[i];`, but did not ask an obvious question before digging in: what usually goes before and after this statement and together what will they produce? A formal RISC-V code analysis usually does not go like this. `int x = a[i];` is the kind of expression that strikes you as useful at the first glance, but then nothing. If you visit an array, then on x64/ARM/RISC-V, they are all compiled down to 2 instructions per iteration. Not 1 vs 2 vs 3 as suggested by the article. RISV-V may have one or two more instructions outside the loop but that's it.

FullyFunctional 5y ago

I'm heavily invested in RISC-V, both personally and professionally, and I think the story is much more complicated than this makes it out to be, but I'm not going to rehash the discussion yet again. However, I do want to point out that a real issue (especially with legacy code) is the scaled address calculation with 32-bit unsigned values. Thankfully the Zba extension adds a number of instructions that help a lot, but still would require fusion to get complete parity with Arm64 For int update(int *base, unsigned index) { return base[index]++; } We get update: sh2add.uw a1,a1,a0 lw a0,0(a1) addiw a5,a0,1 sw a5,0(a1) ret Zba is included in the next Unix profile and will _likely_ be adopted eventually by all serious implementations. EDIT: grammar and spacing

abainbridge 5y ago
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 "Output". I have to use GCC instead: RISC-V (no Zba) Clang - 20 bytes - https://godbolt.org/z/eWfPaorcj Arm64 GCC - 24 bytes - https://godbolt.org/z/bzsPzov5h
- FullyFunctional 5y ago
  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 regular RISC-V). However, calling that a win for Arm64 is not so clear as the more complicated addressing modes could become a critical timing path and/or require an extra pipeline stage. However, as a first approximation, for a superscalar dynamically scheduled implementation, fewer ops is better so I would say it's a slight win. I don't understand the obsession with bytes. 25% fewer bytes has only very marginally impact on a high-performance implementation and the variable length encoding has some horrendous complications (which is probably why Arm64 _dropped_ variable length instructions). Including compressed instruction in the Unix profile was the biggest mistake RISC-V did and I'll die on that hill. ADD: Don't forget that every 32-bit instruction is currently wasting the lower two bits to allow for compressed, thus any gain from compress must be offset by the 6.25% tax that is forced upon it.

throwaway81523 5y ago

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?

FullyFunctional 5y ago
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 much so that we have different benchmark suites for each. Integer operations are critically latency sensitive and bagging on extra semantics doesn't come for free and for most code this would be a tax. The "overflow bit" represents an implicit result that would have to be threaded around (I'm assuming that you aren't asking for exceptions which literally nobody wants). For FP we do that, but the cost and latency of FP ops is already high so it doesn't hurt quite as much. The RISC-V spec [1] (which I assume you have seen) already discusses all these trade offs: "We did not include special instruction-set support for overflow checks on integer arithmetic operations in the base instruction set, as many overflow checks can be cheaply implemented using RISC-V branches. Overflow checking for unsigned addition requires only a single additional branch instruction after the addition: add t0, t1, t2 bltu t0, t1, overflow For signed addition, if one operand’s sign is known, overflow checking requires only a single branch after the addition: addi t0, t1, +imm blt t0, t1, overflow This covers the common case of addition with an immediate operand. For general signed addition, three additional instructions after the addition are required, leveraging the observation that the sum should be less than one of the operands if and only if the other operand is negative. add t0, t1, t2 slti t3, t2, 0 slt t4, t0, t1 bne t3, t4, overflow In RV64I, checks of 32-bit signed additions can be optimized further by comparing the results of ADD and ADDW on the operands." I do think that it might have been worth adding an single instruction version for the last one (excluding the branch), but I'm not aware of it getting accepted. [1] https://github.com/riscv/riscv-isa-manual https://github.com/riscv/riscv-isa-manual

VariableStar 5y ago

It is amusing and sobering to get a glimpse of some of the compexities going on inside a processor and how design philosophies may affect them. Those are things the user or even your normal programmer seldom thinks about.

stonogo 5y ago

It doesn't matter how convincing the sales pitch is when the product is not actually for sale. One thing ARM and x86 got right that SPARC and POWER got wrong is widely-available machines available at reasonable prices. All the 'being right' in the world won't help if developers need a five-figure hardware budget to port to your platform. VMs don't cut it for bringup.

rwmj 5y ago
There's lots of RISC-V hardware these days, from embedded RV32 chips up to machines you can run Linux on. It's nothing at all like SPARC/POWER.
johndoe0815 5y ago
At least PowerPC machines were available for reasonable prices from Apple for about a decade - and Linux was quite well supported in addition to OS X. But with Motorola’s loss of interest in the PC and server market and IBM’s focus on processors for consoles, there was no future for Apple in the growing mobile market. After all, we’re still waiting for the G5 Powerbook :).
BirAdam 5y ago
$17 64 bit RISC-V https://linuxgizmos.com/17-sbc-runs-linux-on-allwinner-d1-risc-v-soc/ https://linuxgizmos.com/17-sbc-runs-linux-on-allwinner-d1-ri... $29 64 bit RISC-V in the same form factor as an RPi CM3 https://www.clockworkpi.com/product-page/copy-of-clockworkpi-core-r-01 https://www.clockworkpi.com/product-page/copy-of-clockworkpi... If you never look for it, you will believe it doesn’t exist. I was very skeptical of ARM back in the day thinking that it was great for crappy little iTrinkets and Androids but not for “real computing”. I was clearly wrong. I was very skeptical of RISC-V until I recently heard Jim Keller explain why RISC-V has a bright future. He was rather convincing. This is especially true given his track record of straight-up magical results. Looking at different RISC-V machines, I think that the greatest advantage is that it is simple and can therefore be optimized more easily than complex designs, and due to being open, it has very low cost which will encourage more eyes trying more and different optimizations. EDIT: Link to Jim Keller interview https://www.anandtech.com/show/16762/an-anandtech-interview-with-jim-keller-laziest-person-at-tesla https://www.anandtech.com/show/16762/an-anandtech-interview-...

erosenbe0 5y ago

What are these r registers for AArch64? Author hasn't likely bothered to run any of the examples through an actual 64-bit ARM assembler. Dubious.

dontlaugh 5y ago

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.

avianes 5y ago
You are right but RISC-V variable instruction size is indeed a good trade-off. Unlike x86 where instructions can range from 1 up to 15 byte, current RISC-V ISA only has 2 instruction sizes. Today x86 decoding is limiting because we want to decode more than ~4 instructions each cycle, for RISC-V to cause same decoding difficulty it would probably be required to decode more than ~20 instructions each cycle
- dontlaugh 5y ago
  I don’t know that it’s a good tradeoff. ARM64 has fixed length instructions with decent density and has proven to allow highly parallel decoding.
audunw 5y ago
Regular base instructions are always 32-bit, compressed are always 16-bit, and they're always aligned. I don't think there's a problem decoding them in parallel. You always know where the opcodes will be located in a 32-bit word - or set of 32-bit words - you're trying to decode. What I've been wondering is how difficult it is to fuse instructions when the compressed instructions you're trying to fuse isn't aligned to a 32-bit word.
- renox 5y ago
  > ou always know where the opcodes will be located in a 32-bit word - or set of 32-bit words - you're trying to decode. Uh? In RISC-V with the C extension, 32bit instructions are 16-bits aligned, so no you don't.
brucehoult 5y ago
This is really not a big deal with RISC-V's 2 instruction lengths and the encoding they use. If decoding 32 bytes of code (256 bits, somewhere between 8 and 16 instructions) You can figure out where all the actual instructions start (yes, even the 16th instruction) with 2 layers of LUT6. You can then use those outputs to mux two possible starting positions for 8 decoders that do 16 or 32 bit instructions, plus 8 decoders what will only ever do 16 bit instructions from fixed start positions (and might output a NOP or in some other way indicate they don't have an input). OR you can use those outputs to mux the outputs of a 8 decoders that only do 32 bit instructions and 8 decoders that do 16 or 32 (all with fixed starting positions), plus again 8 decoders that only do 16 bit instructions from fixed start positions (possibly not used / NOP). The first option uses less hardware but has higher latency. That, again, is for decoding between 8 and 16 instructions per cycle, with an average on real code of close to 12. That is more than is actually useful on normally branchy code. In short: not a problem. Unlike x86 decoding.

IshKebab 5y ago

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.

mhh__ 5y ago
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 off what amd64 originally meant for X86 (e.g. implies SSE2)
- IshKebab 5y ago
  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 compiled for specific chips. > Secondly, AVX-512 alone has a handful of different extensions. 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.
  - mhh__ 5y ago
    The LLVM tools (like llc) use -mcpu. Clang mimics GCC. My point about the specific chip is that you have to know it anyway if you're planning on targeting a combination of extensions so you might as well use it. As for linearity, the "generally" bit will apply to RISC-V by the time we have real desktop class chips using the ISA. We still can't assume AVX support for most programs, I don't view this as any different to RISC-V extensions. Just this ~year Intel added VEX-coded AI NN acceleration instructions, I assume RISC-V has similar plans.

jfkimmes 5y ago

I get "To keep reading this story, get the free app or log in. (With Facebook or Google)" on mobile. No thanks, Medium. These dark patterns crop up everywhere lately...

math-dev 5y ago
That’s a shame…it was the most annoying thing about Quora to me. As a Medium writer, I’m annoyed now! They already stopped paying me my ~0-10$ per month because I refused to beg everyone to get to their new minimum 100 followers requirement for getting paid.
aw1cks 5y ago
https://scribe.rip https://scribe.rip
Eduard 5y ago
https://archive.is/BqS0n https://archive.is/BqS0n
throwaway81523 5y ago
12ft.io got past that for me.
socialdemocrat 5y ago
It is for authors like me writing on Medium, to have a way of getting paid. There is a need for both paid and free content. But reality is that you cannot produce quality content if everything has to be free. Advertisement is one solution, but one not without its own serious drawbacks. Medium is a like a magazine with a very large number of journalists which it pays to write for it. Naturally it needs to charge subscribers to make an income.

btdmaster 5y ago

https://scribe.rip/addressing-criticism-of-risc-v-microprocessors-803239b53284 https://scribe.rip/addressing-criticism-of-risc-v-microproce...

mhh__ 5y ago

> Easily out-perform ARM in code density > No data [that I can see at least]

brucehoult 5y ago
Some data from Ubuntu 21.10 for amd64, arm64, and riscv64: https://www.reddit.com/r/RISCV/comments/tik718/addressing_criticism_of_riscv_microprocessors/i1fqqxs/ https://www.reddit.com/r/RISCV/comments/tik718/addressing_cr...

ribit 5y ago

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 ARMv7 when ARMv8 has been available for over a decade is... odd. - Regarding SIMD... it's a very complex topic, but personally, I don't see any fundamental problem with vector-style ISA. I think it's a great way of allowing scalable software. But vector ISA does not replace basic SIMD as they solve different problems. Vector stuff is great for throughput, SIMD is great for latency. There are many tasks such as geometry processing, modern data structures etc. where fixed-size 128-bit SIMD is an excellent building block. That's why ARM has both NEON and SVE2, the latter does not make obsolete the former. And that bit about GPUs and how they are not good for vector processing... not even sure how to comment on it. Also, at the end of the day, specialised devices will vastly outperform any general-purpose CPU solution. That's why we see, say, Apple M1 matrix accelerators delivering matmul performance on par with workstation CPU solutions, despite using a fraction of power. Overall, my impression is that the article is grasping at straws, ignores modern technology and ultimately fails to deliver. I aolso remain unconvinced by the initial premise that RISC-V follows the principle "not painting yourself into a corner due to choices which have short term benefit". I do think that choices like keeping instructions as simple as possible (even though it makes expression of common patterns verbose), avoiding flags registers, disregarding SIMD etc. could be characterised as "painting oneself into a corner". A usual disclaimer: I do think that RISC-V is a great architecture for many domains. Simple low-power/low-cost controllers, specialised hardware, maybe even GPUs (with extensions) — the simplicity and openness of RISC-V makes it a great point of entry for basically anyone and invites experimentation. I just don't see much merit of RISC-V in the general-purpose high-performance consumer computing (laptop/desktop). In this space RISC-V does not have any notable advantages, it does have potential disadvantages (e.g. code density and lack of standard SIMD — yet). Most importantly, the CPU microarchitecture becomes the decisive factor, and designing a fast general-purpose CPU requires a lot of expertise and resources. It's not something that a small group of motivated folk can realistically pull off. So all the great things about RISC-V simply do not apply here.

5y ago

devit 5y ago

I think the biggest issue is the lack of arithmetic with overflow checking, especially with a variant that calls a location in a control register on overflow. This makes it very inefficient to compile languages that would like overflow checks on all arithmetic.

audunw 5y ago
A comment elsewhere here pointed out that RISC-V can do it with two fused compressed instructions for the most common operations. So seems like they did the right trade off to me.

KSPAtlas 5y ago

I am personally a fan of RISC-V, and I have written low level code for it before.

brucehoult 5y ago

I am so bored with people criticising RISC-V based on tiny code snippets of things that basically never happen in real code. A function that does nothing but return an array element from an array base address and index passed to it? Really? Do you actually write junk like that? And if you write it does your compiler really not inline it? Why? Do you like big slow code? Once it's inlined, it's probably in a loop, and strength-reduced. It's very easy to verify that in the real-world RISC-V code is more compact than amd64 and arm64. Just download the same version of Ubuntu or Fedora (etc) for each one and run the "size" command on the binaries. The RISC-V ones are consistently significantly smaller. You can also, with quite a bit more work, count the number of µops each ISA executes. RISC-V executes slightly more instructions, but they are each simple and don't need expanding. Lots of x86 instructions get expanded into multiple µops and many 64 bit ARM instructions do too. In the end the number of µops executed by each is very similar. Trying to judge the goodness of a modern ISA by looking at two or three instruction snippets is as silly as using Dhrystone as your only benchmark program.

audunw 5y ago

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 if I've understood correctly) I'm sure there are some bad decisions in RISC-V, but I've yet to see one that isn't in the process of being remedied. There was a good argument for a lack of POPCOUNT instruction being bad, but I think that's being added soon

okl 5y ago
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.
- __s 5y ago
  You shouldn't assess RISC-V from the viewpoint of a single chip. It's an ISA first. Branch slots are highly target specific
- mst 5y ago
  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)

albanread 5y ago

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 free design and share the cost of compiler development. Is there really anything else?

monocasa 5y ago
> 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.
kortex 5y ago
Yeah, absolutely. Personally, when I zoom out, and look at the trends of engineering in general: simpler modular systems that compose well together vs bespoke solutions, RISC-V precisely follows the trend. Reduce global state. Make it easier (for humans and algos) to reason about control flow. Have a simple core with optional extensions. This all makes building multi-core solutions way simpler. We are fast running out of transistor density improvements. But we are getting way better at building coprocessors. There's clear value in "doing more simple things in parallel".
socialdemocrat 5y ago
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.

sylware 5y ago

RISC-V is technically not bad enough to select arm64 or x86_64 over it, since those have beyond toxic IP tied to them. From what I read in the comments, I don't expect compressed instructions on future high performance desktop/servers RISC-V CPU cores to be there.

panick21_ 5y ago

People over argue these minimal difference. Lets be honest, never in the history of ISA were these things the primary reason for success or failure of instruction sets been a slightly better code size. Even if by <insert objective measurement> RISC-V is 10% worse then ARM, it wouldn't actually matter that much for adoption. Adoption happens for business reasons and what is differentiating RISC-V far more then anything else is the chance in license, governance and ecosystem. RISC-V being better at hitting different verticals optimally because of the molecularity is likely another thing that matters more overall then how perfectly it fits for each vertical.

wmf 5y ago
Agreed, but I think the purpose of these kind of criticisms is to "fix" RISC-V before it becomes yet another worse-is-better design locked in for 50 years.
- socialdemocrat 5y ago
  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 anything the problem is nearly always about having to support old junk which no longer makes sense to support, or lacking the ability to grow. Remember 640K is enough for everyone? RISC-V has a lot of room to grow. If you want an architecture for the future you would want a minimalist one with room to grow a lot. By keeping the instruction count very low and building in a system for extensions they have made a future proof ISA. Okay we cannot know the future, but it is more likely to survive for decades than something like x86 or maybe even ARM.
  - wmf 5y ago
    Most of the complaints about RISC-V are extremely basic things like array indexing and conditional execution. These will never not be needed.

zozbot234 5y ago

> Every 32-bit word in the instruction cache will contain either a 32-bit uncompressed instruction or two 16-bit compressed instructions. Thus everything lines up nicely. This is not really accurate AIUI, since the RISC-V C extension allows 32-bit insns to be 16-bit aligned. (This would also happen if 48-bit insns were enabled by some other future extension). It's nonetheless a lot simpler than whatever x86 has to do, since insn length is given by a few well-defined bits in the insn word.

jhgb 5y ago

> In RISC-V the equivalent would require a whole 3 different instructions I'm surprised that it wasn't pointed out that this should probably be eliminated by a compiler transformation. Rather than loading from r0+r1<<2 and incrementing r1 by one every loop iteration, surely it might be possible to load from just r0 and increment it by 4 every loop iteration?

avianes 5y ago
We don't need indexed loads only for loops. But even within loops, you may need indexed load. One simple example: when you do loop unrolling, you must access elements n+4, n+8 and n+12 etc.
- jhgb 5y ago
  True, there are other uses. However some people seem to be pointing out that on average, the RISC-V code is still smaller on average. As for unrolling, isn't this a job for RV64V?