Yup. ARMv4T (two modes with 32 bit and 16 bit instructions) was what got ARM's foot in the door with Nokia, but it was Thumb2 (ARMv7) that sealed the deal and l

Yup. ARMv4T (two modes with 32 bit and 16 bit instructions) was what got ARM's foot in the door with Nokia, but it was Thumb2 (ARMv7) that sealed the deal and led directly to ARM's current dominance in mobile and embedded. Abandoning all that for a fixed-length 32 bit opcode 64 bit instruction set with just barely better code density than original ARM (and dropping the stuff that made sense in 1985 but doesn't today, such as predication everywhere and load/store multiple) just looked like lunacy to me in 2012 when I read the Aarch64 manual, and looked even worse when RISC-V came out with a 64 bit instruction set using the same basic idea as Thumb2. If you're doing very wide instruction decode then two instruction lengths is a little harder to handle then one, but not enough to matter, at least at 8- or 16-wide. You can EITHER 1) put a 2:1 32 bit mux in front of half of the decoders if you don't want much extra hardware, OR 2) build 50% more decoders and put bigger 2:1 muxes on the outputs of the decoders. The latter is slightly faster because you have to examine 2 bits out of each 16 bit parcel in the instruction stream to decide which mux input to choose, and option 2) lets you do that in parallel with the decoding instead of having to do it before the decoders. It's just completely incomparable to doing wide decode on x86_64 where you have to deal with 1-15 byte instructions with an arbitrary number of prefix bytes and several opcode bytes to decode before you know the length of an instruction, and therefore where the next instruction starts. If the first instruction starts at offset 0 then the second instruction can start anywhere from offset 1 to 16, the third instruction can start anywhere from offset 2 to 31, the fourth instruction anywhere from offset 3 to 46 etc.