Not exactly. Rather, it’s ARM software running on an ARM chip. It’s translated in advance. That means there’s no emulation overhead, but there may be an overhead anyway from inefficiencies in the translation. Plus there are certain instruction sequences that just won’t run if apps are using them directly (though if they use them indirectly via Apple’s frameworks they’ll work, and in any case the programs that use these are the most likely to be updated).
The rest of this is true, though, and I echo your reasoning: I expect the products that Apple ships will be much faster than the DTK.
I’m wondering if Windows VMs in Parallels will continue to work via Intel emulation.
But what I REALLY would love to see is MacOS running on iPad Pro HW, with the new Magic Keyboard & trackpad, and the Apple Pencil. That way I could travel with just an iPad.
In principle that might be possible since there will be a common instruction set. But Apple would have to allow for it which I highly doubt. Mac apps (including the entire OS) will have been designed with far superior performance in mind than what an iPad usually offers. Case in point: the current DTK is based on roughly current iPad Pro performance level, yet nobody believes that retail arm64 Macs will perform at this level. Far from it actually, at least according to those championing this transition from x86 to arm64.
It might be possible in theory, but very very unlikely, and for perfectly good technical reasons.
Rosetta works by “compiling” x86 code into ARM code. It is designed to translate all of the instructions that are likely to be used by applications. But it doesn’t translate all of them. Apple has, for example, said that not all of Intel’s latest vector math instructions will be supported.
It is also highly unlikely that they will translate privileged instructions and registers that are only used by operating system kernels. For example, those used to manage virtual memory page tables and direct access to PCIe buses.
All hypervisors work by intercepting access to privileged instructions and registers, redirecting them to manipulate virtualized versions of the corresponding hardware.
In a Rosetta environment, those instructions will have to be compiled into the ARM-equivalent privileged instructions/registers. Then the hypervisor’s code to trap the illegal accesses must be compiled into ARM code that can trap the translated privileged instructions. That’s a pretty ugly bit of code. It could certainly be implemented, but that’s a big engineering effort for something that is literally only useful for implementing x86-based VMs.
Any project for running a non-Mac x86 OS software will probably involve emulating the x86 platform (e.g. via QEMU). Fortunately, it should be possible to develop such a package (e.g. porting QEMU) without Apple providing explicit support for it.
I wonder if there will be a port of DosBox for ARM-based Macs. I saw a forum thread from 2006 where someone was working on developing an x86-ARM compiler module for portability to tablets and phones, so I’m hopeful that there are people with the skills and desire to develop this port.
But those issues pertain to running x86 apps through Rosetta 2.
If however you just take vanilla Big Sur along with arm64-compiled Mac apps all that should in principle run on an iPad. My point was that just because it can be done does not necessarily mean Apple would want it to be done, especially not if performance is bad and hence the entire user experience suffers.
I’m sorry, I got a bit turned around. There are two interlacing threads here - one about running Windows VMs (which I was talking about) and the other being ARM macOS on iOS devices.
The latter, as you point out, is theoretically possible, but it would require the installation of a VM or container environment on the iOS device. This kind of software has never been permitted on the iOS platforms in the past, and I wouldn’t expect it today.
Indeed. These are important caveats, and they were the same in the transition from PowerPC to Intel (although there we were going from VirtualPC to real PC!)
My day job involves a lot of JIT (Java compilation and execution) and running, testing and debugging Linux x86 execution environments under Docker and VirtualBox
Realistically, today, there’s no way we can avoid x86 (Java code does not run in a vacuum, and some of our third party tooling is currently x86 specific. While that may change, and AWS have just started offering ARM servers, Linux x86-64 servers seem destined to be with us a while yet)
Mac will remain my own personal choice but I shall greatly miss being able to work in a MacOS environment in my day job, as I’ve enjoyed for the last 10 years, once the x86-64 Apple hardware is obsolete.
I doubt that they “knew”, but I’m sure they suspected.
Apple silicon (fabed by TSMC) started using 7nm in the A12 (September 2018) and 10nm in the A10X (June 2017). The fact that Intel hasn’t been able to keep up so far is enough to make one wonder about their abilities going forward.
And as a close Intel partner and good customer (so far at least) Apple was certainly privvy to more information than the general public, and definitely at an earlier stage.
Now we just need to see first Apple Silicon perform thrice as well at half the wattage in shipping Macs and we should be good to go for the next few years.
I do feel compelled to quote this little gem of corporate newspeak.
Intel CEO Bob Swan said the changes are intended to accelerate product leadership and improve focus and accountability in process technology execution.
I’d be tempted to ask a friendly fellow poster to translate that to common English, but I’m afraid we all know where that would end up.
In a few years, there may be almost no difference between a Mac and an iPad. Both will run the same OS and the difference (whether multi-window and menus Mac or whole screen and touch iPad) will be based on the size of your screen and your input devices.
I can see an iPad Pro where attaching a second large screen, a keyboard, and mouse will make the OS look like it was on a Mac.
Here’s another reason for Apple to move to its own custom chips—more control over security. This isn’t to say that Intel necessarily did anything horribly wrong, just that Mac users may be impacted by the Intel breach.
