Microsoft Confirms No x86 Wrapper For ARM Systems
Earlier this year, Intel software VP Renee James caused a kerfluffle between himself and Microsoft when he claimed Microsoft's upcoming OS wouldn't support older x86 applications when running on an ARM processor. Microsoft, in response, called his characterization "factually inaccurate and unfortunately misleading."
...Except, apparently, it wasn't—at least, not as far as ARM/x86 compatibility were concerned. During a Q&A session this past week, Windows division President Steven Sinofsky clarified the relationship between the two architectures:
Sinofsky's explanation is confused, at best, particularly when he implies that allowing x86 applications to run on ARM tablets is an unacceptable security risk. His comments on battery life are closer to the mark. Even if Microsoft could write a perfect application translation layer, there's no way to perform such tasks without incurring a significant performance penalty and thereby reducing battery life. It's one thing to create platform-agnostic development tools that can be used to create compatible software and something altogether different to provide the sort of translation layers that would allow x86 programs to run seamlessly on ARM processors. Relying on software emulation worked for Apple in the 1990s when it transitioned from the 68k microarchitecture to PowerPC, partly because the entire emulator could fit within 16K of L1 cache, but it's the kiss of death for any mobile architecture.
Generally speaking, emulation only works when the new processor is powerful enough to run a non-native application with a minimal performance hit. The current shipping crop of ARM-based products have no realistic chance of pulling this off. 45nm Atom CPUs may not be able to match Cortex-A9 TDP, but Atom offers far more performance. This throws the performance-related problems of emulation into stark relief; Atom's native x86 application performance is poor-to-mediocre at the best of times. Attempting to compete with Atom by emulating x86 on ARM is as bass-ackwards a proposition as one could ask for.
When Business Interests Collide
The APIs and environments are architecture-agnostic by design
Microsoft's Windows 8 development strategy de-emphasizes CPU architecture in favor of application-level compatibility and unified programming tools. The (theoretical) advantage of the new scheme is that programmers who develop Metro-compatible software can do so without worrying about needing to maintain separate code for the x86 and ARM versions. From Microsoft's perspective, such flexibility is enormously appealing. From Intel's, it's a nightmare. The last thing Intel wants is an agnostic development environment that lets Windows 8 developers target both CPU architectures at the same time. Allowing them to do so prevents the company from arguing that sinking cash into x86 development is a better use of resources. The company is left with no choice but to emphasize a legacy compatibility argument that Windows 8 undermines with its own emphasis on Metro and the need to switch into the clunky (for tablets) legacy UI in order to run legacy apps.
Five years ago, Microsoft undermined its own Windows Vista design goals, angered HP, and sparked a chain of events that got the company sued over the definition of 'Vista Capable,' all in the name of helping Intel to sell more chipsets. The two companies remain allies, but the hand-in-glove relationship that characterized the original WinTel alliance is, by all appearances, over.
...Except, apparently, it wasn't—at least, not as far as ARM/x86 compatibility were concerned. During a Q&A session this past week, Windows division President Steven Sinofsky clarified the relationship between the two architectures:
We've been very clear since the very first CES demos and forward that the ARM product won't run any X86 applications... We built a great deal of what we call class drivers, with the ability to run all sorts of printers and peripherals out of the box with the ARM version. What we talked about yesterday was... when you write a Metro style application, all the tools are there to enable you in any of the languages that we support to automatically support ARM or X86...It's Not A Feature, Just Inevitable
If we allow the world of X86 application support like that, or based on what we call desktop apps in our start yesterday, then there are real challenges in some of the value proposition for system on a chip, you know, will battery life be as good, for example? Well, those applications aren't written to be really great in the face of limited battery constraints, which is a value proposition of the Metro style apps. So, we have to be careful that we don't remove the value proposition for those applications. On the other hand, people would say, oh, but you have to let them run because then there's that whole ecosystem. And then if we do let them run, we just brought the perceived negatives of some of the ecosystem. So, people say, great, now it's easy to port viruses and malware and we'll port those.
So, we've taken the approach that we're going to build a bunch of rich capabilities in the operating system that allow devices and peripherals and a broad range of form factors all to run and working with multiple ARM partners on the ARM side, and then Intel and AMD on the system on a chip side, but then focus on the Metro style applications as the opportunity.
Sinofsky's explanation is confused, at best, particularly when he implies that allowing x86 applications to run on ARM tablets is an unacceptable security risk. His comments on battery life are closer to the mark. Even if Microsoft could write a perfect application translation layer, there's no way to perform such tasks without incurring a significant performance penalty and thereby reducing battery life. It's one thing to create platform-agnostic development tools that can be used to create compatible software and something altogether different to provide the sort of translation layers that would allow x86 programs to run seamlessly on ARM processors. Relying on software emulation worked for Apple in the 1990s when it transitioned from the 68k microarchitecture to PowerPC, partly because the entire emulator could fit within 16K of L1 cache, but it's the kiss of death for any mobile architecture.
Generally speaking, emulation only works when the new processor is powerful enough to run a non-native application with a minimal performance hit. The current shipping crop of ARM-based products have no realistic chance of pulling this off. 45nm Atom CPUs may not be able to match Cortex-A9 TDP, but Atom offers far more performance. This throws the performance-related problems of emulation into stark relief; Atom's native x86 application performance is poor-to-mediocre at the best of times. Attempting to compete with Atom by emulating x86 on ARM is as bass-ackwards a proposition as one could ask for.
When Business Interests Collide
The APIs and environments are architecture-agnostic by design
Microsoft's Windows 8 development strategy de-emphasizes CPU architecture in favor of application-level compatibility and unified programming tools. The (theoretical) advantage of the new scheme is that programmers who develop Metro-compatible software can do so without worrying about needing to maintain separate code for the x86 and ARM versions. From Microsoft's perspective, such flexibility is enormously appealing. From Intel's, it's a nightmare. The last thing Intel wants is an agnostic development environment that lets Windows 8 developers target both CPU architectures at the same time. Allowing them to do so prevents the company from arguing that sinking cash into x86 development is a better use of resources. The company is left with no choice but to emphasize a legacy compatibility argument that Windows 8 undermines with its own emphasis on Metro and the need to switch into the clunky (for tablets) legacy UI in order to run legacy apps.
Five years ago, Microsoft undermined its own Windows Vista design goals, angered HP, and sparked a chain of events that got the company sued over the definition of 'Vista Capable,' all in the name of helping Intel to sell more chipsets. The two companies remain allies, but the hand-in-glove relationship that characterized the original WinTel alliance is, by all appearances, over.
