4 ms·

Everything RISC-V is good (even the mistakes which is making it more robust and more mature).

by sylware 3mo ago

timhh 3mo ago
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 undefined/implementation defined behaviours, which is great if you want to implement an ultra minimal microcontroller with 100 flops, but pretty awful otherwise. Requiring the C (compressed) extension in the RVA profiles was definitely a mistake. The lack of true 16/64kB pages and conditional moves are probably a mistake (though fixable). I don't know how any of these make it more robust and mature. (But to be clear, I still think it's pretty good overall.)
- rwmj 3mo ago
  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 excuse given by Qualcomm - that it would make all instructions fixed length and so much easier to decode - is just wrong. RISC-V supports variable length instructions, even much longer than 32 bits, and you've just got to deal with it. Just because Qualcomm acquired a company with a microarchitecture that could only deal with fixed length instructions is no reason to break the ecosystem. Also interested in the problems you see in Zicond. It claims at least to give you most of the benefit of conditional moves using only two instructions, but I've not actually tried using it. (https://docs.riscv.org/reference/isa/extensions/zicond/_attachments/riscv-zicond.pdf https://docs.riscv.org/reference/isa/extensions/zicond/_atta...)
  - Joker_vD 3mo ago
    > 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 add a 4-byte ring buffer but all in all, efficiently supporting the C extension is non-trivial.
    - rwmj 3mo ago
      RISC-V definitely does support instructions longer than 32 bits, starting at 48 bits (ie. 32 + 16), and going much longer. They are much easier to decode than x86 because the length is evident from the first byte. No ratified extension uses them now, but you're going to need to deal with them as the extension space gets more crowded. Including dealing with instructions split across cache lines and pages, and instructions aligned to 16 bits. I'm not sure what point you're making TBH.
      - Joker_vD 3mo ago
        My point is that fixed-length instructions are supposed to be easier to decode than variable-length ones, right? If not, then why even bother with fitting immediates and inventing LUI/AUIPC, just have a 48-bit long LI instruction. The same goes for 64-bit, an 80-bit LI.W is still shorter than the piecemeal construction with several instructions. If yes, then the small cores are arbitrarily given a burden of supporting variable-length instructions, supposedly efficiently: if your instruction fetch is 16-bit wide, you need two fetches to fetch a single 32-bit instruction, which sucks; if it's 32-bit wide, you need to conditionally stash the upper half for the next fetch cycle, and still prefetch yet more 32-bits because that upper half may contain only a half of a full 32-bit instruction; alternatively, you can fetch 32-bits at alternated aligned/misaligned addresses and ignore the inefficiency of throwing away re-fetched bits — again, all of this sucks.
        3mo ago
- sylware 3mo ago
  English is not my native language and I wrote a bit too fast the message: I wanted to say that "everything pushing forward RISC-V is good". 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.
  - rwmj 3mo ago
    Aarch64 dropped thumb instructions. I don't think you're going to find a single benchmark on the effectiveness of compressed instructions since it really depends deeply on both the workload and the whole system. For example, memory bandwidth and cache pressure are both important for whether smaller text sizes matter, and that may depend on what else is running at the same time. Note your assembler may be automatically compressing instructions without you asking. You'll have to disassemble the binary to find out.
    - camel-cdr 3mo ago
      You can benchmark stuff with and without RVC. Once there is faster hardware I want to do such a comparison with a full gentoo build for both sides. However, quantifying what the result will actually mean is nearly impossible, because you don't know what the hardware cost was.
    - sylware 3mo ago
      Maybe the best approach is to remove C from RVA while keeping it around in the specs for niche applications where text size _really_ matters (with current silicon processes, I wonder how weird those niche applications have to be to require C). But it seems some would remove C even from the specs to free some ISA space. If arm removed thumb... Don't worry, I would know if the assembler is producing C machine instructions, my rv64 interpreter on x86_64 does not support the C instructions at all.
- flopsamjetsam 3mo ago
  > CLIC was awful (thankfully it has been abandoned) Could you expand a little on what made it a bad design? I'm not much up on RISC-V.
  - timhh 3mo ago
    Mostly the specification was just poorly written with many ambiguities. But also the design was complex, weird, invasive and IIRC not backwards compatible with standard RISC-V.

Everything RISC-V is good (even the mistakes which is making it more robust and more mature).

by sylware 3mo ago

Everything RISC-V is good (even the mistakes which is making it more robust and more mature).

timhh 3mo ago

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 undefined/implementation defined behaviours, which is great if you want to implement an ultra minimal microcontroller with 100 flops, but pretty awful otherwise. Requiring the C (compressed) extension in the RVA profiles was definitely a mistake. The lack of true 16/64kB pages and conditional moves are probably a mistake (though fixable). I don't know how any of these make it more robust and mature. (But to be clear, I still think it's pretty good overall.)

