A nice place to discuss rumors, happenings, innovations, and challenges in the technology sphere. We also welcome discussions on the intersections of technology and society. If it’s technological news or discussion of technology, it probably belongs here.
Remember the overriding ethos on Beehaw: Be(e) Nice. Each user you encounter here is a person, and should be treated with kindness (even if they’re wrong, or use a Linux distro you don’t like). Personal attacks will not be tolerated.
Subcommunities on Beehaw:
This community’s icon was made by Aaron Schneider, under the CC-BY-NC-SA 4.0 license.
Windows as always turn out to be the main villain.
Microsoft is actually pushing Windows on ARM right now, since their exclusivity deal with Qualcom expired. This is going to get interesting.
And if it wasn’t for these meddling gnu followers it would have gotten away with it too.
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.
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.
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.
I didn’t mean the customers, but sure.
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.