RISC-V sooner than later, the uncertainty around ARM the company due to the buyout and the whole thing with ARM China is just yuck. But honestly nothing the M1 does x86/RISC-V can't do. At this point ISA is just an ABI it's more about keeping execution pipes filled, as long as a frontend can do that it can absolutely clean up on the metrics.
Another thing although speculative: Windows 11's move to require UEFI/x64/SecureBoot could be prep for AMD and Intel to completely drop a ton of legacy support (16bit etc.) in the chips. I'd give it about 20% chance of happening, but I definitely wouldn't rule it out given you can emulate a 386 easier than you virtualize one.
The whole selling point of x86-64 was that it was an extension. You didn't need to use the extra registers, the long address space, etc. except where it actually was useful. I'd be unsurprised if a lot of x86-64 binaries have plenty of traditional 32- and 16-bit instructions. Maybe there's a handful of "can never sensibly be executed in a 64-bit OS running normal well-behaved software" flows you can nibble off at the edges (stuff related to long-abandoned 286 protected modes?)
If you go much further, you sacrifice the key selling point of buying an x86-64 CPU: the ability to run your closed-source line of business software and propriatery games. Then you've basically got the software value proposition of one of those arcane POWER or RISC-V desktops, or an ARM Chromebook, without the unique selling points of either.
I'd expect the portion of the die responsible for decoding 16- and 32-bit instructions has more or less stabilized over the years, and just gets copy-pasted-shrunk across generations. MOV AX,[1234:5678] is pretty much unchanged in 40 years, so I doubt there's a hot breakthrough in how to decompose it to micro-ops.
The transition I could imagine would be a big-little style thing: a CPU that was, say, eight x86-64 cores and eight RISC-V or ARM. Over time, the ratio skews, until the x86-64 cores are a co-processor you can install seperately if you still need them.
leeter|4 years ago
Another thing although speculative: Windows 11's move to require UEFI/x64/SecureBoot could be prep for AMD and Intel to completely drop a ton of legacy support (16bit etc.) in the chips. I'd give it about 20% chance of happening, but I definitely wouldn't rule it out given you can emulate a 386 easier than you virtualize one.
hakfoo|4 years ago
The whole selling point of x86-64 was that it was an extension. You didn't need to use the extra registers, the long address space, etc. except where it actually was useful. I'd be unsurprised if a lot of x86-64 binaries have plenty of traditional 32- and 16-bit instructions. Maybe there's a handful of "can never sensibly be executed in a 64-bit OS running normal well-behaved software" flows you can nibble off at the edges (stuff related to long-abandoned 286 protected modes?)
If you go much further, you sacrifice the key selling point of buying an x86-64 CPU: the ability to run your closed-source line of business software and propriatery games. Then you've basically got the software value proposition of one of those arcane POWER or RISC-V desktops, or an ARM Chromebook, without the unique selling points of either.
I'd expect the portion of the die responsible for decoding 16- and 32-bit instructions has more or less stabilized over the years, and just gets copy-pasted-shrunk across generations. MOV AX,[1234:5678] is pretty much unchanged in 40 years, so I doubt there's a hot breakthrough in how to decompose it to micro-ops.
The transition I could imagine would be a big-little style thing: a CPU that was, say, eight x86-64 cores and eight RISC-V or ARM. Over time, the ratio skews, until the x86-64 cores are a co-processor you can install seperately if you still need them.
Shadonototro|4 years ago
china? you bring politics too?
who are you?
OneEyedRobot|4 years ago
Like the 80386SX? 80376?
silon42|4 years ago