4 ms·

The solution to this is not to split, but just follow Qualcomm. Their vision for the future of the ISA is simply much better than SiFive's. Right now, most dev

The solution to this is not to split, but just follow Qualcomm. Their vision for the future of the ISA is simply much better than SiFive's. Right now, most devices on the market do not support the C extension, and any code that tries to be compatible does not use it. Qualcomm wants to remove it because it is actively harmful for fast implementations, and burns 75% of the entire encoding space, which is already extremely tight. SiFive really wants to keep it. The solution to fragmentation is to just disable the C extension everywhere, but SiFive doesn't want to hear that.

camel-cdr 2y ago
> most devices on the market do not support the C extension Name one that doesn't, it's exactly the opposite (for 64-bit).
- GeorgeTirebiter 2y ago
  Maybe you've found the solution: RV32 must have the C extension. RV64 and RV128 must NOT have the C extension. Problem solved?
  - camel-cdr 2y ago
    No I meant, that for 64-bit CPUs virtually every available one supports the C extension.
sitkack 2y ago
> Right now, most devices on the market do not support the C extension This is not true and easily verifiable. The C extension is defacto required, the only cores that don't support it are special purpose soft cores. C extension in the smallest IP available core https://github.com/olofk/serv?tab=readme-ov-file https://github.com/olofk/serv?tab=readme-ov-file Supports M and C extensions https://github.com/YosysHQ/picorv32 https://github.com/YosysHQ/picorv32 Another sized optimized core with C extension support https://github.com/lowrisc/ibex https://github.com/lowrisc/ibex C extension in the 10 cent microcontroller https://www.wch-ic.com/products/CH32V003.html https://www.wch-ic.com/products/CH32V003.html This one should get your goat, it implements as much as it can using only compressed instructions https://github.com/gsmecher/minimax https://github.com/gsmecher/minimax
- FullyFunctional 2y ago
  The expansion of a 16-bit C insn to 32-bit isn't the problem. That part is trivial. The problem (and it is significant) is for a highly speculative superscalar machine that fetches 16+ instructions at a time but cannot tell the boundary of instructions until they are all decoded. Sure, it can be done, but that doesn't mean that it doesn't cost you in mispredict penalties (AKA IPC) and design/verification complexities that could have gone to performance. It is also true that burning up the encoding space for C means pain elsewhere. Example: branch and jump offsets are painfully small. So small that all non-toy code need to use a two instruction sequence to all call (and sometimes more). These problems don't show up on embedded processors and workloads. They matter for high performance.
  - camel-cdr 2y ago
    > me but cannot tell the boundary of instructions until they are all decoded Not fully decoded though, since it's enough to look at the lower bits to determine instruction size. > Sure, it can be done, but that doesn't mean that it doesn't cost you in mispredict penalties What does decoding have to do with mispredict penalties? > Example: branch and jump offsets are painfully small Yes, thats what the 48 bit instruction encoding is for. See e.g. what the scalar eficiency SIG is currently working on: https://docs.google.com/spreadsheets/u/0/d/1dQYU7QQ-SnIoXp9vVvVjS6Jz9vGWhwmsdbEOF3JBwUg/htmlview#gid=0 https://docs.google.com/spreadsheets/u/0/d/1dQYU7QQ-SnIoXp9v...
    - dzaima 2y ago
      Mispredict penalties == latency of pipeline. Needing to delay decoding/expansion to after figuring out where instructions actually start will necessarily add a delay of some number of gates (whether or not this ends up in mispredict penalty increasing by any cycles of course depend on many things). That said, the alternative of instruction fission (i.e. that which RISC-V avoids requiring) would add some delay too (I have no clue how these compare though, I'm not a hardware engineer; and RISC-V does benefit from instruction fusion which can similarly add latency, and whose requirement other architectures could decide to try to avoid (though it'd be harder to keep avoiding it as hardware potential improves while old compiled binary blobs stay unchanged), so it's complicated)
