> Which, ten years down the line, should free up a bit more opcode space when they decide to no longer support CS/DS/ES/SS segment prefixes. The space could be

> Which, ten years down the line, should free up a bit more opcode space when they decide to no longer support CS/DS/ES/SS segment prefixes. The space could be used for instructions that are the same in 32-bit and 64-bit modes. The document explicitly says that segment prefixes are _ignored_. > Removing all ring 3 I/O instructions (also part of the plan) will free up 8 further bytes in the primary opcode map for user space code. It does not unless the same codes are removed in ring 0 as well. But if ring 0 IO commands are converted to multibyte, why ring 3 IO commands can't get the same? > And then there is the 67h byte being freed as well due to removing address size overrides. Again, not ignored - unsupported styles get GP instead. > Free space in the primary opcode map => better encoding density... Won't happen. More so, most encodings are shared with 32-bit mode and still developed this way. > Getting rid of 16-bit data will make the data flow engine in future CPUs simpler (no more partial register stalls). This is missed as well. 16-bit data are still handlable. Only addressing is disallowed. > So what are the benefits? Seems pretty none among what you listed:(