Next Generation of Windows To Run On ARM Chip 307
Hugh Pickens writes "Sharon Chan reports in the Seattle Times that at the Consumer Electronics Show in Las Vegas, Microsoft showed the next generation of Windows running natively on an ARM chip design, commonly used in the mobile computing world, indicating a schism with Intel, the chip maker Microsoft has worked with closely with throughout the history of Windows and the PC. The Microsoft demonstration showed Word, PowerPoint and high definition video running on a prototype ARM chipset made by Texas Instruments, Nvidia. 'It's part of our plans for the next generation of Windows,' says Steve Sinofsky, president of Windows division. 'That's all under the hood.' According to a report in the WSJ, the long-running alliance between Microsoft and Intel is coming to a day of reckoning as sales of tablets, smartphones and televisions using rival technologies take off, pushing the two technology giants to go their separate ways. The rise of smartphones and more recently, tablets, has strained the relationship as Intel's chips haven't been able to match the low power consumption of chips based on designs licensed from ARM. Intel has also thumbed its nose at Microsoft by collaborating with Microsoft archrival Google on the Chrome OS, Google's operating system that will compete with Windows in the netbook computer market. 'I think it's a deep fracture,' says venture capitalist Jean-Louis Gassee regarding relations between Microsoft and Intel."
Nvidia cpu (Score:4, Interesting)
Re:But but but but but.... (Score:4, Interesting)
Re:But but but but but.... (Score:5, Interesting)
Having a cross compiler would probably be a necessity.
ARM is pretty quick these days, but has nowhere near the power of the multicore 64-bit chips coming out of AMD and Intel at the moment.
Also there's the branding to think about. Sure windows ran/runs on a few architectures already, but if it *does* come down to x86/win32 apps not working on ARM machines and vice-versa, won't MS have a bit of a public education battle? Will the general public get confused by windows apps that are for one hardware variant and not another? Or will MS mandate fat binaries if you want Windows 8 certification or something?
Many questions...
Re:But but but but but.... (Score:2, Interesting)
TargetCPU in the "advanced" compile options currently allows targeting AnyCPU( x86, x64 ), x64 only, and x86 only. It'd be somewhat reasonable to have the next version of the framework ( 4.5? ) be able to target ARM as a compile option ( maybe even offer an emulator for your code? ) and ship that as a SP to VS 2010.
Of course, there isn't enough windows bashing in this post to get it modded up, but oh well.
Re:But but but but but.... (Score:4, Interesting)
Well, this depends on their target audience.
If you have C/C++ code, porting it to ARM should be a huge deal. Yes there will be some differences, yes, there will be bugs - but in terms of effort its manageable. And more importantly, every single vendor has to do this effort, so Microsoft doesn't have to do anything.
Because Microsoft are saying this now, with no product that anyone can "buy" right now (or even soon), this probably means the audience for this news is *Developers* (the single intelligent word that Mr Balmer has uttered in the last 20 years, so good, he had to say it multiple times for it be considered a quote). They are now selling the ARM architecture to developers. If the developers buy this story, the applications will follow.
And of course, some developers will be more prepared than others. Don't expect an ARM version of Photoshop anytime soon, but an ARM version of Firefox is something that could be cranked out very easily.
I smell Vapourware... (Score:5, Interesting)
Windows on ARM (Score:5, Interesting)
Windows on ARM? That doesn't matter.
Office on ARM is a million times more important - for a start, that suggests you can open your documents on another new platform without having to worry about export filters and binary compatibility. But hey, I'm afraid OpenOffice and suchlike beat you to it.
The problem with Windows on ARM is that no currently existing Windows program will run on it. It's a new architecture without binary compatibility, like Windows CE was. Sure you can port things over but you can do that anyway and few have bothered. Things like the NET framework are "supposed" to be cross-platform but you can be assured than anything vital that you have to use and that you have no control over development of (e.g. business apps) requires an x86 binary at some point, or isn't supported on ARM. So even your programs that are written in NET need to be ported (which usually means it'll never happen).
Telling people that Windows now runs on ARM is misleading - they will think that everything from Half-Life 2 to Sage should work on it without touching anything. What you mean is that there is now an official OS for ARM that looks and works a bit like Windows. Like Windows CE was. But then, what ARM? There are hundreds of ARM variations and not all of them can be catered to, so you're back to it only working on select platforms that have been especially designed for it - like, erm, Windows CE was. Can I join a domain and run my existing business apps? No? Then it's actually just the Windows *GUI* that's consistent across platforms, not the OS.
Even if the next-gen of Windows 8 can be almost identical on PC or other devices, you're then into the problem that it's not the OS that matters (and that pretty much *does* have to be changed for every hardware variation) but the applications. And "Windows on ARM" will make people think they can install Steam on it and just run everything. That's not the case and never will be.
Windows on ARM is a response to Android, to try to pretend to be as cross-platform. Same as OpenXML was a response to ODF, to try to pretend to be platform-independent. In reality, the headline will grab eyes and then the reality will disappoint. But in the meantime, you've sold a "portable Windows" license to some mobile-carrier who has to repeatedly explain that "desktop Windows" isn't the same as "mobile Windows".
It's just Windows CE. Remember trying to explain to people that Pocket Word wasn't the same as desktop Word? Same thing over again.
Re:But but but but but.... (Score:4, Interesting)
Re:Windows on ARM (Score:2, Interesting)
Is that the same Office as I get on my desktop installation CD? No? So it's a Microsoft-only product that's been ported by Microsoft to a Microsoft architecture? Windows "runs" on Alpha too. Office "runs" on Mac by that definition. What you're actually doing is BUYING another version of Office written specifically for that particular "Windows" port by the authors of the software who also happen to be the authors of the OS. How many *other* companies do you think stand a chance in hell of doing that, even with MS's co-operation, and having it work, let alone actually making money on the idea?
It's "Office-like" or even an "Office-port" but it's not "Office". Office ports have run on MacOS for decades. Office can run under Linux if you use WINE. It doesn't mean that "Office is on Linux" or that it's supported (no support = no business use). Also doesn't mean that even 1% of the apps that a business runs or plugs into Office will work on Mac or this or anything else.
There is a new version of Office - that's the news - that can run on ARM and open standard Office docs. The whole "Windows on ARM" thing is a load of misleading marketing nonsense. That's *not* Windows on ARM, and certainly not any other primarily-Windows application on ARM (probably ever). It's a program that normally works on x86 architectures being ported to work on one other architecture and then claimed as being a "Windows on ARM". I bet it gets all the feature parity, updates, support, combined licensing that Pocket Word does (that's "Office on Windows CE", right? (sarcasm) ) or even Office on Mac (no ActiveX integration - how would they? -, no RTF emails, no ODF support, etc. etc. etc.).
*This* Office is not a Windows application. That's entirely my point. It's an ARM application. Running an ARM application on an ARM OS is no shocker. Running a *Windows* (and hence suggesting x86) application on an ARM OS *would be*.
Re:But but but but but.... (Score:4, Interesting)
"What about the huge catalogue of win32 applications?"
They'll probably create an x86-to-ARM JIT-compiler. Like Alpha did with Windows NT during 90-s. So for a brief period Windows NT on Alpha was the fastest way to run x86 applications.
And it's not like they need to emulate the whole API like Wine has to do, they just need to translate x86 calling conventions to ARM calling convention, which can be done by a fairly simple shim layer.
Re:Nvidia cpu (Score:4, Interesting)
Re:Another one (Score:5, Interesting)
Yeah, the other issue is that ARM code is "bigger" but somehow a 900MHz ARM outruns a 1500MHz x86... hmm, why so much faster? The answer turns out to involve small decisions and branches, which on x86 et al involve load-compare-branch (mov %eax ... cmp %eax ... jne), whereas on ARM you have compare-prefix (mov %r1 ... cmp %r1 ... SUBGT, SUBLT, MOVEQ, BNE, etc) that don't take an extra cycle, i.e. MOVGT takes 1 cycle and MOV takes 1 cycle.
This means a lot of simple code compiles to simple instructions, whereas on x86 you have a huge amount of branching to do. A lot of 'if' and 'select' statements can be reorganized to just do one comparison and then drop through a bunch of instructions that are prefixed for simple cases.
This kind of thing reduces the performance penalty of not having a branch predictor--that's right, ARM performs as well as it does with no branch prediction. ARM has a huge number of registers (something like 16 with identical general purpose use and access times, vs x86 4 GPRs), lack of support for mis-aligned memory access (simple, fast data access paths), and a few cherry-picked things like a built-in barrel shifter in any arithmetic instruction (you can i.e. add numbers with shift left/right as part of the instruction). Also most instructions run in 1 cycle--even really crazy ones like conditional-arithmetic-shift (i.e. SUBGT Ra, Ri, Rj, LSL #2)-- whereas stuff like x86 runs an average of 2-3 clock cycles per instruction, with some very long. That means that a 2.5GHz x86 is about as fast as a 1GHz ARM.
ARM is a large amount of compensation for not implementing complex features. They look hard and say, "Well... this is a general good performance feature..." and do that; whereas CISC is like, "Here's a special case we should do... and oh, branch prediction would let us try to speed up branches... and we could add instructions for manipulating ASCIIZ strinsg..." RISC is more like, "Well, let's try to do everything in 1 cycle... let's prefix instructions so that we can avoid branching... let's add a ton of registers... let's not make a slow decoder... let's restrict memory access to avoid performance hits in cache misses..."