6 ms·

RISC-V Board of Directors decision on the Compressed extension

15 points by rwmj 3y ago

rwmj 3y ago
RISC-V Profiles is a technical working group of RISC-V International which decides on a common set of extensions that hardware in particular profiles (eg. application servers) must implement. Recently there has been some rather heated discussion of the Compressed extension. The C extension adds 16 bit instructions, somewhat like Thumb on armv7. Larger server vendors argued that the C extension made it harder to verify implementations and proposed alternatives. Other RVI members argued that dropping C would effectively split the standard (especially if the space used by the C extension was reused for other things). Unexpectedly the Board of Directors stepped in to make this decision yesterday. This doesn't preclude another profile (eg. "high end servers") being created in future.
- snvzz 3y ago
  >Larger server vendors argued Uh no. Let's set the record straight: It was proposed by Qualcomm, and only Qualcomm presented a case against C, which was quickly and thoroughly shot down by SiFive[0]. During the discussion, it became apparent that Qualcomm was only having issues because they tried to swap the frontend of the ARM core they got from Nuvia with the minimal amount of effort. This end result shows that RISC-V Board is strong and won't be easily derailed by one of its member companies. 0. https://lists.riscv.org/g/tech-profiles/attachment/353/0/RISCV-20231004-C.pdf https://lists.riscv.org/g/tech-profiles/attachment/353/0/RIS...
  - brucehoult 3y ago
    > it became apparent As fact? Certainly I've seen (and repeated) speculation that this might be the case.
  - monocasa 3y ago
    I heard rumors that Rivos was tentatively on board as well, but yeah, very little support.
    - snvzz 3y ago
      >I heard rumors that Rivos Yes, I saw this rumor too. Rivos actually appeared in the conversation to basically give the polite equivalent of "don't put words in our mouth". It turned out, the rumor was made up.
      - monocasa 3y ago
        Good to know, thanks. Doubly so right that the effort to remove RV-C failed then.
