It is also about removing some I/O instructions entirely and removing all others from ring 3 ("userspace"). Removing 16-bit addressing support frees up the 67h

It is also about removing some I/O instructions entirely and removing all others from ring 3 ("userspace"). Removing 16-bit addressing support frees up the 67h address size override prefix. They also suggest having CS/DS/ES/SS segment override prefixes do the same as in 64-bit mode: nothing, which should allow for repurposing those 4 entries in the primary opcode map some years down the line. They are suggesting freeing up 5 bytes in primary opcode map in all modes (4 for string I/O, 1 for 67h address size override) plus 8 bytes in ring 3 (userspace) plus making it possible to free up 4 more (segment override prefixes). That means 13 (17) free bytes for userspace! I think part of the plan is to enable more compact encoding of certain existing instructions (and allow for compact encoding of future instructions). I think they want to do that to enable wider instruction decoders -- more compact encodings => more instructions per 16-byte/24-byte/32-byte/whatever size window the decoders look at. Wide decoders are inherently harder for x86 than for architectures like ARM because there are so many possible instruction lengths (all values between 1 and 15 inclusive), so they need all the juice they can squeeze out here. I am surprised they didn't suggest getting rid of the BOUND instruction (which is used for the EVEX prefix in 64-bit mode). And what about HLT? It isn't allowed in ring 3, anyway, so maybe they are looking at repurposing that as well? And INT1, too?