8 ms·

I have to admit, as useful as some of these extension specs may be, it makes me feel like the RISC part of RISC-V is slowly falling by the wayside.

brucehoult 4y ago
Three of these four are software-only changes, and the 4th is hardware but doesn't affect the ISA as seen by a user.
- monocasa 4y ago
  And particularly, the 4th is an optional removal of instructions on systems that don't require it.
panick21_ 4y ago
It was always the goal to support everything from micro to hpc. So more extensions were always expected. However the R in RISC revers to the how many instruction you have to implement to get a job done. If you write for a microcontroller, RISC-V is just as small now as it was when it started.
- andrekandre 4y ago
  > However the R in RISC revers to the how many instruction you have to implement to get a job done. right, the way i always understood it was, in many situations there are different riscs that are appropriate (e.g i only need 32-bit integer and atomic instructions for job x) so instead of accumulating larger and larger single spec, you can pick and choose whats needed: you can have still have your risc (fewer, simpler, efficient instruction) cake and eat it (deploy it in various divergent situations and still be standard) too
NobodyNada 4y ago
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.
ncmncm 4y ago
RISC fell by the wayside decades ago. Two of them. It was really only ever a design touchstone, a reminder that simple operations are easier to fit into a short clock cycle, and complex instructions are not necessarily faster than a series of simple ones. Since the time RISC still was considered a plausible thing, we got cache footprints, and micro-ops in a cache of their own. What matters, ultimately, is performance. RISC was once a means to get performance. Nowadays we do all kinds of crazy shit to get performance, very little of it compatible with what RISC was supposed to enable. So anyway maybe a mistake to put in the name.

brucehoult 4y ago

Three of these four are software-only changes, and the 4th is hardware but doesn't affect the ISA as seen by a user.

monocasa 4y ago
And particularly, the 4th is an optional removal of instructions on systems that don't require it.

panick21_ 4y ago

It was always the goal to support everything from micro to hpc. So more extensions were always expected. However the R in RISC revers to the how many instruction you have to implement to get a job done. If you write for a microcontroller, RISC-V is just as small now as it was when it started.

andrekandre 4y ago
> However the R in RISC revers to the how many instruction you have to implement to get a job done. right, the way i always understood it was, in many situations there are different riscs that are appropriate (e.g i only need 32-bit integer and atomic instructions for job x) so instead of accumulating larger and larger single spec, you can pick and choose whats needed: you can have still have your risc (fewer, simpler, efficient instruction) cake and eat it (deploy it in various divergent situations and still be standard) too

NobodyNada 4y ago

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.

ncmncm 4y ago

RISC fell by the wayside decades ago. Two of them. It was really only ever a design touchstone, a reminder that simple operations are easier to fit into a short clock cycle, and complex instructions are not necessarily faster than a series of simple ones. Since the time RISC still was considered a plausible thing, we got cache footprints, and micro-ops in a cache of their own. What matters, ultimately, is performance. RISC was once a means to get performance. Nowadays we do all kinds of crazy shit to get performance, very little of it compatible with what RISC was supposed to enable. So anyway maybe a mistake to put in the name.