W10 Mobile x86 .exe Emulator

[Drael646464]

Worth remembering that WoW is an emulation (running 32 bit windows applications on a 64 bit windows OS). And this specifically runs only win32, on a 64 bit chip.

 

[a5cent]

When they first demo'd it the QUALCOMM person said it was running on an unmodified chip. (820 I believe). I don't think there is any hardware component.

Yes, I know. However, Qualcomm and MS had already been working on the technology for quite some time at that point. Whatever MS is using for ISA translation was already available in the SD820. For some unknown it reason it apparently just wasn't yet good enough.

You are of course free to believe whatever you want to believe. However, assuming MS' claim of near native performance is true (which is yet unproven), then you might as well believe people can fall upward. The idea that near native performance, while performing on-the-fly ISA translation, is possible without any hardware support is equally ridiculous.

 

[Rosebank]

The idea that near native performance while performing on-the-fly ISA translation is possible without any hardware support is equally ridiculous.

What sort of Hardware support do you think is involved? Other than the CPU (835) the RAM and nice compact board with its components, what else is there involved? some sort of turbo device?? What could that be? or another CPU involved in brute force processing? I cant think of what other Hardware we could be talking about?

 

[Drael646464]

Yes, I know. However, Qualcomm and MS had already been working on the technology for quite some time at that point. Whatever MS is using for ISA translation was already available in the SD820. For some unknown it reason it apparently just wasn't yet good enough.

You are of course free to believe whatever you want to believe. However, assuming MS' claim of near native performance is true (which is yet unproven), then you might as well believe people can fall upward. The idea that near native performance, while performing on-the-fly ISA translation, is possible without any hardware support is equally ridiculous.

They do have the advantage of having arm versions of all the OS side stuff, and like WoW, the spare "bits" from using a 64 bit chip on 32 bit software.... I suppose you are potentially right that there is some hardware component? but I'll believe 'near native' when I see it.

We haven't seen windows on arm do anything demanding yet. How exactly "near" is "near" anyway?

I'm not making any assumptions about performance yet. I like you however assume that if it is truly near native, then it'll be hardware based to some degree, even if that hardware difference is very simple one.

 

[Rosebank]

This is interesting too, this is what I watched about a week ago. >>
https://youtu.be/oSXUDKpkbx4

I went to MS channel 9 as the Qualcomm tech guy stated there was more detailed info on the Emulator but I cant see anything there that is relevant.
I already posted this link on page 8 of this Thread but its all I can see which is fairly up to date >> https://channel9.msdn.com/events/Build/2017/P4171
So nothing new as of yet regards the Emulator.

 

[Grant Taylor3]

This is for legacy Win32 32-bit applications so they are limited to 4GB of RAM.


Anything that needed more than 4GB of RAM or was 64-bit would need to be done as a UWP and put in the store.

If you look at the system requirements for these Win32 applications they will run happily on a 10 year old PC so a modern SD835 should have no issue.

If you want to see it the other way take a look at AMI DuOS that runs ARM Android apps on the fly on X86 Windows.

 

[a5cent]

What sort of Hardware support do you think is involved? Other than the CPU (835) the RAM and nice compact board with its components, what else is there involved? some sort of turbo device?? What could that be? or another CPU involved in brute force processing? I cant think of what other Hardware we could be talking about?

No. Certainly nothing of that magnitude. Whatever it is I'd assume it was also vetted a million times back and forth by lawyers as to whether or not it is defensible in court. I have no idea what that actually is, but it could be any number of things.

Maybe ARM added an instruction or two to their ARMv8 instruction set specifically for that purpose?

Maybe Qualcomm's recent CPUs internally implement a table that map x86 instructions to one or more ARM instructions? Maybe the Qualcomm CPU can use that table autonomously and directly feed the translated instructions into the execution pipeline? Such a translation mechanism must exist somewhere. If that was purely software based, like some here believe, then we'd be executing multiple instructions just to access the x86 to ARM translation table. That would incur an overhead of whatever the ratio between an x86 instruction and the number of instructions required to translate it is. For example, if we'd execute on average four instructions to translate an x86 instruction into an ARM instruction, which is already insanely optimistic (considering the huge mismatch between the x86 and ARM instruction sets), then we'd have already reduced performance to a quarter of what native speeds would be. This is simplified since not all instructions require the same amount to run, but I hope it illustrates the point.

I can think of a few other things, but I'm sure you get the gist of it now. It's "little" things, basically tweaks to the existing platform, made specifically for the purpose of x86 emulation.

 

[a5cent]

If you look at the system requirements for these Win32 applications they will run happily on a 10 year old PC so a modern SD835 should have no issue.

If you want to see it the other way take a look at AMI DuOS that runs ARM Android apps on the fly on X86 Windows.

*Facepalm*

If there was no ISA translation involved, sure. There is. Emulating a 4W mobile CPU on a 45W desktop CPU is also a completely borked analogy. Completely different situation.

 

[Rosebank]

What ever a Dynamic binary Translator is, it seems to be the key part to this, it "looks at chunks of Code and translates them to blocks of ARM 64 code at run time".

 

[Grant Taylor3]

*Facepalm*

If there was no ISA translation involved, sure. There is. Emulating a 4W mobile CPU on a 45W desktop CPU is also a completely borked analogy. Completely different situation.

The Baytrail Atom is not 45W processor.

 

[a5cent]

What ever a Dynamic binary Translator is, it seems to be the key part to this, it "looks at chunks of Code and translates them to blocks of ARM 64 code at run time".

Exactly. If you can dig up anything on that anywhere then please let us know! ;-)

 

[Rosebank]

Exactly. If you can dig up anything on that anywhere then please let us know! ;-)

:evil::grin:

 

[Grant Taylor3]

