4 ms·

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 simpl

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 macro-op fusion and C extension > Including compressed instruction in the Unix profile was the biggest mistake RISC-V did and I'll die on that hill. This is so wrong. The C extension is one of the great strengths of RISC-V, it is easy to decode, very suitable for macro-op fusion, and it gives a huge boost in code density

JonChesterfield 5y ago
Iirc compressed instructions are the thing that costs 2 bits per 32 and was criticised as overfitted to naive compiler output. Am I thinking of something else?
- avianes 5y ago
  Yes, but RISC-V still has a lot of encoding-space free and the benefit of C extension is huge. It's a trade-off. I don't think RISC-V is perfect or universal, but on this point they do a pretty good job compared to other ISAs
  - JonChesterfield 5y ago
    32 bit, 32 registers, three register code. So add r0 r1 r2 spends fifteen bits on identifying which register to use then another two on the compressed ISA. That's half the encoding space gone before identifying the op. Never thought I'd want fewer registers but here we are. If the compressed extension is great in practice it might be a win. If the early criticism of overfit to gcc -O0 proves sound and in practice compilers don't emit it then it was an expensive experiment.
    - avianes 5y ago
      The encoding space is not the number of bits used to encode an instruction, the encoding space is the ratio of values that encode a valid instructions over the total number of instructions that could be encoded. As an example, in an ISA with 8-bits fixed instruction length and 8 registers (reg index encoded on 3 bit): If the last 2 bits are the opcode and we define 2 instructions (eg. AND, XOR) that manipulate 2 registers (3 bits + 3 bits), then instruction word values 0b00_000_000 to 0b01_111_111 might encode these two instructions (ignore "_" they are separators). Therefore, instruction word values from 0b10_000_000 to 0b11_111_111 remain free, which represents half of the encoding space. So half of the encoding space remains free. This means we still have room to put new instructions. Similarly, RISC-V valid instructions use almost all the available bits, but there is still room in the encoding space because some opcodes remain free.
  - klelatti 5y ago
    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?
    - zozbot234 5y ago
      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.
      - klelatti 5y ago
        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.
        snvzz 5y ago
        >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.
    - avianes 5y ago
      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 important for RISC-V. Because RISC-V philosophy to reach high performance is to use very simple instructions that can be combined together and take advantage of macro-op fusion. I think RISC-V without macro-op fusion can't reach the performance of other ISA. But RISC-V with all these simple and not very expressive instructions and without C extension has a pretty bad code density which could cost a lot because it is not at the competitors' level. So if we think of RISC-V as a macro-op fusion oriented ISA, then the C extension becomes important to be competitive. I don't know what is better between a "macro-fusion" oriented arch or a "complex-instruction" oriented arch, future will tell us.
FullyFunctional 5y ago
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: The problem in this HN thread is the same reason we got compressed it in the first place. The vast majority of people aren’t doing high performance wide implementation so the true cost isn’t widely appreciated. The people holding the decision power certainly didn’t understand it. I really think you have to live it to understand it.
- avianes 5y ago
  > 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).

JonChesterfield 5y ago

Iirc compressed instructions are the thing that costs 2 bits per 32 and was criticised as overfitted to naive compiler output. Am I thinking of something else?

avianes 5y ago
Yes, but RISC-V still has a lot of encoding-space free and the benefit of C extension is huge. It's a trade-off. I don't think RISC-V is perfect or universal, but on this point they do a pretty good job compared to other ISAs
- JonChesterfield 5y ago
  32 bit, 32 registers, three register code. So add r0 r1 r2 spends fifteen bits on identifying which register to use then another two on the compressed ISA. That's half the encoding space gone before identifying the op. Never thought I'd want fewer registers but here we are. If the compressed extension is great in practice it might be a win. If the early criticism of overfit to gcc -O0 proves sound and in practice compilers don't emit it then it was an expensive experiment.
  - avianes 5y ago
    The encoding space is not the number of bits used to encode an instruction, the encoding space is the ratio of values that encode a valid instructions over the total number of instructions that could be encoded. As an example, in an ISA with 8-bits fixed instruction length and 8 registers (reg index encoded on 3 bit): If the last 2 bits are the opcode and we define 2 instructions (eg. AND, XOR) that manipulate 2 registers (3 bits + 3 bits), then instruction word values 0b00_000_000 to 0b01_111_111 might encode these two instructions (ignore "_" they are separators). Therefore, instruction word values from 0b10_000_000 to 0b11_111_111 remain free, which represents half of the encoding space. So half of the encoding space remains free. This means we still have room to put new instructions. Similarly, RISC-V valid instructions use almost all the available bits, but there is still room in the encoding space because some opcodes remain free.
- klelatti 5y ago
  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?
  - zozbot234 5y ago
    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.
    - klelatti 5y ago
      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.
      - snvzz 5y ago
        >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.
  - avianes 5y ago
    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 important for RISC-V. Because RISC-V philosophy to reach high performance is to use very simple instructions that can be combined together and take advantage of macro-op fusion. I think RISC-V without macro-op fusion can't reach the performance of other ISA. But RISC-V with all these simple and not very expressive instructions and without C extension has a pretty bad code density which could cost a lot because it is not at the competitors' level. So if we think of RISC-V as a macro-op fusion oriented ISA, then the C extension becomes important to be competitive. I don't know what is better between a "macro-fusion" oriented arch or a "complex-instruction" oriented arch, future will tell us.

FullyFunctional 5y ago

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: The problem in this HN thread is the same reason we got compressed it in the first place. The vast majority of people aren’t doing high performance wide implementation so the true cost isn’t widely appreciated. The people holding the decision power certainly didn’t understand it. I really think you have to live it to understand it.

avianes 5y ago
> 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).