3 ms·

>I still do believe RISC-V did a lot of things better than x86... Such as? I can't think of anything it does better for high performance cores.

• _chris_ 2mo ago
  1B through 15B variable length instruction mess, for one. Which still yields a worse than average 4-5B per instruction average.
  • 201984 2mo ago
    That is a strength, not a weakness. It allows for things like 64-bit immediate loads, 32-bit branch offsets, and nearly unlimited future extensibility. With RISC-V, multiple instruction workarounds are needed for all of the above, and those sequences are usually sequentially dependent ones so they can't be run in parallel. i.e. the insanity of loading a 64-bit value through repeated 12-bit immediates with shifts, using multiple instructions to compute branch offsets, and RVV needing setvli instructions everywhere due to not having opcode space to encode vector length/type. AArch64 is better, but still has problems with limited opcode space when it comes to future extensions. They've had to make "start mode" and "end mode" for SME to save on opcode space, and future compromises will likely be necessary.
  • Symmetry 2mo ago
    More to the point x86 instruction streams aren't self-synchronizing. There are cases where you can read one valid stream of x86 instructions starting at byte X, but another completely different one starting at byte X+1. Apart from the security implications this makes wide decode on x86 notably harder than it has to be, though in practice you can make it work by just starting a decode your fetch window at every byte boundary the fist time you're executing something and throwing away the unused decodes, and then mark the invalid positions in the instruction cache so you don't waste that power again.