[brucehoult]

No more of a problem than in any other ISA that has seen incremental improvements -- which is all of them.

Modern x86_64 OSes such as Windows and Linux run on everything back to the original Opteron and Athlon 64 from 2003, which don't have POPCNT and LZCNT. Those were implemented by AMD starting with Bobcat and Bulldozer in 2011. Intel added POPCNT in Nehalem in 2008 and LZCNT in Haswell in 2013.

Aarch64 got both from the start, but there are other things added in ARMv8.1-A through ARMv8.8-A (and ARMv9) which are presumably also useful to certain software.

Embedded chips used in routers and switches will take exactly the extensions useful to them and none that aren't. If Zbb is useful to them then they will certainly include it -- that's why the extensions are specified so finely with three non-overlapping extensions for BitManip being defined this year. Applications processors running shrink-wrapped OSes are required to take all the extensions in RVA22 (or none). The embedded world picks and chooses what they want.

[ncmncm]

In other words, as much of a problem as in any ISA that has seen incremental improvements. We are supposed to learn from the mistakes of our forbears, not repeat them verbatim.

Chips used in routers and switches will be exactly what is cheapest, just as now, regardless of what performs best or adequately. Thus, they will lack B extensions, howsoever useful they might have been.

[zozbot234]

> In other words, as much of a problem as in any ISA that has seen incremental improvements.

That's way overstated. RISC-V is still an amazingly clean and elegant design, placing extreme focus on technical excellence and on making effective use of limited insn encoding space. (Just look at how cautious the ratification of B and V has been - some of that was due to wanting to maximize feasible overlap between B and other exts, so as to avoid wasting even the smallest fractions of insn space). Tiny warts like SLT returning 0/1 as opposed to 0/-1 don't change that in any way.

[ncmncm]

Way understated, rather. If you have AVX, you know you also have POPCNT and everything else older than AVX. Having thing A on RISC-V tells you nothing about whether you have thing B or C, or vice versa. The set of possible targets is exponential in the number of extensions, rather than strictly linear in the number of additions, as seen in existing chips.

"Tiny warts" reveal mindset: how aware are the designers of the consequences of their choices? Each is a clue. Lack of rotate and popcount instructions in the core instruction set provides a clue. Expectation that five-instruction sequences can be fused might be another. (When your instructions are already 4 bytes or more, each, five means at least 20 bytes for a single primitive operation.) The extremely complicated extensions landscape is another.

[brucehoult]

Rotate and popcount are very specialised instructions. The vast majority of software doesn't use them at all, or uses them so infrequently that a software implementation is fine.

You are confusing embedded applications, which have huge flexibility with RISC-V, and standard operating systems with packaged software.

For the next few years (5?) standard operating systems have to support exactly two choices:

- RV64GC

- RVA22

RVA22 includes all the bit manipulation instructions, vectors, cache management, scalar crypto, and some other stuff. You can't pick and choose -- you have to support it all.

If you are making an embedded appliance on the other hand you can pick and choose exactly what extensions you need (a huge number of combinations, as you say), specify a core with exactly those extensions, build a chip around that with the other IP blocks you need, and tell your compiler which extensions you have. You compile all your software yourself, whether bare metal, using an RTOS, or a minimal Linux such as builtroot or yocto. There is zero confusion because you know what you have and you have what you need -- no more and no less.

No one who knows what they are talking about is talking about fusing five-instruction sequences. That's a total red herring.

[ncmncm]

You appear to have an idealized view of embedded development. High-profile and high-volume products may get custom silicon, but most designs are driven by per-part price, which means in practice piggybacking on manufacturing runs for highest-volume products of other companies, with effectively no choices.

The assertion that rotate and popcount instructions are unimportant is false. All compilers peephole-optimize to generate rotate instructions where supported, and not because nobody needs that. There is a long history of mis-estimating instructions and their importance, going back to optimizing an instruction used only in a kernel idle loop.

A more objective measure is to note how often a neglected instruction has needed to be added after the first ISA version shipped, because its lack handicapped the chips on the market. Popcount wins that race everywhere: always neglected, always added. Its neglect reveals the blinders of the CS academics who do the initial ISA designs, and the need to patch reveals the reality.

The importance of an instruction is poorly represented by both its static frequency and by its total execution frequency for the same reason as that idle-loop instruction was miscounted: the importance of lines of code varies by many orders of magnitude, and there is no way to measure importance when counting. It is easy to prioritize instructions used in signature benchmarks, but they are a cracked mirror.

The market is another cracked mirror: it takes a very large signal to penetrate it. Any that does merits attention.

[brucehoult]

The embedded market using custom silicon is by far the shipment volume and dollar value leader. That's why that's what RISC-V vendors have been concentrating on at first.

The part of the embedded market that uses off the shelf chips may have more designs, but they are each low volume enough that they are dominated by engineering time (and thus employ more engineers, who are vocal online) not by saving a few cents on an MCU that doesn't have the instruction you want.

The packaging and testing and stocking costs of a chip with nothing more than a generic MCU inside it are such a high proportion of the cost compared to the actual die that it would be silly to leave any available low silicon cost extensions out, unless done for monopolistic market segmentation reasons e.g. you can't buy a Cortex M0+ with an FPU at any price because ARM would prefer to sell you an M4F for much more money.

The RISC-V market with many vendors with many cores is not prone to such artificial market segmentation.

If you want the equivalent of an M0 (short pipe, no cache, no branch prediction etc) but with an FPU or with 64 bits or with a vector unit then RISC-V vendors say "sure, no problem".