Microsoft Launches Windows 10 on ARM
The first PCs will be the ASUS NovaGo, which is a convertible laptop, and the HP ENVY x2 convertible tablet.
This is exciting news on a couple of fronts. The Qualcomm Snapdragon 835, which was the processor first announced for Windows 10 on ARM, offers reasonable performance, but with lower power consumption than what we’ve been used to in the PC space, and especially in low-power states. Without having the devices in-hand, we still don’t know how the SD835 compares in performance to the competition. We should finally be able to answer that soon though.
[…]
Battery life should also be a big win, and while we don’t have our own tests done yet, Microsoft’s information is claiming up to 30 days of standby and up to 22 hours of active use, while the detachable tablet-style HP ENVY x2 is claiming up to 20 hours of active use.
Branded as Always Connected PCs, the new Windows on ARM systems are positioned as bringing together the best of PCs and smartphones. They have PC form factors, with the productivity enabled by a real keyboard, touchpad, and general purpose operating system capable of running regular Windows software, but they bring with them the seamless switching between LTE and Wi-Fi, instant on, multiple working day battery life, and slimline, lightweight packaging that we’re accustomed to on our phones.
[…]
The emulator runs in a just-in-time basis, converting blocks of x86 code to equivalent blocks of ARM code. This conversion is cached both in memory (so each given part of a program only has to be translated once per run) and on disk (so subsequent uses of the program should be faster, as they can skip the translation). Moreover, system libraries—the various DLLs that applications load to make use of operating system features—are all native ARM code, including the libraries loaded by x86 programs. Calling them “Compiled Hybrid Portable Executables” (or “chippie” for short), these libraries are ARM native code, compiled in such a way as to let them respond to x86 function calls.
5 Comments RSS · Twitter
I was hoping Apple would take this x86-compatibility approach with ARM-based Macs. Last year, I was lamenting the fact that Apple has the technology to make more affordable Macs but so far has chosen not to: https://www.cv13.net/post/affordable-macs/
Now, after years of us wondering what Apple may or may not do, Microsoft's gone ahead and shipped. A Windows 10 S ARMbook is shaping up to be a rather compelling Chromebook alternative for a large swatch of computing needs (webapps + UWP, without the Win32 cruft). I'm beginning to doubt that family members will stick with Apple when the time comes for hardware upgrades.
Hey, this means mixed mode is back! Apple used it for the 68k to PowerPC transition*, but couldn't use it for the PowerPC to Intel transition (in large part because the endianness difference meant the two bodies of code could not share a common address space). Performance tradeoffs are complex, and depend on the emulation technology anyway (e.g. the 68k emulator in the Mac OS was an interpreter, while here dynamic translation will be used), but entering/exiting the emulator is often a bottleneck, meaning short-lived API functions might be better off *not* being native code (when called from a non-native app, of course), to avoid the penalty of exiting the emulator and then reentering it each time.
And power consumption performance will be interesting to measure and analyze, because that simply wasn't a concern for either the PowerPC or Intel transition, so we don't have nearly as much knowledge in that area. Main advantage of mixed-mode, however, is that it saves memory (no need to have two library stacks loaded in RAM), though that is somewhat negated by the translation cache, and maintenance for the compatibility environment is easier since there is no separate library stack to maintain: compare Rosetta, whose support was dropped merely a few years after the first Intel Macs shipped, with the 68k environment which remained supported just as long as Classic was.
I don't believe Apple will go the route of ARM laptops, however. I find it more likely for them to make iOS x86 laptops.
*in large part because Apple had to ensure support of its own 68k legacy code in the system software, since most of it was written in assembly. For a long time some third-party software programs (or some parts of them) just weren't worth making PowerPC-native, because they often dealt with APIs that were still 68k!
"Hey, this means mixed mode is back!"
Thanks for this info, Pierre. As a non-dev, I was inexplicably curious if this was more like Rosetta or 68K->PPC. And now I sorta know!
[…] Previously: Apple Rumored to Combine iPhone, iPad, and Mac Apps to Create One User Experience, Microsoft Launches Windows 10 on ARM. […]
Having the system libraries not require translation is probably what keeps the performance and battery life within reason running x86 code. It'll be interesting to see the performance of gigantic codebases where a big amount of the code is still legitimately spent inside the app and surrounding infrastructure and not just the system - I wouldn't be surprised if something like Chrome would knock the battery life down to closer to 10 hours (assuming 20 hours is realistically achievable).
It'll be interesting to know if .NET code runs on an ARM-native CLR with an ARM JIT, or if it takes the x86 detour, which would mean better compatibility with the many .NET apps including native components.