09-25-2017 07:54 PM
263 ... 891011
tools
  1. Grant Taylor3's Avatar
    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.
    Last edited by Grant Taylor3; 06-11-2017 at 06:33 AM.
    06-11-2017 06:22 AM
  2. a5cent's Avatar
    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.
    Last edited by a5cent; 06-14-2017 at 02:39 PM.
    Rosebank likes this.
    06-11-2017 06:37 AM
  3. a5cent's Avatar
    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.
    Tien-Lin Chang likes this.
    06-11-2017 06:41 AM
  4. Rosebank's Avatar
    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".
    a5cent likes this.
    06-11-2017 06:42 AM
  5. Grant Taylor3's Avatar
    *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.
    06-11-2017 06:47 AM
  6. a5cent's Avatar
    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 likes this.
    06-11-2017 06:48 AM
  7. Rosebank's Avatar
    Exactly. If you can dig up anything on that anywhere then please let us know! ;-)
    06-11-2017 06:51 AM
  8. Grant Taylor3's Avatar
    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.
    Drael646464 likes this.
    06-11-2017 06:52 AM
  9. a5cent's Avatar
    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.
    Rosebank and Tien-Lin Chang like this.
    06-11-2017 07:11 AM
  10. Drael646464's Avatar
    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.
    Rosebank and a5cent like this.
    06-11-2017 07:13 AM
  11. a5cent's Avatar
    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 likes this.
    06-11-2017 07:21 AM
  12. Rosebank's Avatar
    Nice bit of info @Drael646464, very interesting.
    06-11-2017 07:21 AM
  13. Drael646464's Avatar
    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/0...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.

    0400024001647105.png
    06-11-2017 07:33 AM
  14. Drael646464's Avatar
    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?
    06-11-2017 07:39 AM
  15. a5cent's Avatar
    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.
    Last edited by a5cent; 06-11-2017 at 08:22 AM.
    06-11-2017 08:10 AM
  16. Rosebank's Avatar

    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 completely different from the approach used by FX!32.
    MS have quite clearly stated that this is exactly how they deal with this, its clearly mentioned in the last video link. No guess work required.
    a5cent likes this.
    06-11-2017 08:19 AM
  17. Rosebank's Avatar
    w1.jpg

    The translated code is then cached into memory or Disk for subsequent use.
    06-11-2017 08:26 AM
  18. a5cent's Avatar
    MS have quite clearly stated that this is exactly how they deal with this, its clearly mentioned in the last video link. No guess work required.
    Well that settles it then. I haven't checked the video yet, but I'll take your word for it. It already seemed like the far more likely approach based on the existing documentation.
    Rosebank likes this.
    06-11-2017 08:28 AM
  19. Drael646464's Avatar
    MS have quite clearly stated that this is exactly how they deal with this, its clearly mentioned in the last video link. No guess work required.
    Which - ahead of time, or on the fly?
    06-11-2017 08:32 AM
  20. Rosebank's Avatar
    Which - ahead of time, or on the fly?
    Watch the link, its been on this Thread for months, but I just posted it again today. On the previous page.
    https://channel9.msdn.com/events/Build/2017/P4171
    Goto 7 mins 45 seconds.
    Drael646464 likes this.
    06-11-2017 08:33 AM
  21. Drael646464's Avatar
    Watch the link, its been on this Thread for months, but I just posted it again today. On the previous page.
    https://channel9.msdn.com/events/Build/2017/P4171
    Goto 7 mins 45 seconds.
    Okay, that was very clear. They convert chunks of code, and cache them in memory and on disk for later use, plus they run the system DLLs in native arm.

    So the software itself is run real-time, with caching, and all the OS calling is run native (helped along by the fact that conversion from 32 to 64bit is light work via WoW).

    So the performance, as they say, is going to depend on the app, and what use it makes of the same code repeatedly, or OS dlls.

    I wonder how much disk caching is involved, and how much ram caching? Presumably this will be a factor in running some apps.
    Rosebank likes this.
    06-11-2017 08:45 AM
  22. a5cent's Avatar
    Okay, that was very clear. They convert chunks of code, and cache them in memory and on disk for later use, plus they run the system DLLs in native arm.
    Could it be that MS' claim of it running near native speeds applies only after everything has been translated and written to disk for subsequent use?

    If that's the case, then it would be somewhat of a hybrid solution. Slow execution once but near native speeds with a FX!32 like approach afterwards?
    nate0 likes this.
    06-11-2017 08:56 AM
  23. Rosebank's Avatar
    Could it be that MS' claim of it running near native speeds applies only after everything has been translated and written to disk for subsequent use?
    I have been thinking about that, the program might be slow to begin with but once all the translation has taken place then its stored for subsequent use and faster preforming, what I wonder is if you have x2 x86 programs running can the translated code be shared if there are duplicate code conversations or would the two x86 running programs be treated totally separate? I would be interested to know if there is any cross over (sharing) between 2 or more running x86 programs under Emulation.
    06-11-2017 09:09 AM
  24. nate0's Avatar
    There is NO water or any other type of liquid cooling on the 950 or 950xl.
    The 950 xl has a heat pipe wick cooling system. I am unaware if any or if so what kind of substance/material was inside.

    The 950 might have a pipe too.

    The mention of it when announced has been of controversy so the thought behind it was that it was a wicking/condensing cooling system. Physical liquid/water inside well no. At least not to the naked eye.
    06-11-2017 09:21 AM
  25. a5cent's Avatar
    I wonder is if you have x2 x86 programs running can the translated code be shared if there are duplicate code conversations or would the two x86 running programs be treated totally separate?
    That I can already answer. If the executable binary itself is shared, as is sometime the case with a DLL, then the translation would likely also be shared (at least it should be). Otherwise the binary translation is totally separate. There is virtually zero overlap in in two unrelated binaries, so just trying to find overlap would be rather fruitless and a waste of CPU cycles that would be better invested elsewhere.
    Rosebank likes this.
    06-11-2017 12:23 PM
263 ... 891011

Similar Threads

  1. Win 8.1 enterpise to W10
    By costas60 in forum Windows 10
    Replies: 1
    Last Post: 11-15-2016, 11:49 AM
  2. Replies: 2
    Last Post: 11-15-2016, 11:25 AM
  3. No, Microsoft isn't working on Xbox game streaming to Windows 10 Mobile, but it should!
    By WindowsCentral.com in forum Windows Central News Discussion
    Replies: 0
    Last Post: 11-15-2016, 09:42 AM
  4. how to download in my lumia 1020 this w10 build 10586
    By Windows Central Question in forum Ask a Question
    Replies: 1
    Last Post: 11-15-2016, 03:45 AM
LINK TO POST COPIED TO CLIPBOARD