That, or software emulation of non-existent machine code instructions. The Linux community (that Intel is an important member of) could implement that. MS ... not so sure.
If you mean actual software emulation, then the whole program must be emulated, as the CPU core executes at least tens of thousands of instructions for every kernel tick.
At least on Linux when executing a program with unsupported instruction you'll get a kernel trap "Illegal instruction (core dumped)" (e.g. trying AVX2 on my i7-3930K), but I'm not deeply familiar this mechanism to determine with whether it could successfully catch the entire CPU state well enough to emulate a few clocks and then move it back without causing any program error.
Or quad-pumped or anything that's cheapest to make. If the goal is compatibility, not performance, then any kind of performance above zero is acceptable.
I suggested dual-pumped because the E-core already support 256-bit vectors, and is what Via and AMD successfully did with their first implementations. This would be a relatively marginal cost, only requiring extra complexity for instructions that affect across the 512-bit vector or new types of features that AVX2 lacked (there are a few).
No, these are two different things.
X86S = how can we make the 32-bit parts a little bit leaner (Intel only)
Advisory group = how can we still extract money from our IP when our most important patents expire (Intel and AMD, and I'm not sure what others are doing here)
No silly, the advisory group is about evolving the x86 family, not extracting money.
I'm not convinced all the x86S efforts was a good idea, as it might sacrifice to much compatibility. Running old games (like we all like to do), or running MS-DOS for fun isn't the main concern here, but the vast amount of "enterprise" software running everywhere from servers, to workstations, embedded systems(incl. medical, military uses etc.).
Secondly, the great level of compatibility of x86 over the decades is the main reason for the thriving enthusiast community and the the wealth of software that can run on almost anything without a fruity logo. We may take this for granted, but this wasn't a given in the late 70s and early 80s, and the more obvious outcome would be to have 4-5 vendors like Apple, each with their own platforms constantly evolving and breaking compatibility, and each with their niche selection of software. Having a stable "standard" is immensely valuable, far more important than having the
perfect standard, and we've gotten a massive amount of small software companies and individuals that we wouldn't have gotten otherwise. If anything, compatibility should have been
even better, but this isn't a shortcoming of x86, but mainly MS for terrible API compatibility and some games and applications relying on undefined behavior (e.g. copy protection).
Nothing specific, but 32-bit boot mode/protected mode/ring-0 is an attack surface that X86S would remove. These capabilities also have to be integrated into every new architecture, which is a process that can create new security cracks.
That shouldn't be a concern for anyone except for those consciously choosing to run an antiquated OS, as those who do will do this for a specific purpose.
