Apple has shown that the market could be willing to adapt.
But then again, they’ve always had more leverage than the Wintel-crowd.
But what people seem to ignore is that there is another option as well: hardware emulation.
IIRC correctly old AMD CPU’s, notably the K6, was actually a RISC core with a translation layer turning X86 instructions into the necessary chain of RISC instructions.
That could also be a potential approach to swapping outright. If 80% of your code runs natively and then 20% passes this hardware layer where the energy loss is bigger than the performance loss you might have a compelling product.
Apple has shown that the market could be willing to adapt.
It’s less that they’ll adapt, and more that they don’t really care. And particularly in the case of Apple users: their apps are (mostly) available on their Macs already. The vast majority of people couldn’t tell you what architecture their computer runs on and will just happily use whatever works and doesn’t cost them the earth.
Microcoding has been a thing since the 1950s, it’s the default. Early RISCs tried to get away with it and for a brief time RISCs weren’t microcoded kinda by definition, but it snuck back in because it’s just too useful to not hard-wire everything. You maybe get away with it on MIPS but Arm? Tough luck. RISC-V can be done and it can make microcontroller-scale chips simpler, but you can also implement the RV32I (full) insn set in terms of RVC (compressed subset) and be faster. Not to mention that when you get to things like the vector extensions you definitely want to use microcode. The Cray-1 was hardwired, but they, too, dropped it for a reason.
I guess in modern days RISC more or less means “a decent chunk of the instruction set will not be microcoded but can instead be used as microcode”, whereas with modern CISC processors the instruction set and the microcode may have no direct correspondences at all.
Except software applications like Adobe CC have supported ARM for nearly 5 years now. As do most software because mobile exists (and mobile is exclusively ARM) and these days, apps need to cover desktop and mobile and web. ARM has essentially been forced on everyone because of mobile. Whether they like it or not, ARM is here to stay.
But none of this is a technical limitation. It’s a political one. Companies like MS don’t care about the technology, they just care about moving in a way that gives them control so they can maintain and expand their monopoly through licensing and other restrictions.
Windows as always turn out to be the main villain.
Windows has nothing to do with it. They are talking about software applications that were made for x86. Stuff like Adobe CC, etc.
Windows runs on ARM (and has for a decade) and the apps available in the Windows app store run on ARM.
Apple has shown that the market could be willing to adapt.
But then again, they’ve always had more leverage than the Wintel-crowd.
But what people seem to ignore is that there is another option as well: hardware emulation.
IIRC correctly old AMD CPU’s, notably the K6, was actually a RISC core with a translation layer turning X86 instructions into the necessary chain of RISC instructions.
That could also be a potential approach to swapping outright. If 80% of your code runs natively and then 20% passes this hardware layer where the energy loss is bigger than the performance loss you might have a compelling product.
It’s less that they’ll adapt, and more that they don’t really care. And particularly in the case of Apple users: their apps are (mostly) available on their Macs already. The vast majority of people couldn’t tell you what architecture their computer runs on and will just happily use whatever works and doesn’t cost them the earth.
Virtually all modern x86 chips work that way
Microcoding has been a thing since the 1950s, it’s the default. Early RISCs tried to get away with it and for a brief time RISCs weren’t microcoded kinda by definition, but it snuck back in because it’s just too useful to not hard-wire everything. You maybe get away with it on MIPS but Arm? Tough luck. RISC-V can be done and it can make microcontroller-scale chips simpler, but you can also implement the RV32I (full) insn set in terms of RVC (compressed subset) and be faster. Not to mention that when you get to things like the vector extensions you definitely want to use microcode. The Cray-1 was hardwired, but they, too, dropped it for a reason.
I guess in modern days RISC more or less means “a decent chunk of the instruction set will not be microcoded but can instead be used as microcode”, whereas with modern CISC processors the instruction set and the microcode may have no direct correspondences at all.
Except software applications like Adobe CC have supported ARM for nearly 5 years now. As do most software because mobile exists (and mobile is exclusively ARM) and these days, apps need to cover desktop and mobile and web. ARM has essentially been forced on everyone because of mobile. Whether they like it or not, ARM is here to stay.
But none of this is a technical limitation. It’s a political one. Companies like MS don’t care about the technology, they just care about moving in a way that gives them control so they can maintain and expand their monopoly through licensing and other restrictions.
And if it wasn’t for these meddling gnu followers it would have gotten away with it too.
Microsoft is actually pushing Windows on ARM right now, since their exclusivity deal with Qualcom expired. This is going to get interesting.