What ever a Dynamic binary Translator is, it seems to be the key part to this, it "looks at chunks of Code and translates them to blocks of ARM 64 code at run time".

What MS are doing sounds like a modern implementation of the old FX!32 that DEC came up with in the early 90's.

 

[a5cent]

The Baytrail Atom is not 45W processor.

True, but if you're going to bring this up as an example, then we also need to start talking about what you plan to emulate. 95% of Android programs are written in Java, a language and platform that were specifically designed to be hardware independent!

The "trick" is achieved by bringing a version of Android, compiled for x86, onto the PC and building a little bit of infrastructure around it to make it think it's running on an Android device. That little bit of infrastructure is the only part of this that even qualifies as emulation. That's almost nothing. As far as the Android app is concerned, there is no emulation occurring at all. It runs on the x86 based Java platform just as "natively" as it would on any other device. So, in 95% of all cases, there is absolutely nothing going on that is even remotely comparable to ISA translation!

It's a completely different setup!

However, bring in one of those rare Android C programs, thereby forcing it to emulate ARM, and you can watch your setup collapse to a crawl. I've witnessed this myself and it really wasn't pretty. Intel's more powerful CPUs can mask that performance hit though.

I'm going to leave it at that. As far as I'm concerned you're either comparing apples to oranges or have completely unrealistic expectations.

 

[Drael646464]

What MS are doing sounds like a modern implementation of the old FX!32 that DEC came up with in the early 90's.

I just looked that up.

"It analyzed the way programs worked and, after the program ran, used binary translation to produce dynamic-link library (DLL) files of native Alpha code that the application could execute the next time it ran. This way even in the early 1.0 release, the FX!32 achieved speeds for Win32 x86 applications that ran 40-50% as fast as native x86 code, with a 70% speed projected as likely with improved optimization."

That actually sounds like a plausible way of achieving "near native speeds" using only software. And it sounds quite a bit like MSFTs language around the emulation layer. too.

 

[a5cent]

That actually sounds like a plausible way of achieving "near native speeds" using only software. And it sounds quite a bit like MSFTs language around the emulation layer. too.

I agree that it would be the most straight forward way to achieve near native speeds. I disagree that it sounds like what MS has so far described. Admittedly, that hasn't been much, but from everything I've read it sounds to me like the opposite. To me it sounds like what MS is describing is on-the-fly ISA translation at runtime.

Do you have anything specific that would lead you to conclude otherwise? I certainly would be interested if you do.

 

[Rosebank]

Nice bit of info @Drael646464, very interesting.

 

[Drael646464]

I agree that it would be the most straight forward way to achieve near native speeds. I disagree that it sounds like what MS has so far described. Admittedly, that hasn't been much, but from everything I've read it sounds to me like the opposite. To me it sounds like what MS is describing is on-the-fly ISA translation at runtime.

Do you have anything specific that would lead you to conclude otherwise? I certainly would be interested if you do.

Well IDK if you can make any sense of this, but this is all we have right now, AFAIK.

"Kishan explained that rather than try to run some kind of dynamic emulation, Microsoft developed a “Compiled Hybrid PE” (CHPE) – a set of x86 DLLs with x86 data types, and ARM64 code.
“These are like perfectly pre-generated binaries”, he added."

https://www.theregister.co.uk/2017/...mtwist_comes_closer_with_first_demonstration/

Somehow its those CHPE binaries/dll's that do the grunt work, and make it so that its not actually on the fly. Which I suppose isn't exactly like FX!32. Those DLLS work with WoW and some kind of chipset emulation to produce the total effect.

It also sounds like those binaries are pre-existing somehow? Certainly its not all on the fly. In fact it looks to be as much not on the fly as possible if I am understanding that flow chart properly.

 

[Drael646464]

Perhaps its sort of the opposite of what was formerly mentioned - the OS creates the DLLs upon install of the software, instead of post-run?

Reading into the language of "pre-generated".

If that's the case we could expect a similar up to 70% speed? Thus near native, using software only?

 

[a5cent]

Somehow its those CHPE binaries/dll's that do the grunt work, and make it so that its not actually on the fly. Which I suppose isn't exactly like FX!32. Those DLLS work with WoW and some kind of chipset emulation to produce the total effect.

Yeah, I'm aware of that talk. I think you misunderstand.

They specifically mentioned that those CHPE DLLs are system DLLs! Those are already pre-generated by MS, simply by compiling their Windows system DLL's for ARM. They are shipped together with W10oA. While they are labeled as x86 system DLLs, that refers only to calling conventions, which specifies the binary format of data passed to and from the DLL. Passing that data occurs according to x86 calling conventions, but it is interpreted by ARM code. Everything in between being called and returning is also pure ARM code, so no emulation is required. We had already assumed this approach way back on page two, where I speculated that MS can likely run all OS code (like these system DLLs) natively.

The interesting part is the orange block labeled "x86 app (eg. Photoshop)". That is most definitely not a CHPE binary. As far as I recall they didn't mention anything about how that is converted to ARM code. Just looking at the diagram doesn't suggest to me that it is being translated to ARM ahead of time. In fact, the term "CPU Emulator" being used suggests the exact opposite. If x86 code was being translated ahead of time, there would be absolutely no point to having a x86 CPU emulator, as there would never actually be any x86 code for a CPU to run. All of it would already have been translated to ARM ahead of time before being executed.

It's exactly this type of thing that leads me to believe MS is translating x86 to ARM on-the-fly at runtime, rather than ahead of time, which would make it entirely incomparable to the approach used by FX!32.

In closing, if I'm wrong about all this, and MS really are doing translation ahead of time, they yes, MS can get by with a pure software solution. However if I'm right, and MS really are doing on-the-fly translation at runtime, then no, some form of hardware support will be required.