3 ms·

Except for proprietary extensions, I don't think it will be very different of the x86 world where processors can have a different number of cores, HT, MMX, 3dNo

Except for proprietary extensions, I don't think it will be very different of the x86 world where processors can have a different number of cores, HT, MMX, 3dNow!, SSE(1,2,3,4...), AMX... These extensions didn't destroy x86. I don't think it will be different with RISCV.

ncmncm 5y ago
It is very, very different. X86 extensions get added onto the sum total of almost all the previous extensions, so that the number of variations to support has grown about linearly with time. RISC-V extensions are more or less all independent, so that the number of variant targets explodes exponentially as they are added to.
- javajosh 5y ago
  >explodes exponentially Nit pick: it explodes factorially, which is worse than exponential. The superset of a set of N elts is N!. (If order is meaningful (unlikely here), it's slightly worse, which is all permutations of each member of the superset. But that's only ~exponential and is quickly swallowed by the factorial).
- deleted 5y ago
  [deleted]
- marcodiego 5y ago
  It is not different in the sense that my compiler can generate code that runs on RISC-V and runs faster on RISC-V with specific extensions. Binary compatibility, in practice, is not lost.
  - ncmncm 5y ago
    There is no requirement to execute instructions defined in an extension not supported. So, it means building for RISC-V is necessarily complicated. Worse, if it traps and emulates instructions, then optimizations using extension instructions become radical pessimizations.
    - avianes 5y ago
      Whatever the target processor is, when we need performance we recompile for that specific target. And whatever the target processor is, if you need portability you compile only with extensions widely used. It's the exact same problem with x86 or arm. So.. yes, currently RISC-V is mostly made of isolated extensions, but the goal is clearly to create groups of extensions that will be widely supported.

ncmncm 5y ago

It is very, very different. X86 extensions get added onto the sum total of almost all the previous extensions, so that the number of variations to support has grown about linearly with time. RISC-V extensions are more or less all independent, so that the number of variant targets explodes exponentially as they are added to.

javajosh 5y ago
>explodes exponentially Nit pick: it explodes factorially, which is worse than exponential. The superset of a set of N elts is N!. (If order is meaningful (unlikely here), it's slightly worse, which is all permutations of each member of the superset. But that's only ~exponential and is quickly swallowed by the factorial).
deleted 5y ago
[deleted]
marcodiego 5y ago
It is not different in the sense that my compiler can generate code that runs on RISC-V and runs faster on RISC-V with specific extensions. Binary compatibility, in practice, is not lost.
- ncmncm 5y ago
  There is no requirement to execute instructions defined in an extension not supported. So, it means building for RISC-V is necessarily complicated. Worse, if it traps and emulates instructions, then optimizations using extension instructions become radical pessimizations.
  - avianes 5y ago
    Whatever the target processor is, when we need performance we recompile for that specific target. And whatever the target processor is, if you need portability you compile only with extensions widely used. It's the exact same problem with x86 or arm. So.. yes, currently RISC-V is mostly made of isolated extensions, but the goal is clearly to create groups of extensions that will be widely supported.