5 ms·

There was an article on HN where someone called RISC-V a bit too RISCy. ARM has instructions that combine things that are commonly combined, which increases cod

There was an article on HN where someone called RISC-V a bit too RISCy. ARM has instructions that combine things that are commonly combined, which increases code density and requires fewer instruction decoders (as well as possibly instruction combine logic if there are micro/macro-ops) for the same performance.

phkahler 5y ago
RISC-V had better code density than anything a few years back. Cant say how it competes with the latest though. It does have some weird instruction encodings though. They intended it to be fixed 32bit instructions, but then that changed and its let with some odd things because of it. I'd like to see immediate data come after the instruction.
- brucehoult 5y ago
  In 32 bit, Thumb2 aka ARMv7 has slightly better code density than RISC-V. In 64 bit, RISC-V has by far the most dense code compared to ARM, x86, POWER or any other widely used 64 bit ISA. ARM dropped their 2-byte encodings going from 32 to 64 bit, which hurts them a lot. i386/i686 was reasonably dense, but amd64 needs a lot of REX prefix bytes which increases the code size. RISC-V was always designed to allow for variable instruction lengths. The base instruction set is fixed-length 32 bit -- 30 bit really, as the two LSBs are always '11'. Values of the two LSBs other than '11' were always intended for 16 bit instructions. Encodings with all 1s in the "major opcode" field are reserved to indicate future instructions longer than 32 bits. It's very likely that the first such instructions defined will be 48 bit instructions with 32 bit immediate data. However until now, RISC-V core designers have been strongly resisting adding instructions longer than 32 bits even though software people want them. It might look cleaner to load a 32 bit literal using a single 48 bit instruction instead of two 32 bit instructions, but it might not make for a faster computer.
ch_123 5y ago
That is an implementation detail of the processor hardware, and not of the instruction set, unless you have some details on why RISC-V cannot be implemented this way.
- ahartmetz 5y ago
  It is absolutely a property of the instruction set. In the meantime, I remembered two prominent examples: ARM has compare-and-branch instructions and load / store with offset and scaling instructions. There is no way to get the benefits of less decoding and possibly combining (possibly also reduced register pressure and shorter dependency chains - no intermediate address calculations or comparison status registers) without changing the instruction set.
  - zozbot234 5y ago
    RISC-V has compare-and-branch instructions, and load/store instructions w/ an offset field. Scaling can be achieved via insn fusion.
    - ahartmetz 5y ago
      Thanks for the correction. RISC-V actually seems to have the most efficient way to do conditional branches of all common ISAs (according to its instruction set reference document, heh). But about the more complex ARM load/store opcodes, the point stands that instruction fusion does not simplify decoding or increase code density the way a pre-fused instruction does.
      - brucehoult 5y ago
        "pre-fused" instructions use up a lot of opcode space that might be better used for other things. Complex addressing modes help code size if you've got just a single access to an array element in some straight line code, but they're seldom needed in loops because most of the calculation is best moved outside of the loop leaving just a simple pointer increment inside the loop.
  - deleted 5y ago
    [deleted]
- Symmetry 5y ago
  No, there are certainly ISA related performance factors. RISC-V compressed instructions are easier to decode than x86 but you still need to detect boundaries and mux instructions to their proper lanes. And if you don't you have problems with i-cache pressure. In theory instruction fusion can do a lot to increase backend instruction density. But to equal other ISAs RISC-V have to be fusing triplets instead of just pairs and that's a quadratically harder problem. It's not the end of the world but I don't think it's an accident that x86, on of the simplest CISC ISAs, and ARM, one of the most complex RISC ISAs, ended up being dominant.
saagarjha 5y ago
https://gist.github.com/erincandescent/8a10eeeea1918ee4f9d9982f7618ef68 https://gist.github.com/erincandescent/8a10eeeea1918ee4f9d99...

phkahler 5y ago

RISC-V had better code density than anything a few years back. Cant say how it competes with the latest though. It does have some weird instruction encodings though. They intended it to be fixed 32bit instructions, but then that changed and its let with some odd things because of it. I'd like to see immediate data come after the instruction.

brucehoult 5y ago
In 32 bit, Thumb2 aka ARMv7 has slightly better code density than RISC-V. In 64 bit, RISC-V has by far the most dense code compared to ARM, x86, POWER or any other widely used 64 bit ISA. ARM dropped their 2-byte encodings going from 32 to 64 bit, which hurts them a lot. i386/i686 was reasonably dense, but amd64 needs a lot of REX prefix bytes which increases the code size. RISC-V was always designed to allow for variable instruction lengths. The base instruction set is fixed-length 32 bit -- 30 bit really, as the two LSBs are always '11'. Values of the two LSBs other than '11' were always intended for 16 bit instructions. Encodings with all 1s in the "major opcode" field are reserved to indicate future instructions longer than 32 bits. It's very likely that the first such instructions defined will be 48 bit instructions with 32 bit immediate data. However until now, RISC-V core designers have been strongly resisting adding instructions longer than 32 bits even though software people want them. It might look cleaner to load a 32 bit literal using a single 48 bit instruction instead of two 32 bit instructions, but it might not make for a faster computer.

ch_123 5y ago

That is an implementation detail of the processor hardware, and not of the instruction set, unless you have some details on why RISC-V cannot be implemented this way.

ahartmetz 5y ago
It is absolutely a property of the instruction set. In the meantime, I remembered two prominent examples: ARM has compare-and-branch instructions and load / store with offset and scaling instructions. There is no way to get the benefits of less decoding and possibly combining (possibly also reduced register pressure and shorter dependency chains - no intermediate address calculations or comparison status registers) without changing the instruction set.
- zozbot234 5y ago
  RISC-V has compare-and-branch instructions, and load/store instructions w/ an offset field. Scaling can be achieved via insn fusion.
  - ahartmetz 5y ago
    Thanks for the correction. RISC-V actually seems to have the most efficient way to do conditional branches of all common ISAs (according to its instruction set reference document, heh). But about the more complex ARM load/store opcodes, the point stands that instruction fusion does not simplify decoding or increase code density the way a pre-fused instruction does.
    - brucehoult 5y ago
      "pre-fused" instructions use up a lot of opcode space that might be better used for other things. Complex addressing modes help code size if you've got just a single access to an array element in some straight line code, but they're seldom needed in loops because most of the calculation is best moved outside of the loop leaving just a simple pointer increment inside the loop.
- deleted 5y ago
  [deleted]
Symmetry 5y ago
No, there are certainly ISA related performance factors. RISC-V compressed instructions are easier to decode than x86 but you still need to detect boundaries and mux instructions to their proper lanes. And if you don't you have problems with i-cache pressure. In theory instruction fusion can do a lot to increase backend instruction density. But to equal other ISAs RISC-V have to be fusing triplets instead of just pairs and that's a quadratically harder problem. It's not the end of the world but I don't think it's an accident that x86, on of the simplest CISC ISAs, and ARM, one of the most complex RISC ISAs, ended up being dominant.

saagarjha 5y ago

https://gist.github.com/erincandescent/8a10eeeea1918ee4f9d9982f7618ef68 https://gist.github.com/erincandescent/8a10eeeea1918ee4f9d99...