>>>>>> X86 emulation via an ARM processor? Sounds ugly. [...] the real question is
>>>>>> will they be competitive?

>>>>> No different to running 68k binaries on PPC with Trance really.

>>>> Pretty big difference, Nick. The PPCs we run Trance on run many times faster than a
>>>> 68K processor. The ARM processors will be running at comparable speeds (or slower)
>>>> to an X64. Which, with the overhead, will mean X86 apps will run slowly on ARM.

>>> It's like it's running native ARM code.

>> Even if this was true (which I don't think it is as there simply must be emulation overhead)

> Like means ‘similar to’.

I know. Jim's point you were replying to was about competitiveness of this emulation solution, aka relative execution speed. And I doubt that the execution speed of x86 code on ARM is in any way similar to the execution speed of native ARM code on the same ARM CPU for the simple reason that there must be significant emulation overhead.
The fact that Microsoft's video only shows situations where this overhead doesn't seem perceptible is not surprising at all, after all that's the very purpose of that video. I'm sure eventually there will be independent side-by-side comparisons with native ARM code on the same ARM CPU and with the same x86 code on current x86(-64) CPUs. That's when we will know. Until this point I will maintain my opinion (which is shared by knowledgable people, btw).

>> it's still different to "running 68k binaries on PPC with Trance" for the reason
>> Jim mentioned.

> It's very much like Trance. The x86 binary is dynamically recompiled and calls
> native ARM libraries as though they were x86 libraries.

As I see it, Jim was talking about the anticipated speed of that solution, not about the implementation concept.

>>> https://youtu.be/A_GlGglbu1U

>> No side-by-side comparison with native x86 speed (or native ARM speed for that matter).

> Your entire post is based on your misunderstanding of the meaning of
> the word 'like' as used in this context.

I think your entire post is based on your misunderstanding of what Jim and I have been referring to. And I'm going to spare you the link to the Wikipedia article about hardware emulation ;-)