4 ms·

Okay, so it's more about IMM representation within the bytecode rather than some memory addressing mode.

dmitrygr 2y ago
Well, lack of REG+REG and REG+SHIFTED_REG addressing modes handicaps it significantly. And no, it will not get magically fused by magic fusing fairies in your cpu
- snvzz 2y ago
  >lack of REG+REG and REG+SHIFTED_REG addressing modes handicaps it significantly Is this a guess, or statistically supported on a body of empirical evidence like the RISC-V spec is?
  - dmitrygr 2y ago
    Compile same code for aarch64 and riscv64. Compare. It is well known design deficiency. Much like lack of bit field ops.
    - camel-cdr 2y ago
      Do you have code examples for this? I'm looking for cases where RISC-V is lacking compared to arm.
    - snvzz 2y ago
      Sounds extremely subjective. i.e. it does not have my favored instructions or addressing modes, so it must be worse.
      - smolder 2y ago
        Much like juggling with your feet instead of hands is subjectively worse.
        snvzz 2y ago
        From a hardware perspective, juggling is better without flags and without unnecessary addressing modes. Neither are concepts RISC-V invented, but rather, adopted. Ideas that have been plenty tested out there, and proven beneficial. Large body of evidence trumps intuition and guesswork. Most of this is documented in the spec itself and/or in: Computer Architecture: A Quantitative Approach (John L. Hennessy, David A. Patterson)
        smolder 2y ago
        I just meant that it's somewhat unergonomic when dealing with the instruction set directly, FWIW. Thanks for the reference.
      - jodrellblank 2y ago
        You’re replying to the author of the post explaining why he would have to do more in software to emulate RISC-V than MIPS and that would be more effort and run slower, and you’re telling him “that’s extremely subjective”? How is that subjective?
        Dylan16807 2y ago
        "well known design deficiency" is the subjective part.
- kouteiheika 2y ago
  > Well, lack of REG+REG and REG+SHIFTED_REG addressing modes handicaps it significantly. Does it? Well, there's a vendor specific extension for that (XTheadMemIdx): https://github.com/XUANTIE-RV/thead-extension-spec/releases/tag/2.2.2 https://github.com/XUANTIE-RV/thead-extension-spec/releases/... Not sure about GCC, but on clang it is trivial to enable it. And if you really want to (assuming you have the hardware) you could compile exactly the same code with and without it and compare how much exactly it is handicapped if those instructions are not there. Plus, on RISC-V multiplication/division (about which you've complained) is optional, and there is also a variant of RISC-V with only 16 registers instead of 32 (also very simple to enable on recent versions of clang, although Linux would probably need some modifications to be able to run on that). So I'm not entirely convinced that RISC-V would be worse here.
  - dmitrygr 2y ago
    Lack of mul/div isn’t actually good. Having it be done ins guest code is a magnitude slower than is host code. My other issue was that there is NO working Linux user space for rv32. There is for rv64. No Debian. No Ubuntu. No anything for rv32

Well, lack of REG+REG and REG+SHIFTED_REG addressing modes handicaps it significantly. And no, it will not get magically fused by magic fusing fairies in your cpu

snvzz 2y ago
>lack of REG+REG and REG+SHIFTED_REG addressing modes handicaps it significantly Is this a guess, or statistically supported on a body of empirical evidence like the RISC-V spec is?
- dmitrygr 2y ago
  Compile same code for aarch64 and riscv64. Compare. It is well known design deficiency. Much like lack of bit field ops.
  - camel-cdr 2y ago
    Do you have code examples for this? I'm looking for cases where RISC-V is lacking compared to arm.
  - snvzz 2y ago
    Sounds extremely subjective. i.e. it does not have my favored instructions or addressing modes, so it must be worse.
    - smolder 2y ago
      Much like juggling with your feet instead of hands is subjectively worse.
      - snvzz 2y ago
        From a hardware perspective, juggling is better without flags and without unnecessary addressing modes. Neither are concepts RISC-V invented, but rather, adopted. Ideas that have been plenty tested out there, and proven beneficial. Large body of evidence trumps intuition and guesswork. Most of this is documented in the spec itself and/or in: Computer Architecture: A Quantitative Approach (John L. Hennessy, David A. Patterson)
        smolder 2y ago
        I just meant that it's somewhat unergonomic when dealing with the instruction set directly, FWIW. Thanks for the reference.
    - jodrellblank 2y ago
      You’re replying to the author of the post explaining why he would have to do more in software to emulate RISC-V than MIPS and that would be more effort and run slower, and you’re telling him “that’s extremely subjective”? How is that subjective?
      - Dylan16807 2y ago
        "well known design deficiency" is the subjective part.
kouteiheika 2y ago
> Well, lack of REG+REG and REG+SHIFTED_REG addressing modes handicaps it significantly. Does it? Well, there's a vendor specific extension for that (XTheadMemIdx): https://github.com/XUANTIE-RV/thead-extension-spec/releases/tag/2.2.2 https://github.com/XUANTIE-RV/thead-extension-spec/releases/... Not sure about GCC, but on clang it is trivial to enable it. And if you really want to (assuming you have the hardware) you could compile exactly the same code with and without it and compare how much exactly it is handicapped if those instructions are not there. Plus, on RISC-V multiplication/division (about which you've complained) is optional, and there is also a variant of RISC-V with only 16 registers instead of 32 (also very simple to enable on recent versions of clang, although Linux would probably need some modifications to be able to run on that). So I'm not entirely convinced that RISC-V would be worse here.
- dmitrygr 2y ago
  Lack of mul/div isn’t actually good. Having it be done ins guest code is a magnitude slower than is host code. My other issue was that there is NO working Linux user space for rv32. There is for rv64. No Debian. No Ubuntu. No anything for rv32