I've very curious what you consider to be "modern designs". The only important ISAs designed in the 21st century are ARMv8 and RISC-V. Both use LL/SC (called L

I've very curious what you consider to be "modern designs". The only important ISAs designed in the 21st century are ARMv8 and RISC-V. Both use LL/SC (called Load-Exclusive/Store-Exclusive in ARM). RISC-V from the outset also specified Atomic Memory Operations such as AMOADD, AMOMIN, AMOMAX, AMOOR, AMOAND, AMOXOR. Implementations are permitted to trap the AMOs and implement them using LL/SC if they wish. (The reverse isn't feasible). ARM added similar operations (and CAS, CASP) only in FEAT_LSE (Large Systems Extensions) in ARMv8.1-A, and only in A64. I don't know what IA64 did, but it's dead anyway, so who cares?. The next newest important ISA is POWER/PowerPC, which uses LL/SC. > Another example is that the microarchitecture can't tell if it > is doing an ordinary indirect branch or a function return. In fact it can and, except for a couple of minimal Cortex-M0 competitors, all RISC-V SoCs I know of, right back to the now ancient FE-310 and FU-540, have return address prediction which works very effectively and does not use resources in the indirect branch predictor. > Condition codes were momentarily a problem for out-of-order execution That's one opinion. Another opinion, which both Intel and ARM seem to share, is that "compare and branch" should have been one instruction, and both of their recent designs fuse a compare and a following conditional branch into a single uOp. Using the same condition code result to control multiple branches is a rare thing, not worth optimising for. The really amusing thing here is that I'm pretty sure you criticise RISC-V ideas to implement "missing" instructions or addressing modes using fusing of simpler instructions. > Faithful readers here know about my horror that popcount is missing from the core instruction set Neither the ARMv8 integer instruction set nor NEON have popcount. ARM SVE and RISC-V V both have popcount on execution masks (only) > code generators can't count on having it available for its 10x performance boost of remarkably common operations. Single-cycle popcount is very very expensive. Recent Intel CPUs have a 3 cycle latency for popcount. You can do a popcount using simple operations ... shift, and, add ... in 17 instructions, or 12 instructions including one multiply. On a superscalar machine with the typical 4 cycle latency for multiply, that version has a total latency of 14 clock cycles. The built in POPCNT instruction is therefore only 14/3 = 4.7 times faster than the sequence of simple instructions. A similar ratio applies to throughput if you are doing several in parallel. There is no way that any actual algorithm with popcount as a component has that 4.7:1 ratio. There will be other instructions. The ratio will be lower. 10x is simply impossible. I'm curious what you think these remarkably common operations are.