5 ms·

Frist, we are talking about RISC-V. The ISA is not finished. So yes, it will take time, but that's not the point. > How long until that instruction is availabl

Frist, we are talking about RISC-V. The ISA is not finished. So yes, it will take time, but that's not the point. > How long until that instruction is available in all chips that are manufactured? Longer. The author didn't say it would take a long time, he said that "it won't be in the smaller chips". And "even in the biggest ones for a good while". But what is "for a good while" when nobody is already using RISC-V for performance?

AnimalMuppet 6y ago
In your last paragraph, you sound like you're agreeing with ncmncm (that it will be a while), but arguing that it doesn't matter. (Or are you arguing that we can't tell how to define "for a good while" because nobody is already using the chip for performance?)
- avianes 6y ago
  I agree that the transition to RISC-V (if it's going to happen) will take time, I do not agree that it will take even longer for the B extension. That's why I disagree with him.
brandmeyer 6y ago
> but that's not the point. Its 2020. We've known how RISC machine's evolve for 3 decades or so, yet RISC-V rewound the clock almost back to the beginning. "Let them eat extensions" is a recipe for fragmentation. MIPS actually experienced this in the field. ARM floating-point did for many years, too.
- andrekandre 6y ago
  > "Let them eat extensions" is a recipe for fragmentation. not neccessarily in machine mode (think firmware or hypervisor level) you can trap on unrecognized instructions and handle them retroactively in software), so maybe fragmentation wont be (at least technically) a big issue....
  - brandmeyer 6y ago
    I remember the awful days of fake hard-float support in ARMv4. Trapping to the kernel and doing soft float there was was 10x worse than just doing soft float in userspace in the first place. Now, imagine doing that for xor-and-rotate, or bitfield insert/extract. Or leading zero count, or indexed memory access. No. Thanks.
    - ncmncm 6y ago
      Exactly. Emulation would be even worse than omission. Putting in optimizations that make the slowest hardware run even slower is not the route to happy users.

AnimalMuppet 6y ago

In your last paragraph, you sound like you're agreeing with ncmncm (that it will be a while), but arguing that it doesn't matter. (Or are you arguing that we can't tell how to define "for a good while" because nobody is already using the chip for performance?)

avianes 6y ago
I agree that the transition to RISC-V (if it's going to happen) will take time, I do not agree that it will take even longer for the B extension. That's why I disagree with him.

brandmeyer 6y ago

> but that's not the point. Its 2020. We've known how RISC machine's evolve for 3 decades or so, yet RISC-V rewound the clock almost back to the beginning. "Let them eat extensions" is a recipe for fragmentation. MIPS actually experienced this in the field. ARM floating-point did for many years, too.

andrekandre 6y ago
> "Let them eat extensions" is a recipe for fragmentation. not neccessarily in machine mode (think firmware or hypervisor level) you can trap on unrecognized instructions and handle them retroactively in software), so maybe fragmentation wont be (at least technically) a big issue....
- brandmeyer 6y ago
  I remember the awful days of fake hard-float support in ARMv4. Trapping to the kernel and doing soft float there was was 10x worse than just doing soft float in userspace in the first place. Now, imagine doing that for xor-and-rotate, or bitfield insert/extract. Or leading zero count, or indexed memory access. No. Thanks.
  - ncmncm 6y ago
    Exactly. Emulation would be even worse than omission. Putting in optimizations that make the slowest hardware run even slower is not the route to happy users.