4 ms·

> the so-called better results were for the compressed extension, not for the normal encoding. Ignoring RISC-V’s compressed encoding seems a rather artificial

• brucehoult 5y ago
  Indeed. The "C" extension is technically optional, but I'm not aware of anyone who has made or sold a production chip without it -- generally only student projects or tiny cores for FPGAs running very simple programs don't have it. My estimate is if you have even 200 to 300 instructions in your code it's cheaper to implement "C" than to build the extra SRAM/cache to hold the bigger code without it.
• adrian_b 5y ago
  The compressed encoding has good code density, but low speed. The compressed RISC-V encoding must be compared with the ARMv8-M encoding not with the ARMv8-A. The base 32-bit RISC-V encoding may be compared with the ARMv8-A, because only it can have comparable performance. All the comparisons where RISC-V has better code density compare the compressed encoding with the 32-bit ARMv8-A. This is a classical example of apples-to-oranges, because the compressed encoding will never have a performance in the same league with ARMv8-A. When the comparisons are matched, 16-bit RISC-V encoding with 16-bit ARMv8-M and 32-bit RISC-V with 32-bit ARMv8-A, RISC-V always loses in code density in both comparisons, because only the RISC-V branch instructions are frequently shorter than those of ARM, while all the other instructions are frequently longer. There are good reasons to use RISC-V for various purposes, where either the lack of royalties or the easy customization of the instruction set are important, but claiming that it should be chosen not because it is cheaper, but because it were better, looks like the story with the sour grapes. The value of RISC-V is not in its instruction set, because there are thousands of people who could design better ISAs in a week of work. What is valuable about RISC-V is the set of software tools, compilers, binutils, debuggers etc. While a better ISA can be done in a week, recreating the complete software environment would need years of work.
  • deleted 5y ago
    [deleted]
  • FullyFunctional 5y ago
    > The compressed encoding has good code density, but low speed. That's 100% nonsense. They have the same performance and in fact, some pipelines can get better performance because they fetch a fixed number of bytes and with compressed instructions, that means more instructions fetched. The rest of the argument falls apart resting on this fallacy.
    • amelius 5y ago
      Doesn't decompression imply that there is some extra latency?
      • socialdemocrat 5y ago
        No, it is just part of the regular instruction decoding. It is not like it is zip compressed. It is just 400 logic gates added to the decoder… which is nothing.
        • amelius 5y ago
          Yes, but the logic signal needs to ripple through those gates, which takes time.
          • kragen 5y ago
            It potentially adds latency, but doesn't drop throughput.
        • FullyFunctional 5y ago
          All the implementation I know of all does the same thing: they expand the compressed instruction into a non-compressed instruction. For all (most?), this required an additional stage in the decoder. So in that sense, supporting C mean a slight increase in the branch mispredict penalty, but the instruction itself takes the same path with the same latency regardless of it being compressed or not. Completely aside, compressed instruction hurt in a completely different way: as specified RISC-V happily allows instructions to be split across two cache lines, which could be from two different pages even. THIS is a royal pain in the ass and rules out certain implementation tricks. Also, the variable length instructions means more stages before you can act on the stream, including for example rename them. However a key point here is that it isn't a per-instruction penalty, it a penalty paid for all instruction if the pipeline support any variable length instructions.