I have been following the main RISC-V ISA design mailing list for a while, and of course there has been criticism of some design decisions there. My personal c

I have been following the main RISC-V ISA design mailing list for a while, and of course there has been criticism of some design decisions there. My personal criticism would be that there are still missing parts: the B extension (bit operations like count leading zeros/count trailing zeros/popcount/byte swap), the V extension (extensible vector operations), and the P extension (packed SIMD) aren't ready yet. If your problem domain needs these, you'll have to either wait until they're specified, or use a non-standard extension (of course, a benefit of the RISC-V ISA design is that it makes easy to use non-standard extensions when you need to). Other criticisms I've seen in the mailing list: - As already mentioned by someone else here, the RV32 and RV64 variants (32-bit and 64-bit registers) are incompatible, that is, code written for RV32 won't run on RV64, while with some small tweaks to the instruction encoding, it could; - Some have argued that the C extension (compressed 16-bit instructions - normal instructions are 32-bit) could have been done in a better way; - All Linux distributions have converged on RV64GC as their base ISA, which includes the C extension, and some have complained about this choice; - There have been some complaints of possible interrupt latency on embedded systems due to having to save/restore registers without hardware help.