3 ms·

There's been interesting related discussion in lobsters[0]. Turns out many of these "mistakes" are actually sensible decisions. 0. https://lobste.rs/s/v8xovv/h

by snvzz 3y ago

There's been interesting related discussion in lobsters[0]. Turns out many of these "mistakes" are actually sensible decisions. 0. https://lobste.rs/s/v8xovv/how_design_isa https://lobste.rs/s/v8xovv/how_design_isa

IshKebab 3y ago
Thanks for the link. I don't think you can conclude that from the discussion at all. The comment (https://lobste.rs/s/v8xovv/how_design_isa#c_pluxuy https://lobste.rs/s/v8xovv/how_design_isa#c_pluxuy) about JALR doesn't convince me. Yes you can use other registers for millicode and coroutines, but that is also baked into the ABI. See "Return-address stack prediction hints encoded in the register operands of a JALR instruction." in the unprivileged spec. It's an argument for supporting 2 link registers, not 32. I suppose you could argue "but there might be a future use that needs 3!" but it's definitely not clear cut. I haven't seen a solid defence for the lack of conditional move or advanced addressing modes either. Also the inclusion of compressed instructions in RVA22/23 seems to be a mistake: https://lists.riscv.org/g/tech-profiles/topic/101741936#297 https://lists.riscv.org/g/tech-profiles/topic/101741936#297 I don't think Qualcomm have published their proposal & benchmarks in full, but I can the pain of compressed instructions is very very very high so it would be worth removing them from RVA22/23 even if there is a slight performance penalty. Though it is probably too late realistically, since the profiles are meant to be backwards compatible. Overall I still think these are pretty minor mistakes and RISC-V is a nice ISA.
- brucehoult 3y ago
  > I haven't seen a solid defence for the lack of conditional move or advanced addressing modes either. That's backwards. It's the people who want those who need to prove they make a significant difference, and not just with hand-waving but with actual chips and data. "Everyone else does it" is not data. Thus far, RISC-V cores come in very competitive and even faster than Arm cores with similar µarch e.g. SiFive U74 vs Arm A55, or THead C910 vs Arm A72. > the pain of compressed instructions is very very very high Only for people who bought a company with a fast Aarch64 core that Arm is suing them over using so are trying to convert it to be a RISC-V core instead, with minimal work. The companies that are designing fast and wide RISC-V cores from scratch (Ventana, Tenstorrent, Rivos, ...) are saying the C extension is no big deal to implement, and of course does have real advantages in static and dynamic code size, icache size / performance / bandwidth etc. The discussion you referenced has Qualcomm claiming Rivos is also against the C extension, and then a Rivos person coming back saying "Hang on just a minute ... we're fine with C, we're just open-minded enough to want to see real data on your proposal".
  - IshKebab 3y ago
    > THead C910 This has an extensions that support conditional move and indexed memory access :-D See https://sourceware.org/binutils/docs/as/RISC_002dV_002dCustomExts.html https://sourceware.org/binutils/docs/as/RISC_002dV_002dCusto... In any case you aren't going to be able to see the benefit by comparing totally different cores. There are too many other factors. The article says: > Arm considered eliminating predicated execution entirely, but conditional move and a few other conditional instructions provided such a large performance win that Arm kept them. It would definitely be great to see numbers here but I see no reason to doubt that. > Only for people who bought a company with a fast Aarch64 core that Arm is suing them over using so are trying to convert it to be a RISC-V core instead, with minimal work. I'm not sure what you are talking about here. I was referring to the fact that the C extension means uncompressed instructions may not be naturally aligned which leads to all sorts of complexities, e.g. fetching instructions that are split over a page boundary, different PMA regions, different PMP regions, etc. It adds a lot of complexity to CHERI too. It's not a "big deal" to implement, but it does add significant complexity which would have been nice to avoid if it wasn't actually necessary.
    - camel-cdr 3y ago
      > This has an extensions that support conditional move and indexed memory access :-D RISC-V has Zicond now.

by snvzz 3y ago

IshKebab 3y ago

Thanks for the link. I don't think you can conclude that from the discussion at all. The comment (https://lobste.rs/s/v8xovv/how_design_isa#c_pluxuy https://lobste.rs/s/v8xovv/how_design_isa#c_pluxuy) about JALR doesn't convince me. Yes you can use other registers for millicode and coroutines, but that is also baked into the ABI. See "Return-address stack prediction hints encoded in the register operands of a JALR instruction." in the unprivileged spec. It's an argument for supporting 2 link registers, not 32. I suppose you could argue "but there might be a future use that needs 3!" but it's definitely not clear cut. I haven't seen a solid defence for the lack of conditional move or advanced addressing modes either. Also the inclusion of compressed instructions in RVA22/23 seems to be a mistake: https://lists.riscv.org/g/tech-profiles/topic/101741936#297 https://lists.riscv.org/g/tech-profiles/topic/101741936#297 I don't think Qualcomm have published their proposal & benchmarks in full, but I can the pain of compressed instructions is very very very high so it would be worth removing them from RVA22/23 even if there is a slight performance penalty. Though it is probably too late realistically, since the profiles are meant to be backwards compatible. Overall I still think these are pretty minor mistakes and RISC-V is a nice ISA.

brucehoult 3y ago
> I haven't seen a solid defence for the lack of conditional move or advanced addressing modes either. That's backwards. It's the people who want those who need to prove they make a significant difference, and not just with hand-waving but with actual chips and data. "Everyone else does it" is not data. Thus far, RISC-V cores come in very competitive and even faster than Arm cores with similar µarch e.g. SiFive U74 vs Arm A55, or THead C910 vs Arm A72. > the pain of compressed instructions is very very very high Only for people who bought a company with a fast Aarch64 core that Arm is suing them over using so are trying to convert it to be a RISC-V core instead, with minimal work. The companies that are designing fast and wide RISC-V cores from scratch (Ventana, Tenstorrent, Rivos, ...) are saying the C extension is no big deal to implement, and of course does have real advantages in static and dynamic code size, icache size / performance / bandwidth etc. The discussion you referenced has Qualcomm claiming Rivos is also against the C extension, and then a Rivos person coming back saying "Hang on just a minute ... we're fine with C, we're just open-minded enough to want to see real data on your proposal".
- IshKebab 3y ago
  > THead C910 This has an extensions that support conditional move and indexed memory access :-D See https://sourceware.org/binutils/docs/as/RISC_002dV_002dCustomExts.html https://sourceware.org/binutils/docs/as/RISC_002dV_002dCusto... In any case you aren't going to be able to see the benefit by comparing totally different cores. There are too many other factors. The article says: > Arm considered eliminating predicated execution entirely, but conditional move and a few other conditional instructions provided such a large performance win that Arm kept them. It would definitely be great to see numbers here but I see no reason to doubt that. > Only for people who bought a company with a fast Aarch64 core that Arm is suing them over using so are trying to convert it to be a RISC-V core instead, with minimal work. I'm not sure what you are talking about here. I was referring to the fact that the C extension means uncompressed instructions may not be naturally aligned which leads to all sorts of complexities, e.g. fetching instructions that are split over a page boundary, different PMA regions, different PMP regions, etc. It adds a lot of complexity to CHERI too. It's not a "big deal" to implement, but it does add significant complexity which would have been nice to avoid if it wasn't actually necessary.
  - camel-cdr 3y ago
    > This has an extensions that support conditional move and indexed memory access :-D RISC-V has Zicond now.