The problem with Intel doing this is that, for marketing reasons, they tend to enable different sets of instructions on different cores and an OS would have a really hard time scheduling threads when some the Skylake cores can execute AVX instructions but the Goldmont cores can't. Normally the scheduler wants to assume that it can just move a thread from one core to another but if the thread started off on the Skylake and was taking an AVX-enabled code path that would cause problems.

Not that the idea isn't appealing or even infeasible. It just runs afoul of Intel's marketing.

This is one of those interesting cases where RISC-V could eat their (and maybe ARM's) lunch on implementations like this. The wide vector instructions (i.e. not the packed SIMD, but the -V extension) are width-independent, so you could just make the vector machine narrower on the little core, and switch it to low-frequency in-order.

ARM recently added a similar wide vector instruction called SVE which works similarly. But yes, that way of doing vectors is really cool.

EDIT: Come to think of it, this might be something ARM has been adding deliberately partially to be able to use hetrogenous cores.

ARM did it first with SVE. The RISC-V vector extension is just a draft while I believe SVE silicon is being developed now for exascale HPC.

Cray did it first, that's why there's no patent dispute right now.

The scheduler already knows if you've used AVX or SSE instructions. You don't think they waste time backing up all those registers when you've never used them do you?

You can set a flag causing an exception when an FPU instruction is used, and handle it by setting a flag saying you need to backup those registers.

You can also handle Undefined Operation exceptions by moving the thread to a core that can handle the specific instruction.

In practice any non trivial program will end up touching xmm registers as even plain memcpy ends up expanding to vectorized load/stores.

Apparently lazy FPU restore in Linux is deprecated and eager restore is the default [1]

[1] https://tthtlc.wordpress.com/2016/12/17/understanding-fpu-us...

Couldn't you engineer the little core to take the fat instruction it can't process and instead do many small instructions to get the same end result? I am specifically thinking of AVX here, and it seems like it would work.. but perhaps there are other instructions that would not be so easy to unroll.

In terms of AVX breaking up 256-bit vector instructions into two 128-bit vectors is something that's very possible and is, in fact, what AMD is doing in Ryzen. That saves you on execution and datapath silicon but you still need the full sized registers to hold the data and that means that adding AVX to an Atom processor would require a redesign of the back end. And other new instructions might require other backend changes. And to interpret new instructions you certainly have to make silicon changes to the front end which might have follow on effects on the general layout.

But in general you could certainly design an Atom-ish core that has the full range of Intel instructions. Or just add AVX (they've already done this with Phi) and take all the other extra instructions out of the SKylake.