5 ms·

RISC isn't about the number of total instructions, but the complexity of the individual instructions. Consider the ARM "JavaScript instruction" people love to m

RISC isn't about the number of total instructions, but the complexity of the individual instructions. Consider the ARM "JavaScript instruction" people love to make fun of. FJCVTZS sure sounds like a ridiculous instruction name right out of x86 -- but in reality, it performs a very simple task that greatly speeds up JavaScript code, and it's trivial to implement in hardware but painful in software. If you're going to be doing a task like that frequently it absolutely makes sense to have an instruction for it, and RISC vs. CISC doesn't change that. What makes an architecture CISC is when the instructions start to do too many things at once. For instance, on x86 you can write something like ‘ADD [rax + 0x1234 + 8*rbx], rcx'. This one instruction involves a bit shift, two additions, a memory load, a third addition, and a memory store (and you can stick on prefix bytes to do even more things). Whereas on a RISC you'd split this operation into four or five separate instructions. Crucially, the work that the processor has to do doesn't actually change -- the CISC processor is just going to split the instruction apart into RISCy microoperations anyway. So the RISC processor has to do a little more memory access to read all the instructions, but much less decoding work to lower them into the same microcode.

snvzz 4y ago
>So the RISC processor has to do a little more memory access to read all the instructions, Or not. Example: RISC-V has higher code density than x86-64. Compilers produce consistently smaller code.
- jeffbee 4y ago
  RV64C is typically more dense than x86-64, but RV64 is about the same. RVC is an ISA extension and not all implementations support it.
  - seoaeu 4y ago
    Nearly everything supports the C-extension. The designers were initially expecting that small cores wouldn’t implement it, but quickly discovered that the code size improvements more than paid for the extra gates
  - jabl 4y ago
    I think RVC is more or less universal if we're talking higher end than really simple micro-controllers or university student projects.
    - snvzz 4y ago
      C is also part of RVA20 and RVA22.
    - hajile 4y ago
      Even really simple MCs are likely going to use compressed instructions. RISC-V apparently takes something like 8k gates. Compressed instructions take around 400 gates or 5% more area in this case. SRAM need 6 transistors, so just 67 bits or a bit less than 8.5 bytes of storage reduction is enough to make this worth the gate cost. If you have just 1kb of I-cache, a 10% savings or 100 bytes would be 10x the cost of implementing compressed instructions. In short, I can't think of any reason you'd target a 32-bit microcontroller RISC-V design and not decide to also implement compressed instructions. If you're so sensitive to this cost, there are probably 8/16-bit MCs that would be a better choice.
      - kragen 4y ago
        Most microcontrollers don't have I-cache, and I don't know of any 8/16 bit CPU cores that are significantly smaller on an FPGA than the SeRV implementation of RISC-V, which fits in 200 4-LUTs. Do you? PicoBlaze in particular is about the same size as SeRV (96 6-LUTs I think) and really limited even compared to other 8-bit cores. It's a lot faster than SeRV, though, and has denser code—it has to, since its maximum program size is 1024 instructions. SeRV's RISC-V support lets you compile your code with GCC or clang. I do agree with your broader point that the C extension trades off a bit of decode complexity against a tiny amount of program memory size, even if that's mask ROM or something instead of SRAM I$, so there are not many cases where omitting the C extension is a good tradeoff. Just, I'm not sure the architectural data word width really bears on this.
        hajile 4y ago
        I-cache was just one example that most people find easy to understand. The original paper on compressed instructions claims 25-30% reduction in total instruction size. A typical small M0 microcontroller will have something like 4-32kb of RAM and 32kb to 1MB of flash storage. No matter how you slice it, saving 30% of your instruction space is a HUGE deal. Even with EEPROM (usually used for flash memory) taking just 2 transistors per bit, we're still talking about compressed instructions taking up 200 bits, 40 bytes, or just TEN 32-bit instructions in your flash memory. With that 30% optimistic number, any program with more than 30 instructions will have a net benefit from compressed instructions. Even my very pessimistic 10% number would mean just 100 instructions before you break even.
  - tverbeure 4y ago
    Are there any RV64 implementations without C? If you already take the hit of going 64-bits instead of 32, then dropping compressed instructions seems like a strange trade-off.
    - rwmj 4y ago
      Shakti (made by a group of Indian research institutes). Lack of compressed instructions is also the reason why no Linux distro supports Shakti.
      - brucehoult 4y ago
        I wish people -- especially those who really should know better, such as distro maintainers -- would stop repeating this misinformation. Only their very first experimental chip didn't have C. All their subsequent (and actual production) chips have C. E-Class: RV64IMAC https://gitlab.com/shaktiproject/cores/e-class/blob/master/README.md https://gitlab.com/shaktiproject/cores/e-class/blob/master/R... C-Class: RV64GCSUN https://gitlab.com/shaktiproject/cores/c-class/blob/master/README.md https://gitlab.com/shaktiproject/cores/c-class/blob/master/R...
  - brucehoult 4y ago
    >RVC is an ISA extension and not all implementations support it. I have never seen a commercially-produced RISC-V core that doesn't include the C extension. It's simply too cheap and too useful to leave out. You make back the cost of the C decoder in probably the first 1 or 2 KB of ITIM/icache. The only things that don't have the C extension are educational examples/student projects and extremely simple cores for FPGA uses where they probably run controller code with just a few dozen instructions. You'll certainly never see anything with 64 bit, an MMU, or an FPU that doesn't have the C extension. You could do it, but it's stupid.
