W10 Mobile x86 .exe Emulator

Rosebank

New member
Oct 6, 2016
445
0
0
Visit site
Surely with the power capability of an 8 core phone with 3bg ram a x86 exe file Emulator would be a success and allow us to run limited .exe files on your phones, thus bridging the app gap, I am seriously surprised this cant be done.
A program could be made to run .exe files via the Emulator, Converting x86 for use with ARM processors.
Can anyone shed any light on why this cant be done,
Even with a limitation of running only 1 .exe file per session keeping the heat of the device down again this would allow us to run basic .exe files.
I would even put up with a slow running .exe program because once established this feature would only get better with development.
Food for thought.
1 simple Emulator could revolutionise the Windows 10 mobile platform .
 

xandros9

Active member
Nov 12, 2012
16,107
0
36
Visit site
Phones are powerful but not that powerful. Also it wouldn't bridge the app gap since what I need on a phone are different than what I need on my computer.

Also x86 programs would only be helpful when I have a display and keyboard to hook the phone up to, which isnt really available on the go, at least to me.
 

Rosebank

New member
Oct 6, 2016
445
0
0
Visit site
x86 with Continuum would be nice, I know its not going to happen but I still think the hardware could handle 1 .exe file running, if an old Pentium 4 can do it then I am sure an 8 core chip with 3gb RAM could handle it. (with emulator)
For me this would bridge the app gap, I use a chess site called playchess.com, there is an app available for this via android and IOS but NOT windows phone, however on the PC you can install a .exe file giving you the full program and not a cut down app version. The install of the file is small and the program is very light on resources.
https://account.chessbase.com/en/apps/playchess
 

EspHack

New member
Jun 11, 2013
1,279
0
0
Visit site
asking an ARM cpu to run an x86 code is like asking an x86 cpu to run 3d games like an nvidia/amd gpu, at a certain point you could do it but its just so inefficient its not worth it, hence why cpu's come with at least a barebones integrated gpu

you could bet HP at least thought about that option, if they opted for streaming apps from a dedicated server instead of "just emulating" you get an idea of how bad it would be, they even ship the dock with a laptop charger, so it could run at highly overclocked speeds while having some fancy dock-to-phone cooling tech, but not even that was enough it seems
 

daimv

New member
May 21, 2015
382
0
0
Visit site
Not ready yet. I believe in a few years it will be possible but transistors aren't small enough for x86 phones, emulated or not.
 

a5cent

New member
Nov 3, 2011
6,622
0
0
Visit site
Surely with the power capability of an 8 core phone with 3bg ram a x86 exe file Emulator would be a success and allow us to run limited .exe files on your phones, thus bridging the app gap, I am seriously surprised this cant be done.
A program could be made to run .exe files via the Emulator, Converting x86 for use with ARM processors.
I know its not going to happen but I still think the hardware could handle 1 .exe file running

Three things:

  • The number of cores isn't directly related to performance. It is in no way a reliable indicator of what to expect from a CPU. Just as a reminder, the iPhone has used a dual core CPU for years and it is the best performing device (at its size) around. The number of cores is only useful for comparisons if the CPUs you are comparing are built with identical cores. More importantly even, the software you intend to run must be able to take advantage of the additional cores on the CPU that has more of them. Particularly software for mobile devices often can't do that. Finally, a single core in a modern Intel CPU is much more powerful than a single core in an mobile ARM CPU. Expecting an ARM CPU to run x86 software as well as a x86 CPU just because they have the same amount of cores is ridiculous.
  • Virtualization is a very expensive technology in terms of the incurred performance hit. Both ARM and x86 chips have circuitry dedicated directly to reducing that hit, but it's still very noticeable. This is particularly true if the instruction sets differ, as they do between ARM and x86. Most people using virtualization solutions don't even notice that issue, because they are virtualizing only hardware access (e.g. if you run Windows via Bootcamp on OSX, all of which is x86 based software, just different OSes), rather than the hardware itself (which is what would be necessary to virtualize an x86 CPU on an ARM device). Those are two very different things. This is the main reason your proposal would be a usability nightmare.
  • How well this performs has absolutely zero to do with how many processes are running (an executable file typically launches one process, but some launch more than one). Far more important than how many processes are launched, is what they do, i.e. how much load a process generates for the CPU. Something like an x86 Notepad might barely be usable, but something like Word would surely kill it. All of this assumes MS can pull this off without having to virtualize an x86 based version of Windows itself on ARM, which might not be possible. If not, that likely already kills the idea.

