Slashdot Mirror
Next Generation of Windows To Run On ARM Chip
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."
just happens to be coming out as well.
I knew it was getting fucking cold in here.
--Satan
What about the huge catalogue of win32 applications?
If I was to believe the anti-linux trolling of the last decade or so, that's the major reason people won't ever, ever switch!
On a more serious note, I know .Net stuff stands a good chance of working fine, but there's a hell of a lot of windows stuff people use that isn't .Net and I can't see a translation engine or emulation working that great on ARM stuff.
Wikipedia tells me that .NET (and therefore managed code) is nearly 10 years old (13 February 2002)
I'm pretty sure that someone in Redmond was thinking about supporting multiple platforms when they started architecting their software compiler strategy back then. It just took their management structure 5 years to wake up to the idea.
Now people have to go in and remove all of that crud which is blocking porting their SW to a different architecture ...
DLL Hell was yesterday, tomorrow is P/Invoke hell.
[ Monday is a terrible way to spend one seventh of your life. ]
Not all that surprising. Back in the day, NT ran on MIPS and Alpha and you could compile native code for both from respective versions of Visual C. That was a long time ago but all the code infrastructure to support different CPU architectures are still there. 3rd party code is a different story.
Donald 'Duck' Dunn: We had a band powerful enough to turn goat piss into gasoline.
Properly written .Net apps should run unchanged (needing, at most, a recompile) on Arm. I've written apps (in the .Net 2 days) that ran on XP and CE.Net devices with just a recompile.
Best Slashdot Co
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.
Everyone seems to rambling on about x86 compatability and running existing Windows applications on the ARM cpu. I see this more as an admission from MS that the desktop environment is stagnant and growth will be found in the market for dedicated devices (phones, tablets, netbooks etc). I don't see that this will be about desktops at all. I see this more like Apple does with iOS and OS X. Same code base but one runs on portable devices and the other is for their desktop machines. I have not real insight but I don't see where ARM desktop machines make any sense.
Anyone remember when Windows NT ran on x86, PPC, MIPS and alpha? It was amazing how much better it ran on the Alpha hardware than any x86 machines. Maybe it'll be a step forward for them - not that I really care.
Alex, I'll take keybindings not used by Emacs for $400....
I specifically remember Cmdr. La Forge always talking about iso-linear chips. Not once did he ever mention ARM chips. Just like Microsoft to support the wrong Next Generation systems.
I think calling this a swipe at Intel is overblown. Intel has historically sold ARM-based processors ( see the XScale at http://en.wikipedia.org/wiki/XScale), although they sold-off most of their ARM business to a company called Marvell. However, Intel continued to Fab for Marvell until Marvell was able to build or rent their own Fab. I don't know the current situation, but there is a good chance that Intel still has an ARM production line running under contract for Marvell. At the bottom of the wiki article it says, "Intel still holds an ARM license even after the sale of XScale." So they can move right into the business again if they see the market justification for it.
If they intend the next windows to be available for both Intel and ARM processors, they expect the ARM-Windows to be used on tablets, smartphones, etc.
It means that they do not want translation engines and automagic emulation - noone wants to get a pile of win32 application 1-to-1 copies on a tablet platform. .NET libraries and win32 api required for porting; but the porting needs to involve changes to the UI in any case, including support for low-precision finger pointing, multitouch, physically small screens, etc. All MS needs to do for the current applications is to make the porting process reasonably cheap.
They'll supply the changes to the
Microsoft has shown/announced a lot of cool stuff that will work on the "next generation of Windows". If only half of it ever made it into a shipping version of Windows, I might actually consider Windows an option.
You're probably trolling, but in case you're not I'd like to point out that ARM clocks up to 2.5 GHz (and Netburst taught us that mere clock speed is not the future) and is multicore.
Gamingmuseum.com: Give your 3D accelerator a rest.
What? Microsoft just made the smartest decision in their corporate lifetime. Well, third-smartest, and critical to their survival.
x86 is not the only architecture out there. Itanium is a market failure, RISC is relegated to the memory of us modem-wielding veterans, is there another chip line out there I forgot? If so, irrelevant.
Windows on ARM means:
- Potential NT kernel on phones. Hey, the NT kernel isn't half bad. A single kernel everywhere eorks for Linux, just sayin'.
- Opportunity for new markets like tablets and set-top/integrated TV systems. No, an Atom-powered tablet isn't ery attractive. Power demand is the issue, and ARM seems to be the king of power demand.
- A huge developer base that may not have to learn Java or Cocoa or Objective-C after all to be rlevant in our mobile- social- oriented world.
I mean, Microsoft winning sounds evil, but we should know by now that competition is good. Apple may have to answer this, and the Linux/Android community hasn't changed their value proposition one iota. In fact, consider the appeal of buying a phone and THEN choosing the OS you want - 'WindowsARM', Android, 'OpenIOS'... Or perhaps a hypervisor and VMs running any of the three?
I like it. 2GHz dual-core DX10 phones with 2GB RAM and a uSD slot for another 128G, 4.5" AMOLED screens and 1080p HDMI out? All I need now is to find a table at the Starbucks with the Bluetooth keyboard and mouse, and the 21" display, and I'm rockin.
I can dream, can't I?
deleting the extra space after periods so i can stay relevant, yeah.
RISC was better 20 years ago because CISC chips were using close to 50% of the die area for complex decoders. RISC chips could use 5%, giving them vastly more space to cram on ALUs and so on. Then the transistor budget increased, but the decoder complexity stayed pretty constant. 50% became 25%, then 10%, and now the increased space on RISC chips is pretty much irrelevant and the space-saving in instruction cache offsets it.
Then people started caring about power consumption, and it turned out that the decoder (or, in the case of x86, the micro-op decoder, which is basically a RISC decoder after the CISC decoder) was about the only bit of the chip that couldn't be turned off while the CPU was doing anything. You can power down the FPU, the vector unit, and any of the other execution units that aren't relevant to the in-flight instructions, but you can't power down the decoder[1]. ARM does very well here. It achieves good instruction density with the 16-bit Thumb / Thumb2 instruction sets, but it can power down the ARM decoder when running Thumb code or power down the Thumb decoder when running ARM code, so the extra decoder complexity doesn't come with an increased power requirement.
[1] Xeons actually do power down the decoder when running cached micro-ops, but they need to keep the micro-op decoder powered, and this has a similar power requirement to a RISC decoder.
I am TheRaven on Soylent News
You can develop for Windows Mobile 7 in VS and it compiles to .NET and then runs that in an Arm emulator which is running the Windows Mobile 7 OS.
If your application is 100% Pure .NET, it won't easily be portable outside a .NET environment. Unlike a C++ application, whose back-end can be shared among front-ends for each platform (see multitier and model-view-controller), a .NET application runs only on platforms with the .NET framework.
If your application uses a C++ back-end (for portability) and a .NET front-end, it won't even run. As soon as an app running on Windows Phone 7 tries to P/Invoke or otherwise execute code that isn't verifiably type-safe, it gets a security exception. C++/CLI exists, but the syntax of its verifiably type-safe subset is incompatible with standard C++.
I like it. 2GHz dual-core DX10 phones with 2GB RAM and a uSD slot for another 128G, 4.5" AMOLED screens and 1080p HDMI out? All I need now is to find a table at the Starbucks with the Bluetooth keyboard and mouse, and the 21" display, and I'm rockin.
Don't forget the fanny pack to hold the battery that powers all this for more than an hour per charge.
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
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..."
Support my political activism on Patreon.
Why would we assume that Microsoft and Intel would part company? ARM out-performs Intel in terms of power consumption, but Intel out-performs ARM in terms of processing power. While it seems that Intel may wind up with a smaller portion of pie, the need for desktop computers will continue for a long time. I don't think we will be seeing these competing options "pushing the two technology giants to go their separate ways" in the near future.
seriously, why is this news? yes, naifs out there associate OS stacks with particular hardware platforms, but the people _inside_ software companies don't. msft has produced extensive app stacks for ppc before, even to some extent mips and alpha. current windows is derived through NT and NT OS/2 from a codebase that was _originally_ developed simultaneously on MIPS and x86. obviously for devices like phones and tablets, even a lot of desktops, there's no need to worry about externally-provided add-in cards and the driver complexities that introduces.
besides, who cares that much about native apps anymore? "appliancy" stuff is browser/flash/java-based. msft itself is probably the main purveyor of non-browser/flash/java stuff, and of course they can retarget their office suite, no sweat (hah).
the interesting question in this is whether there's really any reason for ARM to be more mobile-friendly - that is, what is it about the ISA or implementation that makes it _inherently_ better (if any). my suspicion is that it's mostly a matter of methodology or culture: ARM has traditionally been very parsimonious (think hybrid or high-efficiency car), and the x86 makers have traditionally been more Nascar. Intel seemed to have done Atom almost against its will or corporate culture - followons have been more power-efficient, but they hardly seem like significant, bet-the-company efforts. AMD's recent bobcat-based chips appear to be based on a modestly-tweaked version of the K8. maybe what distinguishes ARM is something simple, like a compact instruction encoding...
Yeah, the other issue is that ARM code is "bigger" but somehow a 900MHz ARM outruns a 1500MHz x86
Cite? You're not begging the question, are you?
I'll go further - you're full of shit. Please find me the ARM chip that outruns (performance-wise, unless you mean something else by "why so much faster") the Core i7-680UM (a 1.47GHz x86 chip), even on a core to core basis.
I won't hold my breath.
The main reason people are still using Windows on their systems today is because of all the apps and hardware that Wintel supports. As soon as the first ARM based Windows devices come out for consumers there will be a huge amount of people complaining that there programs or drivers don't work. Even today this comes up, I've seen people not understand that Office 2007 won't work with Windows 98. All they saw on the box was that "Windows" was supported. While Microsoft will be able to get some companies to port many won't and those that do will require users to buy a new version.