Some more:

> The spec says that bit must be zero, and yet no encoding uses the space opened up by that bit being one.

The spec says "the code points with shamt[5]=1 are designated for custom extensions.", so the space is specifically reserved for custom vendor extensions.

So, if I wanted to add a custom "dzaima.c.clear_top_n_bits rd, imm5" instruction, that's space I could safely put it in, knowing that no future standard instruction will be added there that I may regret overlapping. So while that space goes unused in the standard, its existence helps with the overlapping encoding problem!

> For I-type instructions, bit 1 [...], bit 11

Of course, that's cherry-picking two of the 25% of bits that have multiple positions they come from, and specifically 11 as it's the worst one. Full stats:

    1 position: 24 bits: (everything that's not listed below)
    2 positions: 7 bits: 0, 1, 2, 3, 4, 12, 20
    3 positions: 1 bits: 11 (the single worst case)

So that's like 9 muxes for merging all immediates to the same place (or less of course if the different encodings' immediates go to different places), the rest is just wires.

Obligatory note is that some of the funkiness is to place the sign-extended bit in the same bit position, so some saved muxes from that.

Now, I am a "software person who's never written verilog", but I highly doubt a 3:1 mux is as cheap as a 2:1 mux in silicon, so even if you always need to merge in the sign bit, reducing the number of cases is still beneficial.

Compressed does make it a ton more ugly though (combining both 32-bit and 16-bit instruction encodings, placing the 16-bit ones in the low 16 bits):

    1 position: 13 bits
    2 positions: 7 bits: 10, 13, 14, 15, 16, 17, 20
    3 positions: 4 bits: 3, 4, 9, 12
    4 positions: 5 bits: 0, 1, 2, 5, 11
    5 positions: 3 bits: 6, 7, 8

looking at aarch64 on https://asmjit.com/asmgrid/:

    tbz Xt, #imm, #relS*4   imm:1|0110110|imm:5 |    relS:14 |Rt
    lsl Xd, Xn, #n            1   1010011|01|immr:6|imms:6|Rn|Rd

Fun! (lsl being a subset of the bitfield extract instrs is neat; tbz's similar-functionality 6-bit field is just entirely-differently placed though. Also.. using the Rd slot for an input-only Rt? that's one thing RISC-V doesn't do, even across compressed and 32-bit instrs!)