You mean a third time though! The mac went through three architecture transition, and each came with an emulator to keep compatibility for a while. The first one was when they went from Motorolla 68000 to PPC, and they built the Mac 68k Emulator[0] to keep software going.
I also think they could pull it off again. Microsoft has shown us that it's possible to run a lot of x86 software on ARM64 with little noticeable impact[1]. It would, however, require immense engineering effort.
[0]: https://en.wikipedia.org/wiki/Mac_68k_emulator
[1]: https://docs.microsoft.com/en-us/windows/uwp/porting/apps-on...
Emulating x86 on ARM is very hard because x86 has a strong memory model while ARM has a weak one. This either makes emulation very slow or will break lots of multithreaded applications.
The other emulation direction (ARM on x86) works much better.
If emulation were taken seriously, Apple could add extra features to their ARM-ISA processors in support of x86 emulation, including x86 compatible implicit memory barriers.
In fact, out of Intel and ARM, ARM is the only one I know that tried to shut down software emulation...
(ARM blocked parts of QEMU from being published for a while, citing "you must have read the manual to implement this therefore you are bound by the terms of the manual". They also had an open source design removed from OpenCores.)
It would not be completely silly to modify QEMU with x86 guest and modified-ARM target (for implicit-barrier mode), and then just use QEMU for the emulation.
As long as implicit-barrier mode was generic enough I think Intel would have an interesting time claiming it infringed some patent of theirs. Making it efficient would remain Apple's problem but they are good at that. (Or were until the CPU designers left to start Nuvia.)
If Intel won that, implicit-barrier would have to be explicit-barrier which is just normal ARM, but there is no fundamental reason why that cannot be fast, if the processor is designed to expect a lot of barriers and optimised accordingly. Especially if a dense instruction encoding is created for it.
(Everything I just said applies to RISC-V as well as ARM, should Apple decide to change course again.)
https://www.forbes.com/sites/tiriasresearch/2017/06/16/intel...
Thanks for clearing that up. Wonder what the difference is that this article mentions.
But most apps are not very parallelized, only computationally heavy ones are. Those are of course going to suffer from emulation anyway. As a performance lower bound we can imagine that it would emulate a single-core x86 so the memory model differences wouldn't come into play.
Microsoft already has x86 emulation working in Windows for ARM, anyone know implementation details of that, or even publications?
It seems to depend on a feature that is specific for Qualcomm processors: https://news.ycombinator.com/item?id=14318877
I know that to be true, but could you point me to some articles and documentation that tell more. I'd like to learn more.
Apple has already done this. The 68K to PPC transition wasn't nearly as quick as the PPC to x86 transition. They released new 68K Macs after releasing PPC Macs. The apps were "fat binary".
When I bought my first PPC Mac, all of my apps were on an external SCSI drive. I attached the drive to PPC Mac and it ran native software.
If the processor advantage never reaches the point that it can emulate x86 at full speed, then the Mac line probably won’t transition,
Again it doesn't have to. I had a first generation PPC Mac 6100/60 that ran emulated code slightly slower than my accelerated 68030-40Mhz LCII. My 68K Mac was about half the speed of the high end 68040-40Mhz Macs. It couldn't emulate programs that used the 68040's FPU at all. There were third party hacks that you could run like SoftwareFPU (a 68K program nonetheless) that could emulate an FPU.
The high end programs are always the first to be ported. The other apps are "good enough" and depending on how much time an emulated app spends running native operating system code, it won't be all emulated.
It took me forever to realize where the name came from.
“Close but no cigar”.
But that’s still a tall ask at the high end, and splitting the Mac lineup into models that can’t all run the same software isn’t appealing.
So in the meantime, it makes sense to push the iPad toward being a stronger and stronger computing platform with things like the recently added trackpad, better multi tasking, etc. They’ve got a way to go, but given a few more years of iteration, who knows how many more of the “real computer” niches the iPad can fill.
If the processor advantage never reaches the point that it can emulate x86 at full speed, then the Mac line probably won’t transition, and Apple will probably shift it farther upmarket as the iPad cannibalizes every use case that doesn’t need x86. And if the processors do get that much better, then ARM comes to the Mac.
Either way, Apple is in a good place to leverage the iPad as their vision of what the next generation of the personal computer looks like.