In a nutshell, there are only downsides to virtualization of this type. Just use the smallest possible Core M CPU. Anyone designing and using such a device will be a million times better off.
 
Last edited:

a5cent

New member
Nov 3, 2011
6,622
0
0
Visit site
Not ready yet. I believe in a few years it will be possible but transistors aren't small enough for x86 phones, emulated or not.
This has absolutely nothing to do with the process node used to manufacture integrated circuits. Companies are already building phone sized x86 devices and that works just fine.

This is about the problems caused by trying to run x86 software on ARM devices. That will always suck no matter how advanced the process node used to manufacture the integrated circuitry is. Why? Because no matter how advanced that is, using a CPU that can directly run x86 software will always be much much faster and use less power than an ARM chip trying to act as if it was an x86 chip.
 
Last edited:

Rosebank

New member
Oct 6, 2016
445
0
0
Visit site
R3... not long to wait and see. The writers might not be educated but they have reliable sources, the fact that this report pops up gives me hope and that my idea was not such a ridiculous one. You seriously underestimate the CPU capabilities, before I begun this thread I spent several days studying the CPU comparisons etc. Perhaps you should have a look too.

Expecting an ARM CPU to run x86 software as well as a x86 CPU just because they have the same amount of cores is ridiculous.
But it seems they are exploring the issue...nobody said it would run aswell or as good as... they are your words and I agree but small steps are required, in time things can only get better, that is what I stated. Development being the key issue.
Also here is the original report and the Author. http://www.zdnet.com/article/micros...-windows-10-redstone-3-fall-2017-deliverable/
the Author-- Mary Jo Foley has covered the tech industry for 30 years for a variety of publications, including ZDNet, eWeek and Baseline. She is the author of Microsoft 2.0: How Microsoft plans to stay relevant in the post-Gates era (John Wiley & Sons, 2008). She also is the cohost of the "Windows Weekly" podcast on the TWiT network
Technically educated it would seem.
 
Last edited by a moderator:

BackToTheFuture

New member
Aug 9, 2013
44
0
0
Visit site
Let me chip in a bit.

By saying that the authors are not "technically educated", @a5cent means they haven't taken ComSci/Eng courses seriously, and they do not really understand what's happening under the hood. They look at things from a user's point of view.

x86 CPUs are designed with CISC (complex instruction set) while ARMs are RISC (reduced instruction set). It's some how possible to emulate ARM because of their simple architecture (Intel did online translation from ARM to x86 on Atom-based Android tablet/phone) (I don't think they can even reproduce every ARM instruction completely in software yet), but it's impossible to create a fully featured x86 emulator, much less running x86 emulator on ARM. Btw, emulator is different from virtual machine. The emulator must reproduce the actual hardware in software, whereas a virtual machine just pipe the code to the hardware.

I think a possible solution in the future is to create an x86 co-processor for ARM, so that a limited set of x86 functionality can be used on an ARM device. This co-processor will only kick in on demand. But this begs the question, while we don't just use Atom for this and avoid all the hassles. Asus used Atom in their Zenphone/tablet before.
 

a5cent

New member
Nov 3, 2011
6,622
0
0
Visit site
Hey Rosebank, I'm going to be blunt here. It will probably appear rude, but I don't mean to offend. I'm just not going to dance around any issues.

But it seems they are exploring the issue...nobody said it would run as well or as good as... they are your words
Nope, those are definitely not my words. Nowhere did I say it won't run as good. That it won't run "as good", whatever that means, is probably obvious to all of us. What I did say is that it simply won't result in an acceptable user experience, at least not using currently available hardware, and not for anything that generates more load than something like Notepad.

