Re: @Charlie Clark
"the second best way would be to translate the x86 opcodes into ARM equivalents. This would be very difficult"
What makes you say that? E.g. Something very similar was done many years ago (1990s) by DEC with their FX!32 package which took Win32/x86 binaries and translated them on the fly into Win32/Alpha binaries as the program runs (caching the translations for later), by translating x86 code sequences into code sequences for DEC's Alpha processor.
This technology may not be for the faint hearted, but it's not new, and it can work.
You may apparently also be unaware that Intel's Android phones have an ARM to Intel translator/emulator of some kind for apps which use native ARM code rather than pseudo-Java.
"and the result would be slower than if the code were executing on an x86 chip."
Don't you think it might depend on which x86 is being compared with which non-x86?
Don't you think it might depend on what you were planning to do on the system? You might not want to use translation/emulation for a compute-intensive piece of code, but for something that spent 99% of its time idly waiting for events (like a lot of systems do a lot of the time) , you'd hardly notice.
"The third best result (and easiest to implement) would be to interpret the x86 opcodes at runtime. That would make x86 binaries run between one and two orders of magnitude slower than they would on Intel hardware."
"Easiest" would be instruction by instruction emulation, which would indeed not be quick.
Relative performance would depend on which x86 is being compared with which non-x86.
A faster but slightly more difficult approach might use something like the "dynamic translation" found in e.g. QEMU which is sort of a half way house between a simple emulator and a complex translator such as FX!32.
It's far from impossible. Is it sensible from a support point of view? Different question altogether. Intel seem to think the ARM->Intel translation is supportable for phones.