4 ms·
> One day they _may_ be sufficiently better than Intel that Apple could pull a “Rosetta” a second time on the Mac, translating apps from x86 to ARM at the softw
by wolfgke 7y ago
> One day they _may_ be sufficiently better than Intel that Apple could pull a “Rosetta” a second time on the Mac, translating apps from x86 to ARM at the software level.
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.
- jlokier 7y agoThat's true for now. But due to RISC-V's openness, ARM has recently started allowing licensees to add extra features to the architecture. 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.
- doyouevensunbro 7y agoDon’t they still have to deal with the fact that Intel has been vocal about suing anyone doing x86 emulation?
- jlokier 7y agoQEMU exists and so do others, and has for many years, so I think x86 software emulation might turn out to be fair game. 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.)
- doyouevensunbro 7y agoOk I’m not completely crazy, found the article: https://www.forbes.com/sites/tiriasresearch/2017/06/16/intel-threatens-microsoft-and-qualcomm-over-x86-emulation/ https://www.forbes.com/sites/tiriasresearch/2017/06/16/intel... Thanks for clearing that up. Wonder what the difference is that this article mentions.
- scarface74 7y agoThere have been x86 emulators forever. I had SoftPC in 1992
- mrpippy 7y agoHave they? I've never heard anything about that. Microsoft has been shipping x86 emulation in ARM64 machines for the past few years. (And does original Xbox back-compat emulate x86 also? Or was it statically recompiled to PPC somehow?)
- fulafel 7y agoI think it's a safe guess that such an emulation would be made correctness-first. 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?
- wolfgke 7y ago> 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 https://news.ycombinator.com/item?id=14318877
- kyberias 7y ago> Emulating x86 on ARM is very hard because x86 has a strong memory model while ARM has a weak one. 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.