camel-cdr 3y ago
Great to see this finally resolved. The working group was about to collect data that could've been interesting, but the time this could/would take was undetermined. It would've also been questionable because all parties that could do the measurements (IP vendors) are biased. The Samsung talk about Zc on the risc-v summit was also supposed to show performance improvements for the Zc side. We'll probably get the YouTube upload at the end of the month. There is still space for a seperate profile without 16 bit instructions, so we'll have to see how that develops.
- snvzz 3y ago
  >There is still space for a seperate profile without 16 bit instructions, so we'll have to see how that develops. To be clear: RISC-V does also support instructions above 32bit. This was stressed during the discussion. Qualcomm's focus in the discussion seemed to be to have RVA23 be a fixed size ISA. They failed to convince the board, as the ISA's variable size was designed to be very easy for a hardware decoder implementation to deal with, unlike m68k or x86. To provide some practical real world RISC-V hardware examples, SiFive P870 is 6-wide, Tenstorrent Ascalon is 8-wide, Ventana Veyron V2 seems to be 12-wide. Whereas modern x86 microarchitectures seem to be 4-wide and struggling to break into 6-wide, while the largest ARM aarch64 (which is fixed 32bit size) microarchitectures, Apple's M1/M2/M3, are 8-wide.
  - RaisingSpear 3y ago
    Modern x86 (Golden Cove, Zen 3/4) is currently 6 wide. [https://i0.wp.com/chipsandcheese.com/wp-content/uploads/2021/11/goldencove.drawio3.png?ssl=1 https://i0.wp.com/chipsandcheese.com/wp-content/uploads/2021...] A17/M3 is 9 wide [https://files.catbox.moe/vkbop7.png https://files.catbox.moe/vkbop7.png] From what I've heard, Veyron V2 has only 4 wide rename.
    - snvzz 3y ago
      Zen4 is 4-wide[0]. I understand Zen2 (and thus 3) are also 4-wide. I do not know about Intel's designs. Has Apple officially published these details about M3? 0. https://en.wikichip.org/wiki/amd/microarchitectures/zen_4 https://en.wikichip.org/wiki/amd/microarchitectures/zen_4
brucehoult 3y ago
It was never going to go any other way for the RVA* profiles. Qualcomm’s other proposal to add a standard extension with more complex (Aarch64-like) instructions to the ISA should be a totally independent question. There is plenty of room for it in the ISA, people can choose to implement it or not, and if more than one vendor wants such an extension then it makes sense to standardize it. ISA is one thing. Providing alternative extensions that implementors can choose between according to their needs is a good thing. Profiles — that is a set of extensions for a particular application space, which vendors must implement and shrink-wrapped software can depend on — is a totally different thing, which MUST have strong backward compatibility guarantees. The right decision has been made concerning the RVA* profile series. I hope this doesn’t preclude discussion regarding a standard extension to the ISA.
- deleted 3y ago
  [deleted]

15 points by rwmj 3y ago

rwmj 3y ago

RISC-V Profiles is a technical working group of RISC-V International which decides on a common set of extensions that hardware in particular profiles (eg. application servers) must implement. Recently there has been some rather heated discussion of the Compressed extension. The C extension adds 16 bit instructions, somewhat like Thumb on armv7. Larger server vendors argued that the C extension made it harder to verify implementations and proposed alternatives. Other RVI members argued that dropping C would effectively split the standard (especially if the space used by the C extension was reused for other things). Unexpectedly the Board of Directors stepped in to make this decision yesterday. This doesn't preclude another profile (eg. "high end servers") being created in future.

snvzz 3y ago
>Larger server vendors argued Uh no. Let's set the record straight: It was proposed by Qualcomm, and only Qualcomm presented a case against C, which was quickly and thoroughly shot down by SiFive[0]. During the discussion, it became apparent that Qualcomm was only having issues because they tried to swap the frontend of the ARM core they got from Nuvia with the minimal amount of effort. This end result shows that RISC-V Board is strong and won't be easily derailed by one of its member companies. 0. https://lists.riscv.org/g/tech-profiles/attachment/353/0/RISCV-20231004-C.pdf https://lists.riscv.org/g/tech-profiles/attachment/353/0/RIS...
- brucehoult 3y ago
  > it became apparent As fact? Certainly I've seen (and repeated) speculation that this might be the case.
- monocasa 3y ago
  I heard rumors that Rivos was tentatively on board as well, but yeah, very little support.
  - snvzz 3y ago
    >I heard rumors that Rivos Yes, I saw this rumor too. Rivos actually appeared in the conversation to basically give the polite equivalent of "don't put words in our mouth". It turned out, the rumor was made up.
    - monocasa 3y ago
      Good to know, thanks. Doubly so right that the effort to remove RV-C failed then.

camel-cdr 3y ago

Great to see this finally resolved. The working group was about to collect data that could've been interesting, but the time this could/would take was undetermined. It would've also been questionable because all parties that could do the measurements (IP vendors) are biased. The Samsung talk about Zc on the risc-v summit was also supposed to show performance improvements for the Zc side. We'll probably get the YouTube upload at the end of the month. There is still space for a seperate profile without 16 bit instructions, so we'll have to see how that develops.

snvzz 3y ago
>There is still space for a seperate profile without 16 bit instructions, so we'll have to see how that develops. To be clear: RISC-V does also support instructions above 32bit. This was stressed during the discussion. Qualcomm's focus in the discussion seemed to be to have RVA23 be a fixed size ISA. They failed to convince the board, as the ISA's variable size was designed to be very easy for a hardware decoder implementation to deal with, unlike m68k or x86. To provide some practical real world RISC-V hardware examples, SiFive P870 is 6-wide, Tenstorrent Ascalon is 8-wide, Ventana Veyron V2 seems to be 12-wide. Whereas modern x86 microarchitectures seem to be 4-wide and struggling to break into 6-wide, while the largest ARM aarch64 (which is fixed 32bit size) microarchitectures, Apple's M1/M2/M3, are 8-wide.
- RaisingSpear 3y ago
  Modern x86 (Golden Cove, Zen 3/4) is currently 6 wide. [https://i0.wp.com/chipsandcheese.com/wp-content/uploads/2021/11/goldencove.drawio3.png?ssl=1 https://i0.wp.com/chipsandcheese.com/wp-content/uploads/2021...] A17/M3 is 9 wide [https://files.catbox.moe/vkbop7.png https://files.catbox.moe/vkbop7.png] From what I've heard, Veyron V2 has only 4 wide rename.
  - snvzz 3y ago
    Zen4 is 4-wide[0]. I understand Zen2 (and thus 3) are also 4-wide. I do not know about Intel's designs. Has Apple officially published these details about M3? 0. https://en.wikichip.org/wiki/amd/microarchitectures/zen_4 https://en.wikichip.org/wiki/amd/microarchitectures/zen_4

brucehoult 3y ago

It was never going to go any other way for the RVA* profiles. Qualcomm’s other proposal to add a standard extension with more complex (Aarch64-like) instructions to the ISA should be a totally independent question. There is plenty of room for it in the ISA, people can choose to implement it or not, and if more than one vendor wants such an extension then it makes sense to standardize it. ISA is one thing. Providing alternative extensions that implementors can choose between according to their needs is a good thing. Profiles — that is a set of extensions for a particular application space, which vendors must implement and shrink-wrapped software can depend on — is a totally different thing, which MUST have strong backward compatibility guarantees. The right decision has been made concerning the RVA* profile series. I hope this doesn’t preclude discussion regarding a standard extension to the ISA.

deleted 3y ago
[deleted]