5 ms·

> it won't be in the smaller chips, or even in the biggest ones for a good while. Where does this statement come from? Do you have any sources or arguments to

> it won't be in the smaller chips, or even in the biggest ones for a good while. Where does this statement come from? Do you have any sources or arguments to justify that?

AnimalMuppet 6y ago
I'm not the one you're asking. But... there's many a slip between spec and chip. That is, creating a spec that says that it includes a POPCOUNT instruction is easier (except perhaps for politics and bureaucracy) than actually implementing one in a chip, going through layout, producing masks, and starting production. Then it takes a while for those chips to work their way through the supply chain to general availability. How long? I don't know. But I suspect that it's a non-trivial amount of time. How long until that instruction is available in all chips that are manufactured? Longer.
- avianes 6y ago
  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.
ncmncm 6y ago
I am the one you are asking. Manifestly, the B extension isn't in any of the chips being produced now, to my knowledge. It's a proposed extension, not finalized. So, until it is finalized, I don't expect it to be implemented in production. We don't know how long it will be until it is finalized, but the draft had not been updated in more than a year, when I last checked. For all we know, it may never become a standard extension. Somebody said they were trying to get the POPCOUNT instruction removed even from the extension, or made an optional part of it. It's a large extension, so (like other large extensions) it won't be implemented on the smaller chips that will also lack, e.g., floating point or vector units, or 64-bit registers and instructions, and for the same reason. I don't know why I would need sources. What seems surprising about the statement that something that is not considered finished is not being built into chips, or that something huge will not be included in small chips?
- avianes 6y ago
  > Manifestly, the B extension isn't in any of the chips being produced now The RISC-V chips produced today are not made for performance or be competitive, they are proof of concepts, toys and prototypes. The current state of the RISC-V spec is not competitive with either ARM or x86. Therefore why use this as a comparison point? > It's a proposed extension, not finalized. Like many other extensions such as the Packed SIMD one, the Vector one and Hypervisor one. These 3 are probably even more important than bit manipulation for performance and are not finalized either. The RISC-V ISA is still under construction. > It's a large extension, so (like other large extensions) it won't be implemented on the smaller chips that will also lack. Did you know that it's stipulated in the RISC-V spec that instructions not present in the hardware can be emulated in software? This makes it possible, in a small chip, to handle an extension as large as B without the need to implement all the instructions. > For all we know, it may never become a standard extension. Somebody said they were trying to get the POPCOUNT instruction removed even from the extension, or made an optional part of it. > I don't know why I would need sources. You need a source because you make surprising assertions.
  - ncmncm 6y ago
    I see that you do not understand that an emulated popcount instruction would be worse than useless. If you found anything I said surprising, it is only by not having thought things through. You would better learn to do that.

> it won't be in the smaller chips, or even in the biggest ones for a good while. Where does this statement come from? Do you have any sources or arguments to justify that?

AnimalMuppet 6y ago

I'm not the one you're asking. But... there's many a slip between spec and chip. That is, creating a spec that says that it includes a POPCOUNT instruction is easier (except perhaps for politics and bureaucracy) than actually implementing one in a chip, going through layout, producing masks, and starting production. Then it takes a while for those chips to work their way through the supply chain to general availability. How long? I don't know. But I suspect that it's a non-trivial amount of time. How long until that instruction is available in all chips that are manufactured? Longer.

avianes 6y ago
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.

ncmncm 6y ago

I am the one you are asking. Manifestly, the B extension isn't in any of the chips being produced now, to my knowledge. It's a proposed extension, not finalized. So, until it is finalized, I don't expect it to be implemented in production. We don't know how long it will be until it is finalized, but the draft had not been updated in more than a year, when I last checked. For all we know, it may never become a standard extension. Somebody said they were trying to get the POPCOUNT instruction removed even from the extension, or made an optional part of it. It's a large extension, so (like other large extensions) it won't be implemented on the smaller chips that will also lack, e.g., floating point or vector units, or 64-bit registers and instructions, and for the same reason. I don't know why I would need sources. What seems surprising about the statement that something that is not considered finished is not being built into chips, or that something huge will not be included in small chips?

avianes 6y ago
> Manifestly, the B extension isn't in any of the chips being produced now The RISC-V chips produced today are not made for performance or be competitive, they are proof of concepts, toys and prototypes. The current state of the RISC-V spec is not competitive with either ARM or x86. Therefore why use this as a comparison point? > It's a proposed extension, not finalized. Like many other extensions such as the Packed SIMD one, the Vector one and Hypervisor one. These 3 are probably even more important than bit manipulation for performance and are not finalized either. The RISC-V ISA is still under construction. > It's a large extension, so (like other large extensions) it won't be implemented on the smaller chips that will also lack. Did you know that it's stipulated in the RISC-V spec that instructions not present in the hardware can be emulated in software? This makes it possible, in a small chip, to handle an extension as large as B without the need to implement all the instructions. > For all we know, it may never become a standard extension. Somebody said they were trying to get the POPCOUNT instruction removed even from the extension, or made an optional part of it. > I don't know why I would need sources. You need a source because you make surprising assertions.
- ncmncm 6y ago
  I see that you do not understand that an emulated popcount instruction would be worse than useless. If you found anything I said surprising, it is only by not having thought things through. You would better learn to do that.