monocasa 4y ago
Backing this up, here's an ancient usenet post by John R. Mashey (one of the MIPS designers at SGI) defending HP's use of BCD instructions in their RISC core. https://www.yarchive.net/comp/bcd_instructions.html https://www.yarchive.net/comp/bcd_instructions.html HP looked at their actual uses at the time, found a lot of COBOL that required BCD, and included single cycle, register-register instructions to accelerate that use case that was very important to them.
jabl 4y ago
> What makes an architecture CISC is when the instructions start to do too many things at once. For instance, on x86 you can write something like ‘ADD [rax + 0x1234 + 8*rbx], rcx'. Amusingly, one of the common criticisms against RISC-V is that it doesn't have more complex addressing modes like "base + index << shift". Which other RISC ISA's like ARM or POWER do have, and is quite widely used in application code (think array indexing). This doesn't mean that a RISC CPU must split this up into internal micro-ops, AFAIK at least higher end ARM designs implements it all in a single micro-op by having a small adder and shift unit as part of the memory pipe (adders and limited shifters are really small area-wise).
- NobodyNada 4y ago
  Indeed, and this is where the usenet post linked in a sibling comment is really informative: In my opinion, the most common reasonable reason for including some instructions is: a) There is a datatype deemed worth supporting, i.e., whose use burns an interesting number of cycles, either because: 1) It gets used often enough, OR 2) It is used less often, but is really expensive. b) There is a reasonable hardware cost to support the datatype. c) Simulating the use of the datatype with the existing instructions is noticably expensive. In practice, b)+c) usually mean that the datatype operations can obtain useful parallelism in hardware, that cannot be gotten at by sequences of the existing instructions. IF it is difficult to beat sequences of existing instructions in speed, then only if those sequences are really frequent would one add new instrucions, i.e.e., for code density. Adding a little adder and shifter to the memory access unit meets all these conditions -- it's an operation that is effectively free in hardware, but would cost extra cycles & bytes to implement in software. So the "problem" with x86 isn't that such a complex addressing mode exists. It's that the ADD instruction has such a complex addressing mode, as does nearly every other instruction in the ISA. An 'ADD mem, reg' instruction is really a load, an add, and a store, and there's no hardware magic you can do to accelerate that -- it's just as fast to write "load, add, store" in software, so this fails tests b) and c). A RISC will typically have, let's say a dozen load/store instructions to support a variety of addressing modes (probably more if you account for atomics and vectors and non-temporals and whatnot). Then you only need one ADD instruction, one SUB instruction, one XOR instruction, maybe one FJCVTZS instruction, etc. But on x86, you get sort of a combinatoric explosion between possible combinations of instructions, addressing modes, and prefix bytes, which means your decoder has to support a dozen ADDs, a dozen SUBs, a dozen XORs, a dozen FJCVTZSes, and whatever.

