The Windows 10 April 2018 update has arrived! Get the new Dell XPS 15, starting at $999.99
12-21-2016 08:27 AM
53 123
tools
  1. Kogling's Avatar
    Kids Corner and FM Radio was also removed from Windows 10 Mobile Anniversary update. etc..
    Its just 'Apps corner' now isn't it? Broken but still there.
    12-15-2016 01:13 PM
  2. PerfectReign's Avatar
    12-15-2016 01:24 PM
  3. libra89's Avatar
    Its just 'Apps corner' now isn't it? Broken but still there.
    Nope. Kids Corner was a separate thing.
    12-15-2016 01:29 PM
  4. Chemy JMHT's Avatar
    At this point it is a wait and see thing. It is probably capable. I was watching the Full demo by Terry Myerson last night, and afterwards one of the VPs from Qualcomm came out carrying the X3 in hand. Later noted that the demo Myerson gave was on the same chipset as the HP unmodified. Not sure what that means for the X3, and that is all we really have. There are others around the forum that have more insight on this though. So, it is up to you.
    That's good info, I read about the new ability from MS to run Windows on ARM, so maybe the next update will be a desktop-like version for the X3
    12-15-2016 06:09 PM
  5. a5cent's Avatar
    ^ How often has MS allowed a device with one OS (W10M which has no licensing fee) to update to a totally different edition/SKU of the OS (W10 which has a licensing fee, is far less secure than W10M, requires a lot of maintenance, and will have a different UI when being used as a phone)? The answer is never. I'd also not be surprised if many using the x3 would consider such radical changes (e.g. suddenly having to run registry cleaners and windows defender on what they initially considered to be a locked down and maintenance free phone) unacceptable.

    Furthermore, I doubt anyone running emulated x86 software on an X3 would find the experience satisfying. However, even if it worked perfectly, I think the chances of MS and HP doing such an upgrade are, for the reasons mentioned, pretty much zero.
    Last edited by a5cent; 12-16-2016 at 03:43 AM. Reason: formatting
    libra89 likes this.
    12-15-2016 06:29 PM
  6. badMojo69's Avatar
    It will. It's what they used in the demo.
    11:50
    12-16-2016 05:39 AM
  7. a5cent's Avatar
    ^ You mean like how they demonstrated early versions of W10M on the L1520 and then all L1520's were update to W10M... oh yeah... right... never happened. And that would have been a straight update from WP8.1 to W10M... no cross update to a completely different OS SKU/edition.

    More importantly, the presenter was very clear when he said the presentation was made using the same CHIPSET as is used in the x3. The x3 was not what they used for this demonstration. That almost begs the question why not. I'll let you try and guess.

    Believe what you want. Just don't say you weren't warned.

    There is way too much hype surrounding this issue. Not enough critical thinking.
    Last edited by a5cent; 12-16-2016 at 07:26 AM.
    12-16-2016 05:46 AM
  8. Kogling's Avatar
    The x3 was not what they used for this demonstration. That almost begs the question why not. I'll let you try and guess.
    presumably because they were working on x86 under ARM before the HP elite was announced, plus the ability of having to update or change things without having to request development boards from HP etc?

    They are most likely using a development board which is designed for such purposes rather than a production phone.

    That really isn't unexpected to be honest. I would not want to try throw together a test build on a 3rd party phone for a presentation, where the 3rd party is typically responsible for making drivers (because they designed the hardware) when they have their well designed development board to be used instead.

    the only purpose of mentioning that it uses the same chipset as the x3 would be to suggest that the x3 is more than capable.
    12-16-2016 11:04 AM
  9. a5cent's Avatar
    the only purpose of mentioning that it uses the same chipset as the x3 would be to suggest that the x3 is more than capable.
    The "only purpose"? You do realize that Terry Meyerson wasn't talking to consumers in that video, right? He was talking to hardware developers attending WinHEC. Nobody in that room gives a rats behind about whether or not W10 runs on HP's Elite X3. The X3 already exists. Those people care about developing new hardware. Given the context, you don't think there's even the slightest possibility that the purpose of his statement may only have been to say that emulating x86 on ARM is possible NOW, rather than a year down the road?

    Anyway, although MS has occasionally referred to the SD820 as a chip that can theoretically run full Windows, all the reporting suggests that production level devices with emulation capabilities will ship with the SD835. I'm more inclined to believe that will end up being the minimal hardware requirement.

    Like I said, believe what you will. Ultimately, we're all just guessing. Just don't ever say MS "promised" that x86 emulation will be coming to all devices with an SD820 like the X3.
    libra89 likes this.
    12-16-2016 02:02 PM
  10. Ivan05il's Avatar
    What they showed was a proof of concept, that it is possible. I do not expect them to use it in phones. Despite everything, what's the point of being able to use it on the phone. It makes a lot of sense on tablets and laptops, though. The whole Continuum thing is a bit gimmicky to me, too. Nowadays laptops are not that heavy or take much space that you'd save much not using one.
    a5cent likes this.
    12-17-2016 01:24 AM
  11. a5cent's Avatar
    ^ yeah, also possible.
    12-17-2016 06:38 AM
  12. Kogling's Avatar
    You do realize that Terry Meyerson wasn't talking to consumers in that video, right? He was talking to hardware developers attending WinHEC. Nobody in that room gives a rats behind about whether or not W10 runs on HP's Elite X3.
    Firstly, the context of my previous post was in relation to the x3 not being used as the demo device with the suggestion of that being an inability of the x3 to support (or have enabled) this feature (at least how i interpreted it) when IMO it's almost impossible for them to prepare a 3rd party device around their independent developments,. Your response is largely out of the context of that as it's going on about that event rather than the x3.

    However, in response to you:

    Those people care about developing new hardware. Given the context, you don't think there's even the slightest possibility that the purpose of his statement may only have been to say that emulating x86 on ARM is possible NOW, rather than a year down the road?
    If they only care about creating new hardware, then why are they even mentioning a software based feature that requires no changes to how hardware is made?

    They have a device made with a disregard to the feature, is available now and can support it?

    But why do they need to know this? Being available now, next week, month, year? What do they have to plan for, if the feature needs no hardware based consideration? What use is being told that it's "available now" but, in actual fact, that x million $$ you've just invested in a new device now has to have more money thrown at it to support it?

    Yeah, that's not really the purpose of that statement. They don't need to use the x3 to say that it's available now on the basis of software only, they could have said it would work on the Edge running the 820 to turn more heads.

    It's all about backward compatibility. Completely irrelevant to "new" hardware and very fundamental to practically every IT field and is more important to non-hardware people.

    The point probably wasn't meant as "available now", because "available now" is only "now" when the release that feature, but "available x months ago", backwards compatible - on hardware already being replaced and available to their devices whenever windows makes it available. That's far more important than now. Fancy having windows release windows 11 for argument sake and telling everyone "but you have to get rid of all your old hardware and buy this new one".

    That's far more important, and not to hardware devs but everyone in an IT field, - software devs, managers, companies investing in new hardware, systems. Windows is bigger than mobile phones after all.

    Like I said, believe what you will. Ultimately, we're all just guessing. Just don't ever say MS "promised" that x86 emulation will be coming to all devices with an SD820 like the X3.
    I don't, but for the sake of why the x3 wasn't used as the demo device despite being hinted as capable, I would neither dismiss as indicating it wont be added to the x3 for my previously expressed reasons.

    I think the statement is rather strong indicator that it will personally, because it seems pretty pointless to dangle a carrot like that if they know full well they won't allow it /feature it. They know consumers /read/watch these presentations too and, suggesting the 820 can support it with developers potentially looking at using the 820 wont be very happy when they find out well actually, they can only use the 835? or even worse, specifically black list the x3.. yeah just sounds all kinda pointless and bull statement to me if it doesn't get put on the x3.
    Last edited by Kogling; 12-17-2016 at 06:26 PM.
    12-17-2016 06:08 PM
  13. Ivan05il's Avatar
    MS was concentrating on Intel for a long time, their ARM solutions did not do well. What this says, that with this one can build very attractive Windows tablets and lightweight laptops with ARM processors, because they combine the best things of the two worlds.
    12-18-2016 01:58 AM
  14. Michael Alan Goff's Avatar
    Originally posted by a5cent
    ^ How often has MS allowed a device with one OS (W10M which has no licensing fee) to update to a totally different edition/SKU of the OS (W10 which has a licensing fee, is far less secure than W10M, requires a lot of maintenance, and will have a different UI when being used as a phone)? The answer is never. I'd also not be surprised if many using the x3 would consider such radical changes (e.g. suddenly having to run registry cleaners and windows defender on what they initially considered to be a locked down and maintenance free phone) unacceptable.

    Furthermore, I doubt anyone running emulated x86 software on an X3 would find the experience satisfying. However, even if it worked perfectly, I think the chances of MS and HP doing such an upgrade are, for the reasons mentioned, pretty much zero.
    If you have to constantly run a registry cleaner and anti malware on Windows 10, you're doing something wrong.
    12-18-2016 02:22 AM
  15. a5cent's Avatar
    If you have to constantly run a registry cleaner and anti malware on Windows 10, you're doing something wrong.
    Absolutely. But how many people are constantly doing things wrong on Windows? Too many. There are reasons why Windows' reputation isn't exactly stellar.

    Many companies prefer a more robust and locked down OS (like W10M) for exactly that reason. If they can get by without a real computer, that can dramatically reduce support costs. Updating W10M on the X3 to W10 would forfeit that advantage. I've never seen MS do that before. That's all I'm saying.
    EuroKnuter and libra89 like this.
    12-18-2016 01:24 PM
  16. a5cent's Avatar
    However, in response to you:

    If they only care about creating new hardware, then why are they even mentioning a software based feature that requires no changes to how hardware is made?
    Your entire argument is based on the assumption that this feature is realized purely via software and that hardware is irrelevant. That is simply not true. Just the fact that OEMs can't use any old ARM chip already makes that clear. It must be a SoC from Qualcomm's Snapdragon series, and very specific model numbers at that. It will be the SD835 and maybe also the SD820 (IMHO unlikely), but no more. That makes it very clear that this feature depends on explicit hardware support. In that light it makes perfect sense to say: "that hardware is available now".

    Those who have been here a while are fully aware that anything MS says must be parsed very carefully. You simply can't make assumptions about anything that isn't stated explicitly. All the reporting suggests WOA will be limited to the SD835. Until someone from HP explicitly states WOA is coming to the X3, it's safer to assume it won't.

    Look, I don't really want to argue over whether or not WOA will be supported on the X3. You can believe what you want, I'll believe what I want, but nobody should expect WOA to be supported on the X3. If it eventually is, then that's great, but buying an X3 with that expectation could very well turn out to be a colossal waste of money.

    That's all I really want to get across.
    libra89 likes this.
    12-18-2016 01:48 PM
  17. Kogling's Avatar
    Your entire argument is based on the assumption that this feature is realized purely via software and that hardware is irrelevant. That is simply not true. Just the fact that OEMs can't use any old ARM chip already makes that clear.
    Yet this assumes old ARM chips can't be used due to hardware limitations rather than a practicality of performance?

    64bit is probably a big player among other things, and ARM is a entirely different thing to the classic PC CISC computers we use - they have several branches different to each other with manufacturer adaptations - one ARM to another is apple to oranges to some degree.

    No point in going in to massive debate on it, though I wouldn't expect there being a specifically implemented hardware function for the sake of x86 applications. Probably something daft like exploiting windows being 32bits on ARM and using the other half for x86 emulation layer.

    Those who have been here a while are fully aware that anything MS says must be parsed very carefully. You simply can't make assumptions about anything that isn't stated explicitly.
    I'm very aware of this as I have said - not sure if in this thread, the history with their RT tablets and false promises and complete abandonment I am far to aware as a surface 2 RT and Nokia 2520 owner.

    Look, I don't really want to argue over whether or not WOA will be supported on the X3. You can believe what you want, I'll believe what I want, but nobody should expect WOA to be supported on the X3. If it eventually is, then that's great, but buying an X3 with that expectation could very well turn out to be a colossal waste of money.

    That's all I really want to get across.
    Not against that - I agree with you, though I am more inclined of it being introduced, assuming it actually gets released at all anywhere.

    But for the lack of an x3 being used, I will also argue that it's irrelevant to it's potential, because MS simply wouldn't of have a reliable supply of development boards from HP to prototype on the x3 when they are likely going to be using dev board from Qual'.
    12-18-2016 05:44 PM
  18. a5cent's Avatar
    Yet this assumes old ARM chips can't be used due to hardware limitations rather than a practicality of performance?

    64bit is probably a big player among other things, and ARM is a entirely different thing to the classic PC CISC computers we use - they have several branches different to each other with manufacturer adaptations - one ARM to another is apple to oranges to some degree.
    Yes. Certain hardware based facilities for emulation (as Intel chips have had for years) and particularly for ISA transcoding (or whatever you want to call it) must be in place for this to work decently. It's definitely not just a matter of raw computational power.

    With the exception of addressable RAM, 64 bit vs 32 bit is completely irrelevant to this problem. The ability for an x86 based program to make calls into an ARM based OS is achieved by using the same mechanisms MS used to enable a 32 bit program to make calls into a 64 bit OS. So while the translation mechanism is the same, it doesn't itself have anything to do with the "bitedness" of anything.

    ARM also isn't as different as you think it is. Internally, all Intel x86 chips are based on RISC designs, just like ARM. It's been that way for over a decade now. Only the x86 decoder deals with CISC instructions, which is an advantage for Intel.
    Last edited by a5cent; 12-18-2016 at 07:07 PM.
    libra89 likes this.
    12-18-2016 06:54 PM
  19. Ivan05il's Avatar
    Mentioning software possibilities to hardware makers is very important to MS, they are courting them to start making a new range of devices that they believe will be very attractive to consumers, because they combine an efficiency of ARM and full functionality of Windows. They are saying this is not that Windows RT crap nobody wanted. I think they should make it run apps from other platforms on it and they have a winner. It would run anything you threw at it.
    12-18-2016 11:19 PM
  20. Kogling's Avatar
    Yes. Certain hardware based facilities for emulation (as Intel chips have had for years) and particularly for ISA transcoding (or whatever you want to call it) must be in place for this to work decently. It's definitely not just a matter of raw computational power

    The ability for an x86 based program to make calls into an ARM based OS is achieved by using the same mechanisms MS used to enable a 32 bit program to make calls into a 64 bit OS. So while the translation mechanism is the same, it doesn't itself have anything to do with the "bitedness" of anything.
    Not sure I get you here, as I don't recall anything particularly special on a 64 bit processor to "run" x86 programs from when I was into assembly programming.

    86-64 was designed with backwards compatibility in mind, so for the most part, anything that was 32 bits wide was simply extended to 64bits. 32bit code just get truncated to 64bits from what I remember.

    AFAIK WOW64 (which is the x86 into 64 layer for windows) is all to do with the OS (i.e. OS based issues). That's because an x86 program expects 32bit references and handles, so WOW64 converts /manages that bridge by interrupting those system calls and converting a 64bit handle to 32bit etc.

    Thats how Windows chose to handle it and they called it WOW64 but it's not anything massively special and, presumably on 32bit windows or windows mobile (which is 32bit as of current), potentially not needed.

    ARM also isn't as different as you think it is. Internally, all Intel x86 chips are based on RISC designs, just like ARM. It's been that way for over a decade now. Only the x86 decoder deals with CISC instructions, which is an advantage for Intel.
    I can't say much about ARM to be honest as I have only ever skimmed over their architectures with little real interest and that was a few years back now.

    I'm also on the AMD side of processors too, so I've only read their documentation. That's partially because they designed the x64 arch. in use today too.

    However, whether "RISC" is implemented in a CISC or not is down to their architecture design and I'm unsure if it's RISC to the full definition. breaking a larger instruction set down to smaller chunks isn't necessarily anything to be too concerned about, and for a CISC, this is probably related to the VILW /superscalar architecture in order to execute multiple instructions in parallel at the same time which wouldn't be as possible with dedicated CISC instructions.

    Almost everything is broken down smaller so that parts can be shared anyway.

    So not quite sure of the "x86 decoder" you mention. It should all go through a "x86 decoder" because the op code is still an x86 instruction set, the CPU by design has chosen to break x instruction down in to smaller blocks (I think they call it a micro-Op dont they?), most likely to execute several compatible instructions at the same time.
    Last edited by Kogling; 12-20-2016 at 09:10 AM.
    12-20-2016 08:20 AM
  21. a5cent's Avatar
    AFAIK WOW64 (which is the x86 into 64 layer for windows) is all to do with the OS (i.e. OS based issues). That's because an x86 program expects 32bit references and handles, so WOW64 converts /manages that bridge by interrupting those system calls and converting a 64bit handle to 32bit etc.

    Thats how Windows chose to handle it and they called it WOW64 but it's not anything massively special...
    64bit is probably a big player among other things,...
    <snipped>
    No point in going in to massive debate on it, though I wouldn't expect there being a specifically implemented hardware function for the sake of x86 applications. Probably something daft like exploiting windows being 32bits on ARM and using the other half for x86 emulation layer.
    The ability for an x86 based program to make calls into an ARM based OS is achieved by using the same mechanisms MS used to enable a 32 bit program to make calls into a 64 bit OS. So while the translation mechanism is the same, it doesn't itself have anything to do with the "bitedness" of anything.
    Not sure I get you here, as I don't recall anything particularly special on a 64 bit processor to "run" x86 programs from when I was into assembly programming.
    Based on what I've quoted, this is what I understand your position to be (in my own words):

    1. The 64 "bit'edness" of the ARM CPU probably plays an important role in emulating x86 software on ARM
    2. You think x86 emulation involves something related to the "bitedness" of that ARM CPU which is daft (which would contradict the statement of it being important). You suspect that 32 bits of some 64 bit wide circuitry is involved, but what specifically you are referring to I have no idea. A CPU bus? A CPU register? It seems like you're unsure yourself.
    3. You don't think WOW64 is central to Windows x86 emulation capabilities on ARM.

    I think those positions are incorrect:

    1. The 64 "bit'edness" of the ARM CPU isn't that important. It's necessary because we need to run a 64 bit Windows OS, but it's not taking center stage. It's not a big player.
    2. The 64 "bit'edness" of the Windows OS running on ARM also isn't that important. It's also necessary, but it's important primarily in the sense that it introduces WOW64 to the equation.
    3. WOW64 was built to allow 32 bit x86 software to make function calls into a 64 bit x86 OS. According to Marry Joe Foley, WOW64 (or something conceptually similar) is what will allow 32 bit x86 software to make function calls into a 64 bit ARM OS. The important thing here isn't related to bit'edness, but the fact that WOW64 is a translation layer that mediates between software built for one CPU architecture when it's running on another. This is where part of the emulation magic happens.
    4. WOW64 is actually more than it initially appears to be. I wasn't aware of this until recently myself, but apparently WOW64 already plays a role in allowing Itanium software to run on an x86 CPU, meaning that in addition to translating function calls, it also translates individual CPU instructions. That's the heart of any emulation solution! It seems likely that this is where x86 emulation on ARM will fit into the Windows OS architecture. If true, WOW64 is central to MS' emulation solution.

    In addition to all that, I'm positive that none of this is possible without at least some direct hardware support. MS has already made clear that their x86 emulation capabilities on ARM are tied to very specific chips (e.g. Snapdragon 835) and won't work on just any ARM CPU. IMHO that is a very clear indication of direct hardware support being required at some level, otherwise this would be an ARM feature rather than being specific only to the Qualcomm Snapdragon series of chips, end even then limited to very specific models.
    Last edited by a5cent; 12-20-2016 at 02:19 PM. Reason: spelling
    12-20-2016 01:34 PM
  22. Kogling's Avatar
    The 64 "bit'edness" of the ARM CPU probably plays an important role in emulating x86 software on ARM
    There's usually a fair bit of performance gain from 64bit architectures - usually more registers to play with, simpler memory addressing which in turn can promote speed. x86 emulation for all I know may be simply a matter of obtaining extra registers on the processors to manage the added overhead, that is however, a non specific hardware emulation requirement..

    You suspect that 32 bits of some 64 bit wide circuitry is involved, but what specifically you are referring to I have no idea. A CPU bus? A CPU register? It seems like you're unsure yourself.
    I don't think there is any "hardware" level feature for emulation that you're implying, hence, my suggestion that unless they are running 32bit windows on a 64bit architecture and somehow ingeniously exploiting the other half of the addressing range for x86 processes, I don't see how it's anything beyond straight forward emulation.

    point is, hardware emulation unlikely.

    You don't think WOW64 is central to Windows x86 emulation capabilities on ARM.
    if the OS is 32bit (which our phones are, for example) they shouldn't need WOW64 (which stands for Windows 32 on Windows 64) because there is no "windows 64". It's mostly OS level translation for backward compatibility for applications that have already been compiled to expect 32bit based calls, headers and so on.

    I'm sure there's more to it behind the scenes, and they can call it what they want and implement it how they want, but WOW64 largely revolves around bridging how 64bit OS handles things such as files, registries, handles and system calls and translates them to 32bit usable counterparts.

    The 64 "bit'edness" of the ARM CPU isn't that important. It's necessary because we need to run a 64 bit Windows OS, but it's not taking center stage. It's not a big player
    Depends, as said above, if 64bit opens up extra registers these may be necessary to provide reasonable emulation, so I dont see how 64 bit can be overlooked as a functional necessity. Sure, a 32bit counterpart could be made that had extra, but thats generally not the direction manufacturers generally aim towards.

    WOW64 was built to allow 32 bit x86 software to make function calls into a 64 bit x86 OS. According to Marry Joe Foley, WOW64 (or something conceptually similar) is what will allow 32 bit x86 software to make function calls into a 64 bit ARM OS. The important thing here isn't related to bit'edness, but the fact that WOW64 is a translation layer that mediates between software built for one CPU architecture when it's running on another. This is where part of the emulation magic happens.
    It's really not emulation in the sense most people will be looking at it as.

    So It's not taking a instruction for lets say "add a with b" that was encoded for an x86 instruction set and translating it into the x64 instruction for "add a with b", the x86 application is running as per normal with it's standard x86 instruction encoding, but when it tries opening, for example, a file, since on windows all calls are identical but data structures /values have been extended to 64bit from 32bit, stack requirements change (i.e, some calls dont use the stack) then WOW64 needs to read in the "old school" variety and expand it into 64 bit then make the call to the OS function, and then vise versa for anything windows is sending back to the application.

    This is from my understanding of it.

    The only exception to this is Itanium, but that's not the standard architecture people would be expecting to be talking about for x64.

    WOW64 is actually more than it initially appears to be. I wasn't aware of this until recently myself, but apparently WOW64 already plays a role in allowing Itanium software to run on an x86 CPU, meaning that in addition to translating function calls, it also translates individual CPU instructions. That's the heart of any emulation solution! It seems likely that this is where x86 emulation on ARM will fit into the Windows OS architecture. If true, WOW64 is central to MS' emulation solution.
    This is indeed emulation on the instructions - x86 onto itanium, not aware of the other way around though. and by all accounts because it lacks the "backwards compatibility" that AMD64 for example has on a hardware level, is less efficient, as it's translating instructions (emulating) by software at the instruction level,
    12-20-2016 04:44 PM
  23. a5cent's Avatar
    There's usually a fair bit of performance gain from 64bit architectures
    No Kogling. At least in the consumer space that is simply not true. Upgrading to a 64 bit CPU+OS, in itself and isolated from everything else that a newer chip design might have improved upon, does very little in regard to computational performance. Typically absolutely nothing. The best way to prove this to yourself is to take a 64 bit CPU and benchmark the 64 bit and 32 bit versions of the same OS (the 32 bit version can't exploit any of the 64 bit extensions). Unless you force a situation where you require more than 3.5GB of memory, you'll be hard pressed to notice any difference at all.

    Most of the software you run on a Windows PC is still 32 bit software, meaning it can't exploit any of the supposed advantages of a 64 bit CPU. This is after 64 bit CPUs have being available for more than a decade. Why? Because re-targeting a program to a 64 bit architecture leaves you with multiple installation packages that increases the likelihood of people having installation issues, without it providing any practical benefit (that includes no benefit to performance).

    I think the overwhelming majority of people on this site would tell you the same thing. Take this thread for example:

    http://forums.windowscentral.com/win...os-coming.html

    if the OS is 32bit (which our phones are, for example) they shouldn't need WOW6
    Ehem... except full Windows 10 on ARM won't be 32 bit! It's already been confirmed by MS that it must be the 64 bit version, precisely for the reasons I mentioned. None of that was speculation on my part. I didn't do a good job of clarifying which parts of my post are speculation and which are already confirmed facts. The parts about WOW64 being involved in emulation and translation are already confirmed for example. I have trouble making sense of most of your statements, but it's probably not worth arguing over.

    How exactly emulation works I don't yet know. I've been trying to find out but MS is as tight lipped as ever. However, it's suspicious that the impression you are getting seems to be the exact opposite of the impression I'm getting. Mind sharing your sources? In particular it's stuff like this that appears to go against everything I've read so far:

    So It's not taking a instruction for lets say "add a with b" that was encoded for an x86 instruction set and translating it into the x64 instruction for "add a with b", the x86 application is running as per normal with it's standard x86 instruction encoding,
    If the instructions are not being translated from x86 to ARM, then would you mind explaining what you think is executing those instructions (hint: they mean absolutely zilch to an ARM CPU)?
    Last edited by a5cent; 12-20-2016 at 07:24 PM. Reason: spelling
    12-20-2016 06:34 PM
  24. Kogling's Avatar
    No Kogling. At least in the consumer space that is simply not true. Upgrading to a 64 bit CPU+OS
    x64 on a PC means more registers than it's x86 counterpart, and the case is the same for ARM by the looks of it.

    So an ARM (64bit) processor would (potentially) emulate an x86 application more efficiently because it doesn't need to use the stack as much by keeping as much as it can in registers. An emulator for x86 on ARM (32bit) would have less registers to play with, and therefore be more restricted due to higher memory usage.

    AFAIK the move over to x64 made most windows calls become "fastcall" over "stdcall" which, depending on the architecture is generally faster.
    The best way to prove this to yourself is to take a 64 bit CPU and benchmark the 64 bit and 32 bit versions of the same OS (the 32 bit version can't exploit any of the 64 bit extensions
    So to be clear x64 doesn't emulate instructions from x86 to x64, it runs the code natively.

    On an ARM, regardless of 32bit or 64bit, the x86 instruction has to be converted to native ARM instructions. ARM64 would have more registers to play with for a start to make it more feasible, as indicated above.

    You can't treat ARM's x86 emulation the same as x64, since x64 IS native execution via backwards compatibility in the architecture.
    Ehem... except full Windows 10 on ARM won't be 32 bit! It's already been confirmed by MS that it must be the 64 bit version, precisely for the reasons I mentioned
    which isn't my point, it's speculative on the basis that emulation requires 64bit processors. The idea is you compare the feasibility of x86 emulation on a 32bit ARM vs 64bit ARM. 64bit ARM has a clear advantage on usable registers alone.

    Hence my original point, older 32bit ARMs probably couldn't emulate x86 because the lack of registers meant a significant loss of performance having to constantly swap out.

    .The parts about WOW64 being involved in emulation and translation are already confirmed for example.
    it really doesn't matter what is doing the emulation.

    WOW64 is software, therefore WOW64 = software based emulation. Software is emulating it whether they make it part of WOW64 or call it WOW-ARM64 or potato.

    Being WOW or not doesn't change anything. It's still software emulation. WOW64 is just better for developers i guess? and its still true to it's name.
    How exactly emulation works I don't yet know. I've been trying to find out but MS is as tight lipped as ever.
    I'm only going on my knowledge of assembly programming which includes reading AMD processor specifications (the one for people wanting to make OSes and drivers) and also microsoft's documentation on x64 programming, which included WOW64.

    but: "how does WOW64 emulate x86" into google.

    How Windows 64-bit Supports 32-bit Applications | Gizmo's Freeware
    "Under Windows 64-bit, 32-bit applications run on top of an emulation of a 32-bit operating system that is called Windows 32-bit on Windows 64-bit, or WOW64 for short.* WOW64 intercepts all operating system calls made by a 32-bit application.

    For each operating system call made, WOW64 generates native 64-bit system calls, converting 32-bit data structures into 64-bit aligned structures. The appropriate native 64-bit system call is passed to the operating system kernel, and any output data from the 64-bit system call is converted into a format appropriate for the calling application before being passed back."

    --------------
    this is basically converting standard call to and from fast call, and 32bit values to and from 64bit.
    ------------
    Lesson 2. Support of 32-bit applications in the 64-bit Windows environment

    "Different processor architectures have a bit different WoW64. For example, the 64-bit Windows version developed for Intel Itanium 2 processor, employs WoW64 to emulate x86 instructions. This emulation is rather resource-intensive in comparison to WoW64 for Intel 64 architecture, because the system has to switch from the 64-bit mode to compatibility mode when executing 32-bit programs

    WoW64 on Intel 64 (AMD64 / x64) does not require instruction emulation. In this case the WoW64 subsystem emulates only the 32-bit environment through an additional layer between a 32-bit application, and the 64-bit Windows API"

    ---------------------
    Some of the earlier Itanium had x86 hardware support, all the modern ones are purely software emulation as far as i can see.

    If the instructions are not being translated from x86 to ARM, then would you mind explaining what you think is executing those instructions
    The x64 is backward compatible with x86 as part of the architecture. All the x86 parts (registers, etc) are just widened to 64bits.

    the irony is the x86 is backwards compatible with the previous 16bit architecture of DOS? days. When a x64 CPU is booting up, it's in the 16bit mode, the bootloader enables the A20 gate, thus enabling 32bit mode, then from 32bit mode it switches to long mode (if my memory serves me right) and then you have access to 64bit processor functions.

    ARM would need x86 instruction translated into ARM native code.

    My point above was to try (further) stress that WOW64 on an x64 is native x86 execution and only serves as a windows API translation. Itanium is a special case where it does actually provide emulation of the x86 instruction sets.

    x86 on ARM would need the x86 instruction set to be emulated.

    but this all boils down to the fact that it's done via software in WOW64, not hardware, and if you exclude the Itanium special case, instruction set emulation is entirely different to the main bulk of what WOW64 does on standard computers.



    So to clarify, x86 on ARM needs emulation. Emulation on windows with x64 (not ARM) as of current is only for system calls (excluding itanium) whereas ARM will be requiring x86 instruction emulation.

    Reading, decoding and translating of x86 into ARM is likely to need the use of many CPU registers to make it within reasonable performance levels. ARM64 bit has more registers at hand, therefore one of the defining characteristics of support of x86 emulation is a 64bit processor.

    my 2 cents
    Last edited by Kogling; 12-20-2016 at 09:08 PM.
    12-20-2016 08:48 PM
  25. a5cent's Avatar
    You answered pretty much every question I had, except for the one that I would have been most interested in ;-)

    You initially said that x86 instructions are not translated to ARM instructions, but now it seems you're saying something else, so I'm going to assume we now agree that x86 instructions on ARM must be translated before they can be executed.
    Last edited by a5cent; 12-21-2016 at 05:56 AM.
    12-21-2016 05:46 AM
53 123

Similar Threads

  1. when i click on link in browser pop up spyware comes up. How can i fix this?
    By Windows Central Question in forum Ask a Question
    Replies: 4
    Last Post: 12-12-2016, 12:05 AM
  2. Replies: 1
    Last Post: 12-11-2016, 09:38 AM
  3. Why Can't I Move Groove Music Onto A SD Card?
    By Windows Central Question in forum Ask a Question
    Replies: 1
    Last Post: 12-10-2016, 11:33 PM
  4. Can't Enable Cortana on Band 2 Running Insider Fast Ring on 950XL
    By RicketyTiger in forum Microsoft Band & Band 2
    Replies: 1
    Last Post: 12-10-2016, 11:59 AM
  5. Can not answer calls in my 2013 Taurus anymore using Synch
    By Windows Central Question in forum Ask a Question
    Replies: 0
    Last Post: 12-10-2016, 09:59 AM
LINK TO POST COPIED TO CLIPBOARD