Coffeehouse Thread

16 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

Windows on ARM

Back to Forum: Coffeehouse
  • User profile image
    JoshRoss

    Since this is now public, can we see some geeky details, like what was required to do this? Was or is the Phoenix compiler involved?

    -Josh

  • User profile image
    Bass

    NT was designed with multi-architecture, multi-API capability in mind (despite mostly being used with Win32 and x86). I believe NT4 had an ARM port. So I wouldn't be surprised if Microsoft always had an ARM port, and even if they didn't, it probably wasn't a lot of code to rewrite to port Windows 7 to ARM.

  • User profile image
    Sven Groot

    NT4 had an Alpha port (and so did Windows 2000 up to beta 3, after which it was dropped). I don't think it had an ARM port.

    But yeah, NT was designed for easy portability, getting it to run on ARM shouldn't be too difficult.

  • User profile image
    JoshRoss

    I ran WindowsNT 3.51 on the Alpha AXP. At the time, we had FX!32, a translator that would run x86 code, with a substantial performance hit. I have to image that there have been all kinds of changes to the kernel since then.

    Anyways, the Alpha smoked the fastest chips Intel offered, so it was excusable to take a 40% perf hit, when the system ran much faster than native. But, if you were to do something like FX!32 backwards and use slower hardware, like ARM, you better have some cool tricks up your sleeve, just to make the situation tolerable.

    -Josh

  • User profile image
    Charles

    We'll dig into the technical details when the time is right.

    C

  • User profile image
    W3bbo

    I wonder, is it easier to reverse-engineer software if you have multiple binaries for different architectures from the same source? (so one thing that might have been optimised-away for one arch might remain in the binaries for another).

  • User profile image
    felix9

    @JoshRoss:

    There were rumors said that NVidia is working on some kind of x86->ARM translating thingy, lets wait and see.

    for MS IIRC there was a quite decent x86 translator inside VirtualPC for Mac, but thats for PowerPC of course.

    But FX!32 should be a better approach because it only translate the user code and calls into native dlls when calling apis.

    @Charles:

    Cool. I guess the guys in WinDiv/DevDiv will be super busy in the foreseeable future though.

  • User profile image
    W3bbo

    , felix9 wrote

    @JoshRoss:

    There were rumors said that NVidia is working on some kind of x86->ARM translating thingy, lets wait and see.

    for MS IIRC there was a quite decent x86 translator inside VirtualPC for Mac, but thats for PowerPC of course.

    But FX!32 should be a better approach because it only translate the user code and calls into native dlls when calling apis.

    @Charles:

    Cool. I guess the guys in WinDiv/DevDiv will be super busy in the foreseeable future though.

    Don't forget the x86->IA64 translator in Windows Server for Itanium.

  • User profile image
    felix9

    Ahh yes, WoW64 ! maybe we will see WoWARM ?

    But what if somebody accidentaly runs a native ARM app on an x86 Windows ? should there be WoWx86 too ? or is this scenario a rare corner case that can be safely ignored ?? Tongue Out

    anyway, managed apps are prefered now.

  • User profile image
    JoshRoss

    @felix9: The idea that you have potentially a many-to-many relationship with application binaries and platforms is a real mind bender. I'm glad that I target managed runtimes, for the software I write.

    Who knows, you might even have hardware that has both platforms on one board. There has been a lot of talk about heterogeneous chips, but that was more like having a DSP on the CPU.

    -Josh

  • User profile image
    elmer

    @JoshRoss: I also recall working with NT on Alpha and using FX!32.

    While it worked well enough, just as you say, the overhead was MASSIVE, and only made acceptable because the Alpha was so much faster than any available x86 processor at the time.

    However... while the Intel Atom may not be any rocketship, it's not slow enough to for any ARM cpu to get away with wasting that much processor resource on translation.

    Let's hope whatever solution MS have in mind, it's better than the FX!32 approach.

     

     

  • User profile image
    staceyw

    My Micro Framework device (i.e. Fez at tinyclr.com) has been running on an ARM7 for some time. C# and the framework runs like a champ.  NetMF has a porting kit, so any processor can create their own HAL and port themselfs.  They can even port it to run over an OS, instead of direct metal.  I realize this is apples/oranges. But having a porting kit like NETMF does would have let ARM do this themselfs years ago. Smiley

  • User profile image
    JoshRoss

    @staceyw: What do you do with your device?

  • User profile image
    Cream​Filling512

    They should support THUMB as well.

  • User profile image
    QuickC

    There seems to be two views to the ARM adventure.  Looking forward, and Looking back. 

    Looking forward we will see any managed apps written today, should run on ARM unchanged including the XNA games. With the ARM product feature Jazelle should be ported to be the CLR accellerator, now that would be big plus and certainly along the lines of ARM's type of answers to problems. 

    Looking back at native x86 programs running on ARM is unlikely to be a in the box Microsoft product.  Although the many DSP and GPU type products typically bundled in the SOC could make the x86 emulation/translation viable.

  • User profile image
    W3bbo

    , QuickC wrote

    There seems to be two views to the ARM adventure.  Looking forward, and Looking back. 

    Looking forward we will see any managed apps written today, should run on ARM unchanged including the XNA games. With the ARM product feature Jazelle should be ported to be the CLR accellerator, now that would be big plus and certainly along the lines of ARM's type of answers to problems. 

    Looking back at native x86 programs running on ARM is unlikely to be a in the box Microsoft product.  Although the many DSP and GPU type products typically bundled in the SOC could make the x86 emulation/translation viable.

    Windows for ARM has immediate applications in the server world where a lot of the code running is either first-party or CLR-based (especially .NET shops' servers) where changing ISA isn't that big a problem; I imagine we'll see offerings from Dell and HP almost immediately. Who wouldn't jump at the chance of a server with similar performance-per-U but with a fraction of the CPU cost and power consumption?

    ...unless Microsoft cocks this one up bad, like how they keep missing WP7-based tablets *ugh!* and they seem to think that ARM is only useful in consumer electronics.

     

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.