I wonder if big.little is the first step in really hetereogenous architectures. Once we get OSs capable of understanding "this task should be executed on cores

I wonder if big.little is the first step in really hetereogenous architectures. Once we get OSs capable of understanding "this task should be executed on cores 0-7, and these others can be on 0-15", it's a much smaller step to "this task can only be executed on cores 0-7 and will be literal gibberish on the other cores". Over time, you skew the core distribution until x86-64 is a legacy product and you install a separate accelerator that has a couple of cores on it if you still have x86 software that can't be emulated efficiently. What worries me about ARM and RISC-V is that the diversity of SoC design that makes them great for embedded systems, makes them awful for a desktop PC where third-party software and peripherals matter. In that sense, any attempt to ask "will ARM/RISC-V replace x86/x86-64" has to be followed up with "which ARM/RISC-V". We'd need someone that could unite the industry around some standards for an ARM/RISC-V desktop. I worry that may end up being Microsoft, because they have a unique potential gatekeeping position with their closed-source portfolio. They can say "this is the right memory map/device tree for Windows ARM/RISC-V" and actually exert leverage on manufacturers. (If a Linux/BSD product tries the same, vendors can always patch around it). The alternative is chaos. Even in x86 land, with only two meaningful players and huge installed bases of each, we had various instruction sets that took forever to get adopted, or just withered entirely (3DNow!) because people didn't consider them part of the least common denominator.