The problem with ARM laptops is all of the x86 windows software that will never get ARM support and all of the users that will complain about poor performance if an emulator is used to run the x86 software.
Most Linux software already supports ARM natively. I would love to have an ARM laptop as long as it has a decent GPU with good open source drivers. It would need full OpenGL and Vulkan support and not that OpenGL ES crap though.
Modern ARM GPUs already support OpenGL and Vulkan, that’s not a problem. Just some platforms chose to go mobile APIs due to running Android.
The trick with emulation that Apple did was to add custom instructions to the CPU that are used by the emulation layer to efficiently run x86_64 code. Nothing is stopping other CPU manufacturers from doing the same, the only issue is that they have to collaborate with the emulation developer.
The driver situation is less than ideal. Mesa got support for Mali but that’s not the only GPU that comes with ARM chips and you get bonkers situations. E.g. with my rk3399-based NanoPC, a couple of years ago (haven’t checked in a while and yes it’s a Mali) rockchip’s blob supported vulkan for android but only gles for linux as rockchip never paid ARM the licensing fees for that.
And honestly ARM is on the way down: Chip producers are antsy about the whole Qualcomm thing and Qualcomm itself is definitely moving away from ARM, as such my bets for the long and even mid-term are firmly on RISC-V. Still lack desktop performance but with mobile players getting into the game laptops aren’t far off.
Doesn’t Microsoft have something similar to Apple’s Rosetta 2 JIT x86 -> ARM code translation kajigger? I could swear I’ve seen something like that mentioned
Edit: not sure whether it was WOW64 that I read about, that seems to only work for running 32 bit intel code on ARM (although I have no idea if that’s actually a problem or not when running modern Windows binaries, the last Windows I ran was Vista)
Don’t want to go into too much details - from a high level perspective the Windows version integrates better into the overall system. In Rosetta, once you’re in the emulation layer it can be rather complicated to execute native components from there. In Windows - with some exceptions - that’s not a problem.
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.
The problem with ARM laptops is all of the x86 windows software that will never get ARM support and all of the users that will complain about poor performance if an emulator is used to run the x86 software.
Most Linux software already supports ARM natively. I would love to have an ARM laptop as long as it has a decent GPU with good open source drivers. It would need full OpenGL and Vulkan support and not that OpenGL ES crap though.
Modern ARM GPUs already support OpenGL and Vulkan, that’s not a problem. Just some platforms chose to go mobile APIs due to running Android.
The trick with emulation that Apple did was to add custom instructions to the CPU that are used by the emulation layer to efficiently run x86_64 code. Nothing is stopping other CPU manufacturers from doing the same, the only issue is that they have to collaborate with the emulation developer.
The driver situation is less than ideal. Mesa got support for Mali but that’s not the only GPU that comes with ARM chips and you get bonkers situations. E.g. with my rk3399-based NanoPC, a couple of years ago (haven’t checked in a while and yes it’s a Mali) rockchip’s blob supported vulkan for android but only gles for linux as rockchip never paid ARM the licensing fees for that.
And honestly ARM is on the way down: Chip producers are antsy about the whole Qualcomm thing and Qualcomm itself is definitely moving away from ARM, as such my bets for the long and even mid-term are firmly on RISC-V. Still lack desktop performance but with mobile players getting into the game laptops aren’t far off.
Doesn’t Microsoft have something similar to Apple’s Rosetta 2 JIT x86 -> ARM code translation kajigger? I could swear I’ve seen something like that mentioned
Edit: not sure whether it was WOW64 that I read about, that seems to only work for running 32 bit intel code on ARM (although I have no idea if that’s actually a problem or not when running modern Windows binaries, the last Windows I ran was Vista)
They have, and in my experience it works nicer than Rosetta.
Windows 10 had it limited to 32bit binaries (but Windows 10 on ARM is generally very broken). Windows 11 can handle both 32 and 64bit emulation.
Yeah I recall it somehow being better designed than Rosetta but I can’t dig up where I read about this
Don’t want to go into too much details - from a high level perspective the Windows version integrates better into the overall system. In Rosetta, once you’re in the emulation layer it can be rather complicated to execute native components from there. In Windows - with some exceptions - that’s not a problem.
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.
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.
I didn’t mean the customers, but sure.
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.