Could x86-64 emulation be possible on ARM Macs?

[Nugget]

As I said rumor is there is a joint effort by Apple and Microsoft to do deal with the x86 code to ARM issue: Microsoft has the 32-bit stuff Apple doesn't care about (but the PC community does) and Apple has a robust 64-but method (which Microsoft says won't be a thing until 2021).

It's an interesting rumor, but I'm skeptical because I don't know how Microsoft's 32-bit translation for Windows binaries could be utilized on 64 bit Apple Silicon that (by all estimates) probably won't have the ability to run 32 bit code. I'd be amazed if Apple Silicon will be able to run Arm32 binaries, much less translated Win32 binaries.

Secondly, Apple's "robust 64-bit method" is intrinsically tied to macOS binaries and libraries. Microsoft would not have much use for that.

At least that's my understanding.

 

[thekev]

As I said rumor is there is a joint effort by Apple and Microsoft to do deal with the x86 code to ARM issue: Microsoft has the 32-bit stuff Apple doesn't care about (but the PC community does) and Apple has a robust 64-but method (which Microsoft says won't be a thing until 2021).

The 32 bit stuff comes up in a lot of awkward places. In particular libraries designed for Linux and ported to Windows often run on Win32, since common 64 bit Linux distros use different data type sizing than Microsoft. On 64 bit Linux the "long" type tends to be 64 bits, but it's still 32 on Windows. Long long is 64. It's a point of incompatibility for the RPython part of PyPy and a few others. It might be for Cython. I haven't checked that one.

Data Type Ranges

Learn more about: Data Type Ranges

docs.microsoft.com

All of this, as you might have guessed, can make the experience of running x86 programs a comparatively slow experience. However, a cache of already-translated code (located in C:\Windows\XtaCache) eliminates much of the overhead. A compiler (xtac.exe) and background caching service (XtaCache) handle full binary translation and caching. Hybrid binaries (located in C:\Windows\SyChpe32) containing x86-to-ARM stubs also help to reduce overhead." - Teardown: Windows 10 on ARM - x86 Emulation

I tend to view JIT solutions as a mess when they apply to something that is already some type of assembly, just because it's virtually impossible to maintain exact compliance with the various trap codes and runtime details that might have been expected prior to that.

 

[Maximara]

I tend to view JIT solutions as a mess when they apply to something that is already some type of assembly, just because it's virtually impossible to maintain exact compliance with the various trap codes and runtime details that might have been expected prior to that.

You have to admit that Apple did an incredible job with the 68x00 to PowerPC port. Of course there were hiccups, (this is, IMHO, why Sheap Shaver sometimes barfs in its PowerPC-MacOS emulation - there are these weird little pieces of code that just don't line up) but the level it worked at is still impressive. As I noted on these boards World Builder a game creation programs from 1986 writer in 68000 assembly ran all the way up to Lion in 2011. Admittedly the change over did clobber the sound but that it worked at all tells you something.

 

[Maximara]

Except in the datacenter no sane operator will accept emulation OR translation: They will want native software with predictable performance and predictable patterns when things start falling apart.

Graviton2 of Amazon says "Hi!"

 

[Mikael H]

Graviton2 of Amazon says "Hi!"

Yep.

 

[b0fh]

I've used QEMU to emulate x86 and x86-64 on ARM and PowerPC so it's definitely possible but slow. Very slow.

But aren't those platforms slow to begin with, especially if you compare to the current x86. Or did you mean you tried it back at its heyday?

 

[Maximara]

But aren't those platforms slow to begin with, especially if you compare to the current x86. Or did you mean you tried it back at its heyday?

Right. Also when I looked at QEMU it takes about ARM as a guest not a host. As someone who has fiddled with Bluestacks and Nox on a Mac watching an Intel Mac emulate any ARM chip is slow. Not to the point of unusable but slow.

 

[theluggage]

Right. Also when I looked at QEMU it takes about ARM as a guest not a host. As

You'd think that, somewhere, there would be a page listing the host CPUs supported by QEMU in large, friendly letters but I can't find one (which probably means "its complicated") I can't even find a statement confirming that it runs on x86 - but people have built it on a Raspberry Pi and it runs like treacle on valium (but then... that's a $30 buck maker board built from surplus set top box chips).

There's also a port of QEMU - UTM - to (jailbroken) iOS and if you google around you'll see videos of iPad Pros running MacOS (very slowly) - but see the FAQ for some of the reasons why it is so slow (even running ARM guests - and I guess the lack of hardware virtualisation on the A12 etc. also slows down translated x86 code). You can't read much into its performance - its a zero-resources project on a heavily locked-down system that doesn't even have the hardware resources to virtualize a full desktop OS at the best of times...

Back in the day, emulation of x86 on 68k, PPC and ARM (yes, folks, I remember running Windows 3.1 under emulation on an Acorn) was always too slow for demanding software but filled a useful niche for running those odd bits of business/productivity/utility software that you had to use for work. Emulation technology has improved since then so - especially with a bit of support from Apple (and maybe a pinch of Rosetta technology) - there's no real obstacle to a usable x87 Windows/Linux emulator for ASi Mac. It's just not going to be a solution for running pro creative software or non-casual games.

...but the reality check is that, if you're using your Mac to run demanding Windows x86 software, it's probably time to go shopping for a PC or get a new Intel Mac to tide you over.

 

[Nugget]

You'd think that, somewhere, there would be a page listing the host CPUs supported by QEMU in large, friendly letters but I can't find one (which probably means "its complicated")

As an emulator, QEMU (system mode) isn't really as complicated as you're imagining. It's not relying on hardware assists that are baked into the silicon like you'd see with virtualization technology. In reality, QEMU will work on pretty much any system where you can get it to compile and isn't intrinsically tied to any specific CPU architectures. So it's not that it's complicated, but rather that it's very uncomplicated. There's source code that emulates a variety of architectures and that source code is actually quite portable (within the general posix/unixy ecosystem).

It's great that it exists, but as you say -- performance from CPU emulation ranges from "comically unusable" to "hey, I can make this work in a pinch, but damn." It's an impressive technical accomplishment no matter what your perspective is.

 

[theluggage]

As an emulator, QEMU (system mode) isn't really as complicated as you're imagining.

As I understand it, QEMU supports a range of options including 3 different JIT/Translation/Emulation engines and support for hardware-assisted virtualisation, and can be a reasonably efficient hypervisor on the right host system. So its level of usability depends a lot on the host platform (which is what I meant by "It's probably complicated".

 

[Nugget]

As I understand it, QEMU supports a range of options including 3 different JIT/Translation/Emulation engines and support for hardware-assisted virtualisation, and can be a reasonably efficient hypervisor on the right host system. So its level of usability depends a lot on the host platform (which is what I meant by "It's probably complicated".

Yeah, I was speaking specifically about the full system emulation which would be the relevant function for this thread.

 

[Gerdi]

As I said rumor is there is a joint effort by Apple and Microsoft to do deal with the x86 code to ARM issue: Microsoft has the 32-bit stuff Apple doesn't care about (but the PC community does) and Apple has a robust 64-but method (which Microsoft says won't be a thing until 2021).

Microsoft does not need Apple for that. x86-64 emulation on ARM is going live next month in the insider preview fast channels.