31–40 of 80 posts
Excellent find, an academic paper announcing the book is here https://peer.asee.org/57147.pdf Harris and Harris (no relation) have an excellent book on digital design using RISC-V as the domain problem, https://pages.hmc.edu/harris/ddca/ddcarv.html https://pages.hmc.edu/harris/ddca/ Their books are perfect , and I hope this textbook gets adopted by thousands of colleges. Our RISC-V future is bright, now we need one o…
Earlier quoted context omitted.
I've read that rationale, and it's, well, I'm not going to say it's lying , but it's insincere . By the time it was written, they already settled on 16-bit alignment, and fetching (and then decoding) 16-bit aligned 32-bit instructions is either inefficient, or hard, or requires extra circuitry (or an instruction cache).
High performance RISC-V chips exist from Rivos, Ventana and others, and high performance variable length chips also exist in general (AMD, Intel). So in actual reality it increases complexity somewhat, but is not a problem.
And round and around this discussion goes... Apparently, RISC-V has no downsides at any end of the price spectrum, what a marvelous ISA.
Earlier quoted context omitted.
> Requiring C (compressed) is necessary to avoid splitting the Linux ecosystem. Chips lacking C would never be able to run binaries compiled with C. Yes that's precisely the point of excluding it from the RVA profiles. It would mean that Linux distros don't compile code with C enabled, so chips are free to not support C and therefore can achieve higher performance (probably). And it opens 3/4 of the instruction encod…
Compressed is necessary to reduce code size which is important for performance. A bunch of vendors have done high performance server chips which support compressed (Rivos, Ventana, some Chinese vendors), so in actual reality this was only a problem for Qualcomm. And that's only because Qualcomm bought Nuvia and they wanted to do the cheap thing (minimally change the front end) rather than the right thing.
But it's definitely more awkward and has costs throughout the CPU.
I would be really surprised if the lower code density is worse than the improvement due to everything being nicely aligned. Especially because Qualcomm had actual data that it isn't (if you add new instructions with the extra coding space you free up).
Earlier quoted context omitted.
I broadly agree with your points except one. Requiring C (compressed) is necessary to avoid splitting the Linux ecosystem. Chips lacking C would never be able to run binaries compiled with C. There's no practical way for such binaries to detect this and work around it at runtime as they can with other extensions. And emulation would be super-slow given a large proportion of instructions are compressed. Also the excus…
> RISC-V supports variable length instructions, even much longer than 32 bits, and you've just got to deal with it. ...no, not really? There is nothing like 9 byte-long MOVABS instruction of x64 that exists on RISC-V. The main difficulty in decoding is that 32-bit instructions are not required to be 4-byte aligned, this means that naïve decoders will spend 2 cycles fetching such split instructions. It's possible to a…
For high performance implementations both decoding variable length instructions and decoding/cracking fixed-length instructions into uops, are rather analogous in terms of the work hardware needs to do.
However, I think the advantage of fixed-length instructions, is that you can do further tricks, like pre-decoding in Icache. With RVC, you can also do pre-decoding, but now you need twice the amount of pre-decoding data, unless you find other tricks.
Still, in a reasonable variable-length ISA and fixed-length ISA, the variable-length one will get better code size. There are also a lot of other things to consider, RVC is self synchronizing, cracking is challenging for decode, but also keeps the backend better fed, how more instruction starts impact branch predictors, instructions crossing cache-lines...
I benchmark compiling programs with a rva23 clang build and clang compiled for rva23-without-C and got a 10% performance improvement from RVC on the SpacemiT X100. The X100 is a 4-wide out-of-order core and afaik doesn't do anything special for RVC, except for expanding the 16-bit to 32-bit instructions.
It's hard to quantify the real impact on a CPU design, but going the fixed-width route seems to enable more optimizations (not so much the decoding it self).
Everything RISC-V is good (even the mistakes which is making it more robust and more mature).
I like RISC-V (it's been my job for the last 7 years) but this is nonsense. Not everything RISC-V is good. CLIC was awful (thankfully it has been abandoned). The spec is not especially well written - the style is inconsistent due to being written by many authors, and it is waaaay too much of a textbook rather than a proper spec. (There is some ongoing work to improve this tbf.) There's a practically unending list of…
I code RISC-V assembly, I don't use C machine instructions (I don't even use the pseudo-instructions, ABI register names and dodge nearly all ISA extensions, I try to stick to core as much as I can). I run my code on x86_64 linux with a small interpreter written in x86_64 assembly (thx to the 'R' in RISC).
I wonder if there are some 'broad and not niche, real-life' speed benchmark numbers to show how much C machine instructions are worth.
For the moment, I see those C machine instructions more as a marketing extension to match their arm equivalent: you know, for those key deciding people who care more about the amount of features and not their contextual pertinent usage.
To say an ISA is "good" is related to some set of technical sweet spots based on compromises based on projected usages.
RVA from my point of view is mostly preparing RISC-V hardware for some level of x86_64/arm compatibility.
I wonder if there are RISC-V implementations using the latest silicon process from TSMC.
Earlier quoted context omitted.
High performance RISC-V chips exist from Rivos, Ventana and others, and high performance variable length chips also exist in general (AMD, Intel). So in actual reality it increases complexity somewhat, but is not a problem.
sighs This kind of discussion is so annoying... I start with "RISC-V's decision to make 32-bit instructions only 16-bit aligned complicates instruction fetch and decoding", and the response is "For high performance RISC-V implementations, it's a trivial matter" (which is true), I response with "But then why even bother with mostly-fixed-but-not-quite instruction length, just make a properly variable length ISA, it'd…
Earlier quoted context omitted.
Compressed is necessary to reduce code size which is important for performance. A bunch of vendors have done high performance server chips which support compressed (Rivos, Ventana, some Chinese vendors), so in actual reality this was only a problem for Qualcomm. And that's only because Qualcomm bought Nuvia and they wanted to do the cheap thing (minimally change the front end) rather than the right thing.
Of course you can make compressed work. E.g. you fetch 66 bytes instead of 64. Hell, Intel/AMD manage to make x86 fairly fast. But it's definitely more awkward and has costs throughout the CPU. I would be really surprised if the lower code density is worse than the improvement due to everything being nicely aligned. Especially because Qualcomm had actual data that it isn't (if you add new instructions with the extra…
Not really, you would fetch fewer bytes with RVC [2, page 9], because the code density is better.
> I would be really surprised if the lower code density is worse than the improvement due to everything being nicely aligned.
This is very hard to quantify.
> Especially because Qualcomm had actual data that it isn't (if you add new instructions with the extra coding space you free up).
I've liked the back and forth slides bellow. Though I want to bring up to things regrading the Qualcomm slides:
> [RVC] Performance benefit is modest
> • Best case: 2-3% speedup
I also have no idea how they got those numbers. (not that they are wildly implausible, it's just not transparent)
> Improving Android Code Size
I want to point out, that the JAL opcode has enough space left (7/8th) to encode a long jump of a same range and there is a proposal for a 32-bit +32M -12M 32-bit long jump: https://github.com/riscv/riscv-isa-manual/blob/zijfal/src/un...
[1] https://lists.riscv.org/g/tech-profiles/attachment/321/0/A%2...
[2] https://lists.riscv.org/g/tech-profiles/attachment/353/0/RIS...
[3] https://lists.riscv.org/g/tech-profiles/attachment/378/0/Res...
[4] https://lists.riscv.org/g/tech-profiles/attachment/400/0/AOS...