snvzz 4y ago

>So the RISC processor has to do a little more memory access to read all the instructions, Or not. Example: RISC-V has higher code density than x86-64. Compilers produce consistently smaller code.

jeffbee 4y ago
RV64C is typically more dense than x86-64, but RV64 is about the same. RVC is an ISA extension and not all implementations support it.
- seoaeu 4y ago
  Nearly everything supports the C-extension. The designers were initially expecting that small cores wouldn’t implement it, but quickly discovered that the code size improvements more than paid for the extra gates
- jabl 4y ago
  I think RVC is more or less universal if we're talking higher end than really simple micro-controllers or university student projects.
  - snvzz 4y ago
    C is also part of RVA20 and RVA22.
  - hajile 4y ago
    Even really simple MCs are likely going to use compressed instructions. RISC-V apparently takes something like 8k gates. Compressed instructions take around 400 gates or 5% more area in this case. SRAM need 6 transistors, so just 67 bits or a bit less than 8.5 bytes of storage reduction is enough to make this worth the gate cost. If you have just 1kb of I-cache, a 10% savings or 100 bytes would be 10x the cost of implementing compressed instructions. In short, I can't think of any reason you'd target a 32-bit microcontroller RISC-V design and not decide to also implement compressed instructions. If you're so sensitive to this cost, there are probably 8/16-bit MCs that would be a better choice.
    - kragen 4y ago
      Most microcontrollers don't have I-cache, and I don't know of any 8/16 bit CPU cores that are significantly smaller on an FPGA than the SeRV implementation of RISC-V, which fits in 200 4-LUTs. Do you? PicoBlaze in particular is about the same size as SeRV (96 6-LUTs I think) and really limited even compared to other 8-bit cores. It's a lot faster than SeRV, though, and has denser code—it has to, since its maximum program size is 1024 instructions. SeRV's RISC-V support lets you compile your code with GCC or clang. I do agree with your broader point that the C extension trades off a bit of decode complexity against a tiny amount of program memory size, even if that's mask ROM or something instead of SRAM I$, so there are not many cases where omitting the C extension is a good tradeoff. Just, I'm not sure the architectural data word width really bears on this.
      - hajile 4y ago
        I-cache was just one example that most people find easy to understand. The original paper on compressed instructions claims 25-30% reduction in total instruction size. A typical small M0 microcontroller will have something like 4-32kb of RAM and 32kb to 1MB of flash storage. No matter how you slice it, saving 30% of your instruction space is a HUGE deal. Even with EEPROM (usually used for flash memory) taking just 2 transistors per bit, we're still talking about compressed instructions taking up 200 bits, 40 bytes, or just TEN 32-bit instructions in your flash memory. With that 30% optimistic number, any program with more than 30 instructions will have a net benefit from compressed instructions. Even my very pessimistic 10% number would mean just 100 instructions before you break even.
