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.
It's not politics its just that there is a dispute between ARM China and its parent, this is well documented. This complicates IP licensing concerning the ARM ISA in the world's largest market. I personally wouldn't want to develop a product with uncertainty around the IP in a major market.
So right now when an x86-64 CPU boots it starts in 16bit real mode regardless of everything else. The UEFI then has to set up a x64 protected mode env then the OS picks up from there. If you drop that backwards compat (e.g. 16bit, virtual 8086 mode etc.) you can remove a lot of cruft that is mostly worked around. If nobody is setting Local Descriptor tables then why support it? Or the hardware task switching support that's not even supported in long mode etc.
I believe that individual cores must still be brought up via real mode, etc. even when the UEFI boot otherwise gives you a clean 64-bit environment. So the backward compatibility must still be present.
It's complicated and annoying but yes. There is also the question of 'downleveling' a core back to real mode when the others aren't. But if you require UEFI and secure boot then you could bypass that and go to a 64-bit linear reset vector anyway as that's how UEFI sets up the boot env. That would mean you'd only need to initialize that core and it'\s local APIC and associated envs in theory instead of playing mode hopscotch.
On the topic of downleveling... based on the research I've done (think writing a UEFI capable kernel for FreeDOS) it's dubious at best to do that because the real mode core wouldn't know about the local APIC and would mess with the IO APIC when you really really don't want it to. So is it possible? Potentially? Would anyone with any shred of sanity recommend it? No not in my opinion. There is no valid reason to do that.
I'd wager that in general the crowd frequenting this site are much more interested in what the back-end / protocol is written in than what the web app is.
Funny that they are not encrypted and also based in the EU, so any kind of "revolt" against the status quo couldn't ever happen using their platform. https://revolt.chat/aup
> The most affordable 4G smartphone of India, JioPhone Next will began pre-booking from next week. The phone has been created in collaboration with Google. Reliance Jio Infocomm Limited, doing business as Jio, is an Indian telecommunications company and a subsidiary of Jio Platforms, headquartered in Mumbai, under the chairmanship of Mukesh Ambani.
> Pressing the dot ( . ) key while browsing any repository on GitHub.
if you are using a QWERTY keyboard layout, yet again, decision made by someone self centered, probably a mac user since github's font looks so bad on linux