panick21_ 2y ago
> Right now, most devices on the market do not support the C extension That's outright false. And outside of the actual devices, the whole software ecosystem very much uses the C extension. Qualcomm simply wants to break the standard to make money, that literally all it is. > Qualcomm wants to remove it because it is actively harmful for fast implementations Funny how not a single company other then Qualcomm argues this. Not Ventara, not Si-Five, not Esperanto, not Tenstorrent, non of the companies form China. Its almost, almost as if it not that big of a deal and Qualcomm simply want to same money and reuse ARM IP. > The solution to fragmentation is to just disable the C extension everywhere, but SiFive doesn't want to hear that. Literally nobody except Qualcomm wants to hear it. It wasn't even a discussion before Qualcomm. All the other companies had plenty of opportunity to bring up issues in all the working groups, and nobody did. Literally not a single company gave a talk, talking about how the C extension was holding them back. In fact most of them were saying the opposite.
- FullyFunctional 2y ago
  There is a lot of stuff behind the scene you don't know. You statement about "other companies" is completely wrong.
  - camel-cdr 2y ago
    pray tell
  - panick21_ 2y ago
    These things are supposed to be discuss in the open, its an open standards process. So please link me to the official statements by these companies that they are unhappy. I have watched many discussions and updates by the work-groups, and nobody came forward. And why are they afraid to come forward? If this is so important then shouldn't there be an effort to convince the community? So sorry until I see something other claims like 'there is a shadow cabal of unhappy companies planning a takeover' I'm not gone buy that this is widespread movement.
    - 2y ago
timschmidt 2y ago
> Qualcomm wants to remove it because it is actively harmful for fast implementations Qualcomm's "fast implementation" reportedly started out life as an ARM core and has had it's decoders replaced. That explanation makes their very different use of the instruction space make much more sense to me than any other. They did the minimum to adapt an existing design. Not the stuff of lasting engineering.
brucehoult 2y ago
> Right now, most devices on the market do not support the C extension, and any code that tries to be compatible does not use it. I don't know of ANY commercially-sold RISC-V chips that don't implement the C extension. Even the 10 cent CH32V003 implements C (RV32EC). > burns 75% of the entire encoding space In ARMv7 the 2-byte original Thumb instructions burn 87.5% of the 4-byte encoding space (28 out of 32 combinations of the 5 MSBs).

camel-cdr 2y ago

> most devices on the market do not support the C extension Name one that doesn't, it's exactly the opposite (for 64-bit).

GeorgeTirebiter 2y ago
Maybe you've found the solution: RV32 must have the C extension. RV64 and RV128 must NOT have the C extension. Problem solved?
- camel-cdr 2y ago
  No I meant, that for 64-bit CPUs virtually every available one supports the C extension.

sitkack 2y ago

> Right now, most devices on the market do not support the C extension This is not true and easily verifiable. The C extension is defacto required, the only cores that don't support it are special purpose soft cores. C extension in the smallest IP available core https://github.com/olofk/serv?tab=readme-ov-file https://github.com/olofk/serv?tab=readme-ov-file Supports M and C extensions https://github.com/YosysHQ/picorv32 https://github.com/YosysHQ/picorv32 Another sized optimized core with C extension support https://github.com/lowrisc/ibex https://github.com/lowrisc/ibex C extension in the 10 cent microcontroller https://www.wch-ic.com/products/CH32V003.html https://www.wch-ic.com/products/CH32V003.html This one should get your goat, it implements as much as it can using only compressed instructions https://github.com/gsmecher/minimax https://github.com/gsmecher/minimax

