Is it possible to compile a binary which will run on both x86 and ARM

Question

It does not necessarily need to be an entire program, just a simple operation which performs the same action on both processors.

Without CPU emulation such as qemu.

If this is not possible, can you explain to me like I am 5, why it is not possible.

Answer 1

It's possible to write polyglot machine code, which decodes on x86 as a jump to more x86 machine code (which doesn't have to be valid ARM machine code). And if executed on ARM, it ends up executing a different part of the code.

So you'd have one small part of the machine code which can be decoded as instructions for either ISA, jumping to separate destinations depending on which.

For example, https://news.ycombinator.com/item?id=27033330 is a 4-way polyglot for x86, ARM, AArch64, and MIP(little-endian). Each different interpretation of the code branches to a different relative offset. (Before reaching any instructions that would do more than modify registers.) I googled polyglot arm x86, there are likely others. Also related: x86-32 / x86-64 polyglot machine-code fragment that detects 64bit mode at run-time? is a polyglot for multiple modes of x86, which use the same machine-code format but different defaults for operand-size, except for 64-bit mode which changes the meaning of some opcodes.

It's not practical (or likely possible) to write an entire program this way, nor for the code to do the same things on both ISAs. If they have the same machine-code format, they're the same ISA (assuming other things are the same, like memory-ordering semantics, and a bunch of kernel stuff like interrupt handling, page tables, TLB invalidation semantics, etc.) ARM and x86 are not the same ISA, using very different machine-code formats.

---

Of course, normally a "fat binary" doesn't need that, you have metadata which tells the OS's program-loader which part of your program is which. (A "fat binary" being one with multiple versions of the machine code, usually compiled for different ISAs.

MacOS had this during the PowerPC to x86 transition, you could have one file that was about twice the size, but would run on either. And now they have it again with x86-64 and AArch64. When you run that executable, an x86-64 MacOS will see that there's a "slice" for x86-64, and run that part of the program the same as if it was the only thing in the executable. But an AArch64 MacOS would look for an AArch64 slice in an executable, and run it if found.

If the OS doesn't find what it's looking for, the execve system call will return an error about invalid exec format. It won't map AArch64 machine code into memory and jump to it, on an x86-64 machine.

Answer 2

This is an old question, but I just found this via a Google search and want to try and clarify for anyone else who might stumble upon it.

In short, x86 and ARM binaries are incompatible, but I think this comment from the OP clarifies what the real question is:

If two chip manufacturers decided to use identical instructions, i.e. ADD = 0101 then are there any other reasons why object code generated for one will not work for the other? I'm looking for more of a list of arguments here not just the most obvious one.

If hypothetically two chip manufacturers decided to use identical instructions/encodings/pipelines, then yes they'd be able to run the same code, but that's because they'd already be using the same ISA.

Intel and AMD designs for x86 processors are typically very different from a physical perspective¹, but those different chips from different manufacturers are able to run the same code precisely because they've "decided to use identical instructions".

x86 and ARM themselves aren't really "chip" designs, but they're specifications of an abstract machine². There's a strong link between the physical design/implementation and how the instruction sets and pipelines are defined because there will be obvious efficiencies to certain approaches, but an "ARM" processor doesn't have to confirm to any specific physical design. An "ARM" processor just has to provide the same programming model as the "ARM" abstract machine.

In theory there's nothing stopping any one "chip" from implementing both x86 and ARM instructions as long as it had a way to distinguish between then, but it would probably be a hugely inefficient waste of money, power and resources. The current momentum behind ARM is at least partially due to the bloat that x86 has built up over the years, so combining the two would probably give you the worst of both worlds.

---

_{1 - Take this with a grain of salt, as processor architectures are changing rapidly, but from what I understand Intel tends to design monolithic implementations and AMD tends to design chiplet implementations.}

_{2 - This is a simplification, but "x86" and "ARM" are actually whole ISA families, and both can refer to a large number of different standards with various optional extensions.}

Answer 3

It is possible if you don't compile directly for the specific ISA, but it is still work in progress. Have a look at Transmeta. What they do is insert a layer on top of the internal architecture that accepts "generic" code. You can think of it like a JVM in hardware, at a very high level of abstraction.

Answer 4

It would be like trying to read English with a french dictionary and vice versa.

Different CPUs are like different languages, only an emulator can act as an
interpreter to let a program for an architecture be run on an other.

Answer 5

No it's not. Program executed by the CPU are encoded in machine language. x86 and ARM doesn't have the same instructions in their respective machine language, and the encoding are very different.