- tverbeure 4y ago
  Are there any RV64 implementations without C? If you already take the hit of going 64-bits instead of 32, then dropping compressed instructions seems like a strange trade-off.
  - rwmj 4y ago
    Shakti (made by a group of Indian research institutes). Lack of compressed instructions is also the reason why no Linux distro supports Shakti.
    - brucehoult 4y ago
      I wish people -- especially those who really should know better, such as distro maintainers -- would stop repeating this misinformation. Only their very first experimental chip didn't have C. All their subsequent (and actual production) chips have C. E-Class: RV64IMAC https://gitlab.com/shaktiproject/cores/e-class/blob/master/README.md https://gitlab.com/shaktiproject/cores/e-class/blob/master/R... C-Class: RV64GCSUN https://gitlab.com/shaktiproject/cores/c-class/blob/master/README.md https://gitlab.com/shaktiproject/cores/c-class/blob/master/R...
- brucehoult 4y ago
  >RVC is an ISA extension and not all implementations support it. I have never seen a commercially-produced RISC-V core that doesn't include the C extension. It's simply too cheap and too useful to leave out. You make back the cost of the C decoder in probably the first 1 or 2 KB of ITIM/icache. The only things that don't have the C extension are educational examples/student projects and extremely simple cores for FPGA uses where they probably run controller code with just a few dozen instructions. You'll certainly never see anything with 64 bit, an MMU, or an FPU that doesn't have the C extension. You could do it, but it's stupid.

monocasa 4y ago

Backing this up, here's an ancient usenet post by John R. Mashey (one of the MIPS designers at SGI) defending HP's use of BCD instructions in their RISC core. https://www.yarchive.net/comp/bcd_instructions.html https://www.yarchive.net/comp/bcd_instructions.html HP looked at their actual uses at the time, found a lot of COBOL that required BCD, and included single cycle, register-register instructions to accelerate that use case that was very important to them.

jabl 4y ago

> What makes an architecture CISC is when the instructions start to do too many things at once. For instance, on x86 you can write something like ‘ADD [rax + 0x1234 + 8*rbx], rcx'. Amusingly, one of the common criticisms against RISC-V is that it doesn't have more complex addressing modes like "base + index << shift". Which other RISC ISA's like ARM or POWER do have, and is quite widely used in application code (think array indexing). This doesn't mean that a RISC CPU must split this up into internal micro-ops, AFAIK at least higher end ARM designs implements it all in a single micro-op by having a small adder and shift unit as part of the memory pipe (adders and limited shifters are really small area-wise).

NobodyNada 4y ago
Indeed, and this is where the usenet post linked in a sibling comment is really informative: In my opinion, the most common reasonable reason for including some instructions is: a) There is a datatype deemed worth supporting, i.e., whose use burns an interesting number of cycles, either because: 1) It gets used often enough, OR 2) It is used less often, but is really expensive. b) There is a reasonable hardware cost to support the datatype. c) Simulating the use of the datatype with the existing instructions is noticably expensive. In practice, b)+c) usually mean that the datatype operations can obtain useful parallelism in hardware, that cannot be gotten at by sequences of the existing instructions. IF it is difficult to beat sequences of existing instructions in speed, then only if those sequences are really frequent would one add new instrucions, i.e.e., for code density. Adding a little adder and shifter to the memory access unit meets all these conditions -- it's an operation that is effectively free in hardware, but would cost extra cycles & bytes to implement in software. So the "problem" with x86 isn't that such a complex addressing mode exists. It's that the ADD instruction has such a complex addressing mode, as does nearly every other instruction in the ISA. An 'ADD mem, reg' instruction is really a load, an add, and a store, and there's no hardware magic you can do to accelerate that -- it's just as fast to write "load, add, store" in software, so this fails tests b) and c). A RISC will typically have, let's say a dozen load/store instructions to support a variety of addressing modes (probably more if you account for atomics and vectors and non-temporals and whatnot). Then you only need one ADD instruction, one SUB instruction, one XOR instruction, maybe one FJCVTZS instruction, etc. But on x86, you get sort of a combinatoric explosion between possible combinations of instructions, addressing modes, and prefix bytes, which means your decoder has to support a dozen ADDs, a dozen SUBs, a dozen XORs, a dozen FJCVTZSes, and whatever.