4 ms·

Completely right. There is very little room to complain about what RISC-V does have, in RV32I/RV64I or even RV32G/RV64G. The core ISA works just fine and its p

Completely right. There is very little room to complain about what RISC-V does have, in RV32I/RV64I or even RV32G/RV64G. The core ISA works just fine and its primary attribute is that everyone is legally free to use and build on it, and that there is a large and growing body of software that runs on it. The complaints are about things it doesn't have. No carry bit. No complex addressing modes. That kind of thing. If someone proves that those actually matter, for example by building a CPU with custom instructions that blows away everyone else's, then those can be added to RISC-V. There should never be any reason to need a "RISC-VI". I'm actually quite sympathetic to Qualcomm's proposal to add some of the things Aarch64 has, as an optional but standardised extension. On the other hand I'm completely against the second part of their proposal, to do a "big bang" replacement of the C extension with their extension in e.g. the RVA23 profile.

saagarjha 3y ago
Well there is the chance that you might not want to advertise your processor as supporting "RISC-V" if it means that someone else's extensions are not the same as yours.
- snvzz 3y ago
  Custom extensions go into custom space. RISC-V cares about its trademarks; a non-compliant core would not be allowed to use them.
  - saagarjha 3y ago
    That's not what I mean. I'm saying that if someone makes a program that uses custom extensions, they might label it as "RISC-V" but it doesn't actually work on my machine. Of course other ISAs also have extensions, but they are standard and programs typically check for them before using them. Does RISC-V have a way of looking for which extensions are available? Especially if there are a lot of entities that can implement them?
    - snvzz 3y ago
      The ISA spec does indeed have a sane, easy to understand method. The rest is a software problem. I know that e.g. Linux exposes the required information about the CPU's ISA via a dedicated syscall. I do not know whether there's some ELF header or the like.
      - camel-cdr 3y ago
        It does? Isn't it read the device tree isa string, the csr bits for the most common things, or catch the trap on illegal instruction?
mbitsnbites 3y ago
I think that companies will continue to suggest a "big bang" that involves supporting integer instructions with three source operands and possibly dropping compressed instructions. Maybe it's out of selfishness (e.g. because they are repurposing an existing microarchitecture for RISC-V), or maybe it's because that's how they want to build their hardware (e.g. for their particular performance target decoding a plain-old 32-bit instruction may be more silicon/power efficient than to fuse 2-3 16-bit instructions). Whatever the reasons, I think that RISC-V will have to live with this critique for as long as it lives. I'm not saying that those are poor design choices, but they will always be pain points (for small cores and big cores alike - but for different reasons). I don't think that you should underestimate the drive to modify an architecture if it does not fit your needs - especially if it is a free and open architecture like RISC-V. For example LoongArch has already happened, and I can easily see how something similar can happen if a major player decides to move from x86 or ARM to "something else" (e.g. if NVIDIA wants full control over their next gen super AI solution).
- snvzz 3y ago
  >(e.g. because they are repurposing an existing microarchitecture for RISC-V) I don't think we'll see a repeat of Qualcomm's attempt. This was a very special situation that they ended up with the NUVIA purchase/ARM lawsuit fiasco. Fortunately, RISC-V foundation handled the situation well. As RISC-V continues to grow exponentially, an unlikely later attempt will meet even stronger resistance, not just from the set precedent, but from the larger already deployed ecosystem of software and hardware.

saagarjha 3y ago

Well there is the chance that you might not want to advertise your processor as supporting "RISC-V" if it means that someone else's extensions are not the same as yours.

snvzz 3y ago
Custom extensions go into custom space. RISC-V cares about its trademarks; a non-compliant core would not be allowed to use them.
- saagarjha 3y ago
  That's not what I mean. I'm saying that if someone makes a program that uses custom extensions, they might label it as "RISC-V" but it doesn't actually work on my machine. Of course other ISAs also have extensions, but they are standard and programs typically check for them before using them. Does RISC-V have a way of looking for which extensions are available? Especially if there are a lot of entities that can implement them?
  - snvzz 3y ago
    The ISA spec does indeed have a sane, easy to understand method. The rest is a software problem. I know that e.g. Linux exposes the required information about the CPU's ISA via a dedicated syscall. I do not know whether there's some ELF header or the like.
    - camel-cdr 3y ago
      It does? Isn't it read the device tree isa string, the csr bits for the most common things, or catch the trap on illegal instruction?

mbitsnbites 3y ago

I think that companies will continue to suggest a "big bang" that involves supporting integer instructions with three source operands and possibly dropping compressed instructions. Maybe it's out of selfishness (e.g. because they are repurposing an existing microarchitecture for RISC-V), or maybe it's because that's how they want to build their hardware (e.g. for their particular performance target decoding a plain-old 32-bit instruction may be more silicon/power efficient than to fuse 2-3 16-bit instructions). Whatever the reasons, I think that RISC-V will have to live with this critique for as long as it lives. I'm not saying that those are poor design choices, but they will always be pain points (for small cores and big cores alike - but for different reasons). I don't think that you should underestimate the drive to modify an architecture if it does not fit your needs - especially if it is a free and open architecture like RISC-V. For example LoongArch has already happened, and I can easily see how something similar can happen if a major player decides to move from x86 or ARM to "something else" (e.g. if NVIDIA wants full control over their next gen super AI solution).

snvzz 3y ago
>(e.g. because they are repurposing an existing microarchitecture for RISC-V) I don't think we'll see a repeat of Qualcomm's attempt. This was a very special situation that they ended up with the NUVIA purchase/ARM lawsuit fiasco. Fortunately, RISC-V foundation handled the situation well. As RISC-V continues to grow exponentially, an unlikely later attempt will meet even stronger resistance, not just from the set precedent, but from the larger already deployed ecosystem of software and hardware.