[kllrnohj]

> The approach that immediately occurred to me would be have a layer that translates the legacy instructions into modern equivalents; without as much concern if they are slower to execute in their new form (they're legacy, after all, right?).

This is what x86 CPUs already do and have been doing for years.

It's also why Intel & AMD don't care about "x86 complexity" and it's also why even though people love to claim that a switch to RISC would improve efficiency/performance, so far there's really no evidence to support that.

Intel just plops their teeny-tiny (in terms of die space) x86-to-internal-microcode transactor on top of their new cores and calls it a day. As long as that translation layer isn't a bottleneck, which it rarely is, then Intel doesn't care.

[roca]

It's not just about legacy instructions which can be decoded down to some microcode. It's about architectural features like SGX, CET, MPX, TSX, VT --- plus the legacy stuff like segment registers and 286 call gates and virtual 8086 mode and so on and so on --- and how they all interact with each other, and how they increase the complexity of context switching, OS support, and so on.

[kllrnohj]

OS complexity is because they choose to keep and value that backwards compatibility, just like x86 values backwards compatibility.

Linux could eliminate all that complexity tomorrow by just bulk removing x86 support and only running x86-64. All OS complexity eliminated. All context switching complexity eliminated.