5 ms·

How close is RISC-V to RISC-I? (2017)

73 points by cpeterso 4y ago

kragen 4y ago
Much closer than I would have expected. But what's this about RISC-V not having a jump with a register and offset address? Doesn't JALR have a 12-bit offset that's added to the base register rs1? How is that different from RISC-I's JMP COND, S2(Rx)? Does COND mean the jump is conditional, like JMPR EQ? Interestingly since this article most of the "In RISC-V, but not RISC-I" instructions have been moved to extensions: Zicsr for the CSR instructions and Zifencei for the FENCE.I instruction (which turns out not to be useful for user processes running on a multicore processor with a multitasking OS like FreeBSD or Linux). That leaves only AUIPC, SBREAK (now called EBREAK), and FENCE. So it's even closer now than it was in 02017.
- Dylan16807 4y ago
  > Does COND mean the jump is conditional, like JMPR EQ? Yes. The better generic description would have been Branch with register + offset but the RISC-I specific language uses "Jump" for everything.
  - kragen 4y ago
    So what's missing is conditional branch to a runtime-computed address.
Y_Y 4y ago
Had anyone tried to find (or derive) an ideal set of instructions for a processor architecture, with any assumptions about arithmetic etc? For example you can try to minimise the number of instructions it takes to encode some set of nontrivial programs. (Of course how this would translate to silicon is another question.)
- artemonster 4y ago
  Ideal in what regard? Easy to code for humans or generate for compilers? Code size or decoding simlicity? Parallelism or cache friendliness? Energy efficiency or low cpi? Flexibility? Future-proofness or backward compatibility? In theory you only need one instruction (subleq), everything else is a highly narrow optimization attempt.
- retrac 4y ago
  In terms of length and density at least, the optimal solution is something like compression with Huffman coding, as it is fundamentally a compression question, where we want to represent the most frequent operations and operands with the fewest bits, on average. As with any question of compression, the optimal format will depend on the nature of the compressed data. So at least in that domain, there is no truly ideal solution, only approximately ideal solutions. (The approximately ideal solution is quite good though -- in practice Huffman-encoded instructions for stack machines with a rich operation set based on an average instruction mix, come around 4 bits per instruction on average, IIRC. I've seen the approach used with a VM interpreter on a memory-constrained embedded system to pack in more code.) I suspect the same is true of other criteria you might select for what makes an ideal instruction set; it's always going to be some compromising trade-offs, some of which depend on runtime properties like actual instruction mix.
  - zogomoox 4y ago
    Would it be possible to have fast stack machine CPUs nowadays? (let's say, competing with x64 cpu's) or is there some inherent benefit to register machines?
    - Taniwha 4y ago
      I think that one of the main issues with stack machines is that the order of instructions in the original instruction stream is constrained by the instruction format - you can't as easy software schedule instructions (harder to express "I have all the information required to load that value from memory around now, I'll start it now because it might take a while"). Now any high performance stack machine is likely to decompose stack code to register renaming and micro-ops so some of that stuff is going to happen anyway (as it would in a register machine) and some stack ops (like dup) are going to disappear into the renamer (but then a compiler would do that as a CSE on a register machine)
Sniffnoy 4y ago
Why is this an archive.org link? The page is still up: https://aspire.eecs.berkeley.edu/2017/06/how-close-is-risc-v-to-risc-i/ https://aspire.eecs.berkeley.edu/2017/06/how-close-is-risc-v...

73 points by cpeterso 4y ago

Much closer than I would have expected. But what's this about RISC-V not having a jump with a register and offset address? Doesn't JALR have a 12-bit offset that's added to the base register rs1? How is that different from RISC-I's JMP COND, S2(Rx)? Does COND mean the jump is conditional, like JMPR EQ? Interestingly since this article most of the "In RISC-V, but not RISC-I" instructions have been moved to extensions: Zicsr for the CSR instructions and Zifencei for the FENCE.I instruction (which turns out not to be useful for user processes running on a multicore processor with a multitasking OS like FreeBSD or Linux). That leaves only AUIPC, SBREAK (now called EBREAK), and FENCE. So it's even closer now than it was in 02017.

Dylan16807 4y ago
> Does COND mean the jump is conditional, like JMPR EQ? Yes. The better generic description would have been Branch with register + offset but the RISC-I specific language uses "Jump" for everything.
- kragen 4y ago
  So what's missing is conditional branch to a runtime-computed address.

Y_Y 4y ago

Had anyone tried to find (or derive) an ideal set of instructions for a processor architecture, with any assumptions about arithmetic etc? For example you can try to minimise the number of instructions it takes to encode some set of nontrivial programs. (Of course how this would translate to silicon is another question.)

artemonster 4y ago
Ideal in what regard? Easy to code for humans or generate for compilers? Code size or decoding simlicity? Parallelism or cache friendliness? Energy efficiency or low cpi? Flexibility? Future-proofness or backward compatibility? In theory you only need one instruction (subleq), everything else is a highly narrow optimization attempt.
retrac 4y ago
In terms of length and density at least, the optimal solution is something like compression with Huffman coding, as it is fundamentally a compression question, where we want to represent the most frequent operations and operands with the fewest bits, on average. As with any question of compression, the optimal format will depend on the nature of the compressed data. So at least in that domain, there is no truly ideal solution, only approximately ideal solutions. (The approximately ideal solution is quite good though -- in practice Huffman-encoded instructions for stack machines with a rich operation set based on an average instruction mix, come around 4 bits per instruction on average, IIRC. I've seen the approach used with a VM interpreter on a memory-constrained embedded system to pack in more code.) I suspect the same is true of other criteria you might select for what makes an ideal instruction set; it's always going to be some compromising trade-offs, some of which depend on runtime properties like actual instruction mix.
- zogomoox 4y ago
  Would it be possible to have fast stack machine CPUs nowadays? (let's say, competing with x64 cpu's) or is there some inherent benefit to register machines?
  - Taniwha 4y ago
    I think that one of the main issues with stack machines is that the order of instructions in the original instruction stream is constrained by the instruction format - you can't as easy software schedule instructions (harder to express "I have all the information required to load that value from memory around now, I'll start it now because it might take a while"). Now any high performance stack machine is likely to decompose stack code to register renaming and micro-ops so some of that stuff is going to happen anyway (as it would in a register machine) and some stack ops (like dup) are going to disappear into the renamer (but then a compiler would do that as a CSE on a register machine)

Sniffnoy 4y ago

Why is this an archive.org link? The page is still up: https://aspire.eecs.berkeley.edu/2017/06/how-close-is-risc-v-to-risc-i/ https://aspire.eecs.berkeley.edu/2017/06/how-close-is-risc-v...