I think I understand your question better now. Apparently your question was more theoretical in nature. You were really only interested in whether x86 virtualization was theoretically at all possible. If I'm right about that, then sure, we agree. That is possible. But here is the thing:

Pretty much anything a computing device could theoretically be expected to do can be done! Period.

From a strictly theoretical perspective, the excuses MS occasionally lets slip, like "the Surface RT can't be upgraded to W10", or "it was technically impossible to run WP8 on a WP7 device" are all BS. The later was even proven to be BS a few years later when a guy got WP8 to run on WP7 hardware. For any such computing related "is it technically and theoretically possible?" question, the answer is almost always: "yes, it is technically and theoretically possible". Connect a large HDD to a Commodore 64 from 1982 and you could even develop a Windows x86 emulator for that. That too is technically possible! It will be slow as hell and look like crap, but it is technically possible.

In summary, a question that can always be answered with "yes" just isn't a very interesting question.

Also here is the original report and the Author. Microsoft's x86 on ARM64 emulation: A Windows 10 'Redstone 3' Fall 2017 feature | ZDNet the Author-- Mary Jo Foley has covered the tech industry for 30 years for a variety of publications, including ZDNet, eWeek and Baseline. She is the author of Microsoft 2.0: How Microsoft plans to stay relevant in the post-Gates era (John Wiley & Sons, 2008). She also is the cohost of the "Windows Weekly" podcast on the TWiT network Technically educated it would seem.

IMHO the only way you can assume Marry Jo Foley is technically educated, is by not being technically educated yourself. Whenever things get even slightly technical, she resorts to verbatim quotes. Because she lacks the background to really understand what she is quoting, she also isn't equipped to ask technical follow up questions. Don't get me wrong. I have no problems with her. She has good sources and she reports the information she gets carefully and well. If you want to know about release schedules, licensing changes and strategic stuff like reorganizations or product retirements, she's great. None of that is technical however.

The most technical statement she makes in the article you linked to is this:

What if an ARM64-based device could run x86 apps via emulation, the same way that the WOW (Windows on Windows) emulator allowed 32-bit apps to run on 64-bit Windows?

I suspect she barely understands what that sentence means. I doubt any of the writers on this site do either. Frankly, I can't be sure either, because it's not enough information, but if forced to guess, I'd say that sounds very much like MS can solve the issue I mentioned in my first post. It likely means that MS can run x86 apps on an ARM CPU without having to emulate x86 hardware for the hosting OS. That is certainly a promising step!

