One other note for your consideration. Regarding the idea of Windows Arm running on Apple Silicone there is one other player you need to consider. Microsoft. They disparately need a platform for Windows 10 Arm that will run it at anything near a usable speed. They don't have that yet even after developing their own CPU. Apple Silicone fixes that instantly. They have had DTK's for some time now- Where do you think that those almost finished Office apps came from? You think that the office team and the windows team don't talk? Microsoft has a play here. They are being suspiciously quiet for a reason.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Could x86-64 emulation be possible on ARM Macs?
- Thread starter JPNMac
- Start date
- Sort by reaction score
Yeah, but their play is either Mornington Crescent, Calvinball or Brockian Ultra Cricket. MS are in an odd position with PC hardware, because it puts them in direct competition with Dell, HP, Lenovo etc. who currently sell vastly more PCs than Microsoft - and Microsoft relies on those third-party PCs to provide the vast majority of their income via software licensing. Not to mention that part of their dominance comes from lock-in and long-term backwards compatibility down to the binary level - ARM can only reduce that, and if they persuade customers to maybe, just maybe embrace change that opens the door to competitors and suddenly Windows is having to compete with Linux and MacOS on merit. Shudder!
The whole surface range sometimes seems to be not so much MS trying to sell hardware and more about trying to prod OEMs into doing better... The most extreme example is the Surface Studio - gorgeous concept until you look at the specs, at which point the iMac suddenly looks like a bargain - but the whole Surface range is a bit like that. I think Windows on ARM is more bet-hedging than thinking that the wider Windows world is going to give up x86 anytime soon.
That said, I completely agree that ARM Macs have the power to rapidly outnumber ARM-based Windows machines and that MS will probably do something to get ARM Windows onto it. However, my guess is that it will be via virtualisation rather than direct boot (possibly via a license agreement with Parallels/VMWare). For the majority of use cases, virtualisation is inherently more convenient and flexible than direct booting, and the exceptions - running A-list games and demanding pro apps - well, lets face it, you'll need an x86: Apple can and probably will get all the key MacOS Apps running native within a year or two but that just isn't gonna happen for Windows applications.
I'm still also guessing that cloud-based virtual Windows x86 instances will be a growth industry.
By not supporting bootcamp, Apple gets the freedom to change hardware and firmware with every generation of Mac without howls of protest from every Windows and Linux driver developer. With Virtualisation, the hypervisor presents the OS with a simulated, standard machine.
While this has been true in the past, IMHO the ARM chip is a total game changer. Nintendo, the second largest console by marketshare, uses an ARM chip for example. Bluestacks and NoxPlayer could be rewritten to have vitalization rather than their current emulation structure which would speed them up significantly and that opens the Mac to a good hunk of the Android's gaming library.
There are supposed to be some very involved discussions going on between Microsoft and Apple. I have no doubt that some of that involves getting Windows onto the AS Macs in some form. Rene Ritchie has repeatedly said that the issue with getting Windows on the AS Macs is NOT a technical one, but an issue with Microsoft's licensing, and that is what is under discussion, along with other things (as in the XBox Game streaming, probably access to Microsoft Servers, things like that). Nobody has said anything about it, but it is possible that an X86/x64 emulator/translator/hardware abstraction layer/etc. may be part of it. Its not like it isn't something that Microsoft can't use outside of the AS Mac anyway, as it could be used on ARM Windows machines.
Last edited:
Technically Windows for ARM probably could run on AS Macs right now if Apple agreed to sign it but it needs work in order to get it up to the standard of regular Windows.
The interesting question is who is driving the idea? Are Apple asking Microsoft to license (and improve) Windows for ARM to run on Macs, or are Microsoft asking Apple if they will allow it to be installed providing they make it work right?
The interesting question is who is driving the idea? Are Apple asking Microsoft to license (and improve) Windows for ARM to run on Macs, or are Microsoft asking Apple if they will allow it to be installed providing they make it work right?
That, nobody can really say. This is only part of a range of issues being discussed, and it is unknown what the exact range of issues are being discussed, and we will probably never know. This is an extension of the direction that Microsoft has been going towards (i.e. platform agnostic). While Microsoft has always had a presence in the Mac software market (mostly Office), they have branched out into some Linux and Android stuff as well. Some see it as a way for Micosoft to start breaking its dependence on the Windows PC world, and branch into mobile (they also make Android apps and casual games) and cloud based offerings..
Back in 2007, as a former pc-user, I would never would have the courage to make the transition to mac (a whole new unexplored world for me back then), if I didn't know that I can run windows on my mac anytime I want.
The transition to intel, was not made for allowing users to run windows on macs, but the new capability given to us, gave us all the reasons to make our move towards mac world without further hesitation.
It moved people towards the mac platform, as a good strong additional reason.
Bottom line, from my perspective, we still need this opportunity to run windows on new macs.
Apple and Microsoft should make something about it.
Also I would like to know about what is parallels possibly do on this particular topic too.
The transition to intel, was not made for allowing users to run windows on macs, but the new capability given to us, gave us all the reasons to make our move towards mac world without further hesitation.
It moved people towards the mac platform, as a good strong additional reason.
Bottom line, from my perspective, we still need this opportunity to run windows on new macs.
Apple and Microsoft should make something about it.
Also I would like to know about what is parallels possibly do on this particular topic too.
I think what people need to understand is that you could emulate x86 on pretty much any modern CPU.
The big question is "how fast".
Bochs has run x86 on different platforms since the early-mid 90s and is 100% opens source.
It just depends how fast you need things to run
Also, specifically check this out:
The big question is "how fast".
Bochs has run x86 on different platforms since the early-mid 90s and is 100% opens source.
It just depends how fast you need things to run
bochs: The Open Source IA-32 Emulation Project (Home Page)
Bochs IA-32 Emulator provides a virtual PC that can run operating systems such as Windows, Linux, and BSD.
bochs.sourceforge.net
Also, specifically check this out:
x86 emulation might struggle if there is no hardware acceleration as shown in the following video.
Run ANY OS on iPad or iPhone!
The URL link was borked to the point of unusable (have no idea why) but I think I fixed it. Also note that this a third party x86 emulator that was only installable via jailbreaking ie of questionable quality.
That used to be the case. There were certain x86 commands that had to be run at a high security level than the hyper visor and traps and work around put in place. This was what made VMWare a rich and successful company.
Intel gradually improved virtualisation support vt-d etc so that this isn’t required. Performance running on a hyper visor on Intel is basically native.
Arm are a little behind in this regards. Hence the quick interim releases in their Architechiture armv8a-5, 6, 7 etc. DTK doesn’t support Apples new hyper visor code, so the A14 must be one or more arm architecture revisions higher than the a13.
More than likely the A14 itself won't have a hypervisor core, as there is no reason for it. The Mac SoC, which is a specific SoC for the Mac will, because there may be a use for it. Even though the CPU and GPU cores will be common between the A14 and Mac SoCs, there are going to be some elements that are only going to be in the A14 SoC (like the cell phone and rear camera controllers) and others (like USB/TB controllers) that will be specific to the Mac SoC. The Hypervisor core will be in the Mac SoC; it won't be in the A14.
No reason?
One of the biggest security wins in the past two decades is running things isolated in a virtual machine.
Also you don't really have a "hypervisor core". You have instruction set extensions to support virtualisation... they will be common to all A* CPUs moving forward, no doubt. Apple already demonstrated virtual machines running on the A13Z, they will continue to be present in future processors.
THe A14 family for mobile devices won't have a hypervisor core because it will eat up more power and use up silicon area that could best be used for something else. They probably will have virtualization instructions, but no physical core. The iPhones and iPads don't seem to have security issues even now, without a hypervisor core or instructions, because as a very strictly controlled, closed system, there is no need for it.
The Mac SoCs will have a silicon hypervisor core. It was stated as such in the WWDC announcement. Not instructions, a physical core separate from the CPU cores.
- The A12X/Z already did.
- They're not going to go backwards, and
- I'm not sure you realise how relatively trivial it is to add virtualisation support to a CPU that already supports memory protection/sandboxing. It's not a whole heap of extra silicon required. Its a couple of tweaks to some instructions that are likely already there - if not present for the past 10 years.
Popek and Goldberg virtualization requirements - Wikipedia
Also (and this is getting off tangent from x86 specifically - which you likely WON'T be able to virtualise on ARM Macs) - ARM has been able to run KVM since somewhere around 2010
Armv7 and V8 (and up) optionally support virtualisation
Xen ARM with Virtualization Extensions - Xen
Last edited:
I did not say that A12....A14 don't/won't support virtualization. What I said was they won't have a separate virtualization core/block/whatever you want to call a separate, disctinct chunk of silicon. The Mac SoC will. Popek and Goldberg are talking about software. I am talking about hardware. See brief mention in the Rene Ritchie video, interestingly enough, released today:
Specifically, listen at 4:30 onwards where he talks about virtualization being necessary to the Mac SoC, and how it makes it different from the iPad SoC, and how this will probably be implemented in silicon, NOT software.
He also talks about why the Mac SoC will not be an A14X at 3:16, but of course people are going to keep nattering on about the A14X iPad SoC being in the low end Mac laptop, and the China News (a questionable source, with not track record to speak of) talking about a MacBook replacement as the first unit out, when all of the reliable leakers have already achieved consensus on the MacBook Pro coming out first.
Specifically, listen at 4:30 onwards where he talks about virtualization being necessary to the Mac SoC, and how it makes it different from the iPad SoC, and how this will probably be implemented in silicon, NOT software.
He also talks about why the Mac SoC will not be an A14X at 3:16, but of course people are going to keep nattering on about the A14X iPad SoC being in the low end Mac laptop, and the China News (a questionable source, with not track record to speak of) talking about a MacBook replacement as the first unit out, when all of the reliable leakers have already achieved consensus on the MacBook Pro coming out first.
It would need to, at a minimum, implement a subset of x86_64 assembly and properly trap unrecognized opcodes. I don't think the runtime needs to be identical. They don't need to emulate store forwarding or other such features. If it was me, I would make AVX2 the cutoff and ignore SSE and AVX512 completely, aside from scalar instructions that lack a VEX prefixed version. I think a few of them still only have 2 operand forms. AVX2 also implies FMA3, but Neon has some form of FMA available. I would ignore all AMD specific opcodes if this is being written specifically for OSX and macs. It's easier if the software believes its target is intel.
Code compiled for Skylake like architectures is pretty regular, as on the intel end a lot of operations that had 3 or 5 cycle latencies on earlier architectures standardized to 4, and most things can issue on 2 ports. As a result, a lot of low level code could still be efficiently implemented in ARM. It lacks the ability to issue arithmetic instructions with memory operands, but it exposes 32 Neon register names with 128 bit widths as opposed to 16 at 256. Unless it needs more space for something, this could work okay.
What is it that you imagine a "virtualization core" is? What would be an example of an existing CPU that has something like this? What you are saying makes absolutely no sense to me at all.
That statement isn't wrong, but I don't think thatit means what people think that it means. From this Apple document:
What that is saying is that Rosetta won't run the x86 version of Parallels/VMWare etc. Which is kinda confirming the bathroom habits of forest-dwelling bears if you think about what that would entail.
It says nothing to deny the possibility of x86 emulation on Apple silicon (...go look at the youtube videos of iPads running x86 MacOS under QEMU), nothing to exclude ARM virtualisation (Parallels for ARM was shown running ARM Linux at WWDC - my guess is that it's based on the Hyopervisor kit built into window) and nothing to say that Apple couldn't adapt Rosetta technology to allow MacOS's built-in hypervisor to run x86 hosts using some sort of just-in-time translation (...that's pure speculation and far more easily said than done, but no laws of Physics would be broken).
If Apple/Microsoft co-operate to allow Windows 10 for ARM to run as a VM (it's not going to 'just work' but if Apple/MS sort out the licensing it will be made to happen), then that has x86-32 translation with x86-64 promised real soon now, and would probably be the best way of running x86 Windows apps on AS - because (like Rosetta) it's only translating/emulating the application, not the entire OS.
The Apple A13 uses the ARMv8-4A instruction set (link) and looking at this Wikipedia page (link) there were several upgrades to virtualization support between v8-A (A12) and v8.4-A (...and I'm not saying that v8-A/A12 didn't have virtualization support, just that v8.4-A definitely does).
No, they're talking about "virtualization" in the modern sense of running code directly on the CPU and 'trapping' critical instructions to give the effect of a virtual machine. More to the point they're talking about the minimum requirements for doing it efficiently (...and removing the need to pre-translate the guest code to add trap instructions). Hyoervisors for x86 (and not old-school 'SoftPC'-style emulation software) appeared before Intel added the VT-x instructions to make it more efficient - and even "inefficient" virtualization blows emulation out of the water.
Last edited:
Intel and AMD would never let them license x86 in full but maybe if it was just for one x86 core per CPU....