FullyFunctional 2y ago
The expansion of a 16-bit C insn to 32-bit isn't the problem. That part is trivial. The problem (and it is significant) is for a highly speculative superscalar machine that fetches 16+ instructions at a time but cannot tell the boundary of instructions until they are all decoded. Sure, it can be done, but that doesn't mean that it doesn't cost you in mispredict penalties (AKA IPC) and design/verification complexities that could have gone to performance. It is also true that burning up the encoding space for C means pain elsewhere. Example: branch and jump offsets are painfully small. So small that all non-toy code need to use a two instruction sequence to all call (and sometimes more). These problems don't show up on embedded processors and workloads. They matter for high performance.
- camel-cdr 2y ago
  > me but cannot tell the boundary of instructions until they are all decoded Not fully decoded though, since it's enough to look at the lower bits to determine instruction size. > Sure, it can be done, but that doesn't mean that it doesn't cost you in mispredict penalties What does decoding have to do with mispredict penalties? > Example: branch and jump offsets are painfully small Yes, thats what the 48 bit instruction encoding is for. See e.g. what the scalar eficiency SIG is currently working on: https://docs.google.com/spreadsheets/u/0/d/1dQYU7QQ-SnIoXp9vVvVjS6Jz9vGWhwmsdbEOF3JBwUg/htmlview#gid=0 https://docs.google.com/spreadsheets/u/0/d/1dQYU7QQ-SnIoXp9v...
  - dzaima 2y ago
    Mispredict penalties == latency of pipeline. Needing to delay decoding/expansion to after figuring out where instructions actually start will necessarily add a delay of some number of gates (whether or not this ends up in mispredict penalty increasing by any cycles of course depend on many things). That said, the alternative of instruction fission (i.e. that which RISC-V avoids requiring) would add some delay too (I have no clue how these compare though, I'm not a hardware engineer; and RISC-V does benefit from instruction fusion which can similarly add latency, and whose requirement other architectures could decide to try to avoid (though it'd be harder to keep avoiding it as hardware potential improves while old compiled binary blobs stay unchanged), so it's complicated)

panick21_ 2y ago

> Right now, most devices on the market do not support the C extension That's outright false. And outside of the actual devices, the whole software ecosystem very much uses the C extension. Qualcomm simply wants to break the standard to make money, that literally all it is. > Qualcomm wants to remove it because it is actively harmful for fast implementations Funny how not a single company other then Qualcomm argues this. Not Ventara, not Si-Five, not Esperanto, not Tenstorrent, non of the companies form China. Its almost, almost as if it not that big of a deal and Qualcomm simply want to same money and reuse ARM IP. > The solution to fragmentation is to just disable the C extension everywhere, but SiFive doesn't want to hear that. Literally nobody except Qualcomm wants to hear it. It wasn't even a discussion before Qualcomm. All the other companies had plenty of opportunity to bring up issues in all the working groups, and nobody did. Literally not a single company gave a talk, talking about how the C extension was holding them back. In fact most of them were saying the opposite.

FullyFunctional 2y ago
There is a lot of stuff behind the scene you don't know. You statement about "other companies" is completely wrong.
- camel-cdr 2y ago
  pray tell
- panick21_ 2y ago
  These things are supposed to be discuss in the open, its an open standards process. So please link me to the official statements by these companies that they are unhappy. I have watched many discussions and updates by the work-groups, and nobody came forward. And why are they afraid to come forward? If this is so important then shouldn't there be an effort to convince the community? So sorry until I see something other claims like 'there is a shadow cabal of unhappy companies planning a takeover' I'm not gone buy that this is widespread movement.
  - 2y ago

timschmidt 2y ago

> Qualcomm wants to remove it because it is actively harmful for fast implementations Qualcomm's "fast implementation" reportedly started out life as an ARM core and has had it's decoders replaced. That explanation makes their very different use of the instruction space make much more sense to me than any other. They did the minimum to adapt an existing design. Not the stuff of lasting engineering.

brucehoult 2y ago

> Right now, most devices on the market do not support the C extension, and any code that tries to be compatible does not use it. I don't know of ANY commercially-sold RISC-V chips that don't implement the C extension. Even the 10 cent CH32V003 implements C (RV32EC). > burns 75% of the entire encoding space In ARMv7 the 2-byte original Thumb instructions burn 87.5% of the 4-byte encoding space (28 out of 32 combinations of the 5 MSBs).