Why is that important? Consider an app that does nothing but make calls into the OS (there is no such app, but it's a helpful way to think about it). Such an app could run practically at native ARM speeds. Why? Because almost all the code being executed on the app's behalf would be part of the OS which isn't emulated. For everything an app does on its own without calling into the OS however, we'll see a performance hit. If you can't imagine what it means to translate x86 instructions into ARMv8 instructions in software, then you also can't imagine the performance hit that would incur. I couldn't give you exact numbers either, but we're certainly talking about it being multitudes slower compared to the same app running on a similarly spec'ed x86 core.

For something like Notepad, that does almost nothing but read and write characters to a memory buffer, this could actually work quite well. For anything more serious than that... forget it. Like I said, at least not without additional hardware support.

And again, at this point we haven't even addressed the OS, which Marry Jo Foley would have if she had a technical background. If MS really intends to run Win32 desktop software in continuum mode on a phone, then we'd have to use W10 rather than W10M. Based on what I've read so far, it sounds like this is really targeting W10M however. I'm not sure what the point of that would be, because it wouldn't allow us to run any of the desktop software you and others are looking forward to running on your phones. If MS is actually talking about installing full W10 on a phone sized device, then it makes a lot more sense, but that isn't what people seem to be reporting.

You seriously underestimate the CPU capabilities, before I begun this thread I spent several days studying the CPU comparisons etc. Perhaps you should have a look too.

Nope. I don't. You just underestimate the performance impact this will have (using currently available technology). I'm aware that the fastest mobile ARM CPUs are somewhat comparable to the slowest Intel Core M CPUs. An Intel Core M CPU is perfectly fine for most use cases. However, you won't get anything close to Intel Core M performance from this type of emulation-based solution! I suspect you're only considering hardware specs and completely ignoring the software side of this equation, in which case you're guaranteed to be totally off.

We agree that it's an interesting step though. Until instruction set translation is moved from software to hardware however, it just won't convince anybody who is looking for more than the novelty effect. Of course, if that sort of hardware supported translation already exists and I'm just not aware of it, then I'll eat my words. I just haven't been able to find anything that would suggest it does.
 
Last edited:

a5cent

New member
Nov 3, 2011
6,622
0
0
Visit site
but it's impossible to create a fully featured x86 emulator, much less running x86 emulator on ARM.

Thanks for chipping in BackToTheFuture. I agree with everything you said except this one sentence. I think it is possible to create a fully featured x86 emulator on ARM. You'd just be translating a single CISC instruction to multiple RISC instructions in a way that is always safe and always guaranteed to work (register values possibly stored in RAM rather than in actual CPU registers, nothing close to what an optimizing compiler would generate, etc).
 
Last edited:

BackToTheFuture

New member
Aug 9, 2013
44
0
0
Visit site
Thanks for chipping in BackToTheFuture. I agree with everything you said except this one sentence. I think it is possible to create a fully featured x86 emulator on ARM. You'd just be translating a single CISC instruction to multiple RISC instructions in a way that is always safe and always guaranteed to work (register values possibly stored in RAM rather than in actual CPU registers, nothing close to what an optimizing compiler would generate, etc).

Agree with you, but I meant it in practical terms, it's not possible. Theoretically, anything can be done in software. The CPU as we know of is just realization of software in electronic form. But running software emulation incurs massive performance hit. That's why we now have hardware for rendering (anyone remembers those days in 90s when we had software-based DirectX & OpenGL?), crypto, video decoding etc, while all of these tasks can be done with a general purpose CPU, at a cost.

Regarding x86 emulation, primitive instructions have been emulated in software for a long time - for example testbed for those microprocessors used in embedded systems. But the problem lies in advanced instructions (such as SSE3/4, AVX) that a lot of software nowadays rely upon. What's the point to emulate them, when they were originally designed to accelerate processing?

But hey who knows. Someone might wield their magic wand and make it possible. That would be a true engineering marvel.
 

a5cent

New member
Nov 3, 2011
6,622
0
0
Visit site
^ Yeah, just wanted to be sure. I got off to a bad start in this thread because I allowed the practical vs theoretical debate to confuse me. Just didn't want a repeat ;-)
 

Rosebank

New member
Oct 6, 2016
445
0
0
Visit site
So glad the report surfaced because quite simply it was an idea I had and wondered if it would be possible. YES THEORETICAL.
Up pops a report 1 week later on the very issue, Now come on, the reporter did not make up the report, She was reporting on information she had come into the possession of.
1 point I would like to make, you did say this :- "Expecting an ARM CPU to run x86 software as well as a x86 CPU just because they have the same amount of cores is ridiculous"
That means it wont run as good as. I quoted your words in my reply further up the page, as well as or as good as means the very same thing, then I agreed with you but now I have an idea that a team MIGHT be working on this very issue.
As for my Technical ability or your questioning of it is not for debate, My theoretical forum post seems to have some common ground with the recent report and that's good enough for me.
Thanks for all the technical information.
.

. Don't get me wrong. I have no problems with her. She has good sources and she reports the information she gets carefully and well. If you want to know about release schedules, licensing changes and strategic stuff like reorganizations or product retirements, she's great. None of that is technical however.
Seems a bit of a problem here, somewhat of a contradiction, she is good at reporting things non Technical is your opinion and not based on fact, (you might be right) your implying she is simple or lacks ability but your happy to accept "some" of her reporting, Reporting on a x86 Emulator.. which category does that fall into using your Logic? Are her sources still good if reporting on a x86 emulator? why are companies giving her a Job reporting on Technology and x86 Emulators? Would she be able to report on technical issues given the technical facts, I suspect she would be more than capable and understand them if detailed correctly.
Foley graduated from Simmons College in 1983 with a degree in technical journalism.[
Suggesting some form of technical ability/Intellect/interest - combined with 30 years experience why else would she be reporting on Computer and operating systems, that are technical by nature,
You cant expect the author of the report to be any more Technical than the information SHE HAS BEEN GIVEN?
So lets assume she reported everything she knew, she is not paid to add her technical opinion, as for her Podcasts I have not seen them but I will endeavour to do so later. Little bit strange having a non technical person doing Microsoft windows weekly podcasts...?
 
Last edited by a moderator:

a5cent

New member
Nov 3, 2011
6,622
0
0
Visit site
1 point I would like to make, you did say this :- "Expecting an ARM CPU to run x86 software as well as a x86 CPU just because they have the same amount of cores is ridiculous"

That means it wont run as good as.

Again. No. What that actually means is that it's not reasonable to expect two CPUs to perform similarly just because the spec sheet states that both have the same number of cores. The larger point was that the number of cores is a useless performance metric for comparative judgments of entirely unrelated CPU architectures (which x86 and ARM devices are). It means no more and no less. I mentioned that only because you falsely concluded that x86 emulation on ARM would "surely be a success" based on the fact that some ARM CPUs had 8 cores (among other things).

Either you have difficulties precisely parsing text or you're not reading carefully enough. The same applies to passages like this:

Now come on, the reporter did not make up the report
Seems a bit of a problem here, somewhat of a contradiction, she is good at reporting things non Technical is your opinion and not based on fact, (you might be right) your implying she is simple or lacks ability but your happy to accept "some" of her reporting

None of that has anything to do with what I actually said. If you don't intend to put words in my mouth, I'd suggest you use the exact wording from the original post you're quoting (that's what the quote function is for). Paraphrasing isn't serving you well.

I'm going to ignore most of that and let you go back and figure out for yourself what I actually said.

However, let it be clear that I'm not attacking MJF in any way. Also let it be clear that she doesn't have to be a technical genius to be factual. Like BackToTheFuture already said, she reports on the tech industry from a user's perspective. There is nothing wrong with that. Her reporting just isn't technical. She'd lose 99% of her readership if she started reporting on the technical stuff that software and hardware engineers need to know about.

I'll leave it at that.
 
Last edited:

Grodelj

New member
Apr 2, 2013
319
0
0
Visit site
What if...the "surface phone" will have some sort of hybrid cpu? If it would be technically possible, one with let's say 4 ARM cores and two x86 cores? Or maybe two CPUs, one ARM and other x86 and when the device is powered by battery it runs on ARM and when in continuum mode, it runs on x86. I have no idea if something like this is or will be possible, but just a thought:)
 

Rosebank

New member
Oct 6, 2016
445
0
0
Visit site
Thanks, I have said my part and have nothing further to add at this stage, I do hope we can look forward to developments on this on this issue whether they be from a technical or non technical source.
 

a5cent

New member
Nov 3, 2011
6,622
0
0
Visit site
What if...the "surface phone" will have some sort of hybrid cpu? If it would be technically possible, one with let's say 4 ARM cores and two x86 cores? Or maybe two CPUs, one ARM and other x86 and when the device is powered by battery it runs on ARM and when in continuum mode, it runs on x86. I have no idea if something like this is or will be possible, but just a thought:)

Yes, that is possible. You just need enough engineers, time and money. However, Intel is probably the only company that could economically build something like that. Everyone else would have to license the x86 instruction set from Intel, and I doubt Intel would be willing to oblige at a price that isn't prohibitive. I'd have no problem believing Intel is working on something like that, but the thing is, so far the reporting suggests that it will be the Snapdragon 830 or 835 that supports this, and those are built by Qualcomm, not Intel.

Wait and see I guess. Like Rosebank said, it's not too far off.
 

Members online

Forum statistics

Threads
323,136
Messages
2,243,316
Members
428,029
Latest member
killshot4077