Instruction set could support compatibility cores to enhance versatility and interoperability.
Instruction set could support compatibility cores to enhance versatility and interoperability.
Currently, X86 supports more than 1000 instructions, with many unused today, mainly for backward compatibility. It’s possible to remove obsolete instructions from the main cores and relocate programs using those instructions to a few dedicated "compatibility" cores that retain the full X86 instruction set. This approach could be faster than emulation, reduce chip size, and bring some benefits from ARM architecture to X86.
I'm not convinced by this idea, though I have some concerns. The biggest problem seems to be timing—this CPU would require its own unique scheduler, and given how inconsistent the big-Little architecture is on Windows (all cores share the same instruction set but vary in speed), it would be extremely challenging to get it to function smoothly. I might be mistaken, since I don't build CPUs professionally, but it definitely warrants thought.
Consensus reached on the need for additional overhead to maintain responsiveness. A dedicated scheduler IC could manage incoming instructions efficiently, ensuring proper sorting by core designation. Incorporating a RISC island for non-legacy tasks or a specialized island for legacy instructions might help, though the expected practical benefit seems limited.
Intel is phasing out support for 32-bit OS compatibility with X86S. This decision preserves 32-bit software on a 64-bit system through an additional layer, making true native x86 compatibility largely unnecessary except in rare industrial scenarios tied to outdated operating systems. Such cases would require special motherboard setups that aren’t standard for typical desktops. Some manufacturers continue producing Intel-compatible chips using older designs to meet precise timing requirements, ensuring the hardware behaves exactly as before. The transition from legacy boot to UEFI also plays a role, as modern UEFI handles initialization differently and doesn’t rely on BIOS handoffs. I suspect a few companies still offer compatibility for specific legacy applications because those systems demand exact functionality. Ultimately, these outdated instructions were kept mainly for cost reasons, and removing them now would save significant development costs compared to the space savings.
It would be efficient to keep overhead low by adopting a core affinity approach. When a process begins, it helps determine if it needs legacy cores. If no signal is found, treat it as a legacy task and assign it to those cores. Otherwise, confine it to the cores it requires. If some of your eight cores can handle legacy workloads, this reduces restrictions to just two cores during the shift. Meanwhile, the remaining six cores would be limited because those two are burdened with legacy tasks. Together with the extra scheduler challenges, the benefits seem minimal.