rdos wrote:
These instructions could have been discontinued in the new 32-bit compatibility mode too, and allowed the use of 64-bit registers.
But if you did that, it wouldn't be compatible.
rdos wrote:
The worst thing about the whole design is that 32-bit loads in compatibility mode will destroy the upper 32-bit of the 64-bit registers, making it extremely complicated to use 32-bit handlers in long mode.
Modern x86 CPUs are actually a custom architecture with an x86 translator on top. This feature would require the custom architecture to implement two sets of 32-bit operations: one set that clears the upper 32 bits to break dependency chains, and one set that preserves the upper 32 bits. It would only be useful in this specific circumstance.
The added expense of implementing this feature is far greater than the added expense of a temporary 64-bit wrapper to call your 32-bit handler while you work on a 64-bit version.
rdos wrote:
No, the fact that it has been around for so long means it was a superior design.
68k was the superior design. The only reason we're not all using 68k-based PCs right now is because the 68000 wasn't ready in time for IBM to put it in their PC.
rdos wrote:
It's only a pity that compilers never could handle segmentation properly, and that the switch to 64-bit turned off segmentation instead of fixing the problems with 16-bit selectors.
I disagree, but this thread isn't a good place for another argument about segmentation.