rwmj 3mo ago
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 excuse given by Qualcomm - that it would make all instructions fixed length and so much easier to decode - is just wrong. RISC-V supports variable length instructions, even much longer than 32 bits, and you've just got to deal with it. Just because Qualcomm acquired a company with a microarchitecture that could only deal with fixed length instructions is no reason to break the ecosystem. Also interested in the problems you see in Zicond. It claims at least to give you most of the benefit of conditional moves using only two instructions, but I've not actually tried using it. (https://docs.riscv.org/reference/isa/extensions/zicond/_attachments/riscv-zicond.pdf https://docs.riscv.org/reference/isa/extensions/zicond/_atta...)
- Joker_vD 3mo ago
  > 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 add a 4-byte ring buffer but all in all, efficiently supporting the C extension is non-trivial.
  - rwmj 3mo ago
    RISC-V definitely does support instructions longer than 32 bits, starting at 48 bits (ie. 32 + 16), and going much longer. They are much easier to decode than x86 because the length is evident from the first byte. No ratified extension uses them now, but you're going to need to deal with them as the extension space gets more crowded. Including dealing with instructions split across cache lines and pages, and instructions aligned to 16 bits. I'm not sure what point you're making TBH.
    - Joker_vD 3mo ago
      My point is that fixed-length instructions are supposed to be easier to decode than variable-length ones, right? If not, then why even bother with fitting immediates and inventing LUI/AUIPC, just have a 48-bit long LI instruction. The same goes for 64-bit, an 80-bit LI.W is still shorter than the piecemeal construction with several instructions. If yes, then the small cores are arbitrarily given a burden of supporting variable-length instructions, supposedly efficiently: if your instruction fetch is 16-bit wide, you need two fetches to fetch a single 32-bit instruction, which sucks; if it's 32-bit wide, you need to conditionally stash the upper half for the next fetch cycle, and still prefetch yet more 32-bits because that upper half may contain only a half of a full 32-bit instruction; alternatively, you can fetch 32-bits at alternated aligned/misaligned addresses and ignore the inefficiency of throwing away re-fetched bits — again, all of this sucks.
      - 3mo ago
sylware 3mo ago
English is not my native language and I wrote a bit too fast the message: I wanted to say that "everything pushing forward RISC-V is good". 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.
- rwmj 3mo ago
  Aarch64 dropped thumb instructions. I don't think you're going to find a single benchmark on the effectiveness of compressed instructions since it really depends deeply on both the workload and the whole system. For example, memory bandwidth and cache pressure are both important for whether smaller text sizes matter, and that may depend on what else is running at the same time. Note your assembler may be automatically compressing instructions without you asking. You'll have to disassemble the binary to find out.
  - camel-cdr 3mo ago
    You can benchmark stuff with and without RVC. Once there is faster hardware I want to do such a comparison with a full gentoo build for both sides. However, quantifying what the result will actually mean is nearly impossible, because you don't know what the hardware cost was.
  - sylware 3mo ago
    Maybe the best approach is to remove C from RVA while keeping it around in the specs for niche applications where text size _really_ matters (with current silicon processes, I wonder how weird those niche applications have to be to require C). But it seems some would remove C even from the specs to free some ISA space. If arm removed thumb... Don't worry, I would know if the assembler is producing C machine instructions, my rv64 interpreter on x86_64 does not support the C instructions at all.
flopsamjetsam 3mo ago
> CLIC was awful (thankfully it has been abandoned) Could you expand a little on what made it a bad design? I'm not much up on RISC-V.
- timhh 3mo ago
  Mostly the specification was just poorly written with many ambiguities. But also the design was complex, weird, invasive and IIRC not backwards compatible with standard RISC-V.