The Sacrifices of Portablility?

hackwrench asks: "There is lots of talk about writing portable programs, but this pursuit has resulted in a lot of processor features going unused. One example is being able to write a program that purposely uses a combination of 16-bit and 32 bit. I know there are arguments that writing solely in one or the other is a performance advantage, but what are the factors involved? Is the slowness of such a combination inherent in its design or is it a result of current hardware. We are beginning to replace systems and programs designed primarily to run in pure 32-bit mode with systems designed to run in pure 64-bit mode, so I ask: Is such purity really worth it?"

Comments

16 bit is often slower than 32 bit

[dtfinch]

In 32 bit protected mode, 16 bit instructions require a prefix to tell it that the following instruction is 16 bit, wasting a byte and a CPU cycle. In 16 bit real mode, the same is true of 32 bit instructions. But modern processors aren't optimized to preserve 16 bit performance. If they can improve 32 bit performance just a little, they'd be willing to sacrifice a lot of 16 bit performance to do it. Also, if you're mixing 16 and 32 bit variables in C/C++, it'll do a lot of expensive conversions to make it all work. I've done very little with 64 bit though, aside from playing with MMX on one occasion.