> I'd be surprised if 16bit support uses a noticeable amount of power in a running system.
For 16 bit you have to strongly distinguish between 16 bit real mode (what DOS ran on by default), 16 bit protected mode (what Windows 3.x and partly Windows 95 ran on) and Virtual 8086 mode (which was for example used under Windows 95 to run DOS applications). Also I think SMM (System Management Mode) also runs 16 bit code.
Next: In 32 bit mode, nearly every instruction can be prefixed by 0x67 (I am aware that some instructions use an 0x66 prefix instead - I just want to keep things simple here) that allows one to use 16 bit (protected mode) addressing to be used in 32 bit mode. Except for some very obscure applications that surely does not make sense, but shows how deeply ingrained 16 bit support is in the x86 instruction set. Also: If you prepend an 0x66 prefix to many classic x86 instructions in 32 bit mode, they will do what the instruction would do in 16 bit mode (except for using 32 bit adressing if suitable; but I just explained how this can be changed, too). This is exactly how instructions that use 16 bit registers are encoded.
So 16 bit support is deeply ingrained into x86 and cannot be simply removed. And I would bet there exist customers who would be really enraged if Intel or AMD did just remove some of the 16 bit modes, because they have some exotic application that depends on them.
For 16 bit you have to strongly distinguish between 16 bit real mode (what DOS ran on by default), 16 bit protected mode (what Windows 3.x and partly Windows 95 ran on) and Virtual 8086 mode (which was for example used under Windows 95 to run DOS applications). Also I think SMM (System Management Mode) also runs 16 bit code.
Next: In 32 bit mode, nearly every instruction can be prefixed by 0x67 (I am aware that some instructions use an 0x66 prefix instead - I just want to keep things simple here) that allows one to use 16 bit (protected mode) addressing to be used in 32 bit mode. Except for some very obscure applications that surely does not make sense, but shows how deeply ingrained 16 bit support is in the x86 instruction set. Also: If you prepend an 0x66 prefix to many classic x86 instructions in 32 bit mode, they will do what the instruction would do in 16 bit mode (except for using 32 bit adressing if suitable; but I just explained how this can be changed, too). This is exactly how instructions that use 16 bit registers are encoded.
So 16 bit support is deeply ingrained into x86 and cannot be simply removed. And I would bet there exist customers who would be really enraged if Intel or AMD did just remove some of the 16 bit modes, because they have some exotic application that depends on them.