Slashdot Mirror
ARM Hopes To Lure Microsoft Away From Intel
Steve Kerrison writes "With the explosion of netbooks now available, the line between PC and mobile phone is becoming much less distinct. ARM, one of the biggest companies behind CPU architectures for mobile phones (and other embedded systems), sees now as an opportunity to break out of mobiles and give Intel a run for its money. HEXUS.channel quizzes Bob Morris, ARM's director of mobile computing, on how it plans to achieve such a herculean task. Right now, ARM's pushing Android as the OS that's synonymous with the mobile Internet. But it's not simply going to ignore Microsoft: 'What if Microsoft offered a full version of Windows (as opposed to Windows Mobile or Windows CE) that used the ARM, rather than X86 (Intel and AMD) instruction set? Then it would be a straight hardware fight with Intel, in which ARM hopes its low power, low price processors will have an advantage.'"
You will kneel before Z80!
Mac users have had to endure 2 processor family changes and finally had to settle for the same one the PC uses. Could you imagine the irony if the PC switched to ARM and the Mac was left using the "outdated" x86 architecture?
The article is nothing but FUD. They base the relationship of Microsoft and Intel cooling on a comment an Intel employee made at a trade show that some Microsoft employees in the next booth overheard and said "Hey, we're listening."
This is just another crappy article that is spread over a bazillion pages when one when would do so they can push their advertisers.
"What if Microsoft switched to ARM?"
"What if Count Chocula and the Cookie Monster teamed up kidnapped the Keibler Elves? What if monkey's flew out of Cowboy Neil's butt? What is Megan Fox showed up naked at my front door with Natalie Portman covered in grits?"
Its about the same comparison.
^Apple didn't suddenly port Mac OSX to x86. Both versions had been in development since OSX's inception so Apple could keep its options open if the PPC roadmap didn't unfold to their liking. It didn't, so they exercized the option.
Look at how quickly Apple ported Mac OS to Intel.
Apple maintained an internal cross platform port.
Exactly. A few people want to run Windows, but most don't care. What they do want is to run Windows apps. A port of Windows wouldn't be a straight hardware fight with Intel. Windows NT ran on Alpha and was a lot faster (and not much more expensive) than anything Intel had to offer, but all of the apps were emulated x86 apps, which ran slower than native apps on Intel chips.
The CLR helps a lot here. A .NET app isn't a native app anywhere, so it's a level playing field. Except that there are very few real .NET apps; they all include a load of native DLLs and unfortunately these are very often in performance-critical code.
I am TheRaven on Soylent News
When Apple switched from Motorola 680x0 to PowerPC processors in 1994, they built an emulator into the operating system to allow m68k code to run transparently on the new platform. In fact, they didn't even port the entire operating system itself; bits and pieces of it ran under emulation for years as Apple gradually finished porting it all.
In addition, they created an easy way for applications to be compiled natively for BOTH architectures at the same time, and encouraged application developers to release fat binary versions of their apps. This worked so well that the majority of users weren't even aware that the PowerPC was a completely new incompatible architecture, as opposed to simply a new faster version of what they'd always had.
When Apple switched CPU architectures again, they mostly duplicated this success. Some applications and drivers aren't compatible with Rosetta (the PowerPC emulator), and it's not possible to use a plugin compiled for one processor in an application compiled for another, but Apple's own developer tools offered a simple checkbox to recompile an app as a Universal Binary, and most developers have moved away from third-party compilers.
Microsoft does have x86 emulation technology that they bought from Connectix a few years ago, but they have no experience getting applications to work transparently across dissimilar architectures, and moving from a faster Intel CPU to a slower ARM CPU makes emulation pretty unappealing anyway. Look at what a pain in the ass it is just to get everything to work on a 64-bit version of Windows!
Mac developers are accustomed to following Apple's spontaneous whims, because users consistently reward them with big piles of cash, but Windows developers have a lot less incentive to play ball by releasing native applications for a platform that doesn't exist yet, has no users, and seems unlikely to get users because there is no native software. If they can make the emulation work perfectly, then they might get some users, and if they have users, some developers will start porting their apps. You'll never get all of them, of course, but the ones most people use every day will probably have ARM-native versions introduced. Also, pure .Net applications should work perfectly out-of-the-box. Microsoft wouldn't use a universal binary architecture like Mac OS X; since virtually all Windows applications require an installer and you can't easily move an app from one computer to another without reinstalling it from scratch, there's no reason to do that.
In contrast, Apple could announce a new ARM-based Mac netbook tomorrow, and a majority of developers would have native applications ready to go in six months.
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
Take yourself a little less seriously for 5 minutes, and try to come up with a credible scenario in which MS can fuck ARM over. Remember for those 5 minutes that TFA refers to CPU architectures. Try to resist MS-bashing just long enough to stay on topic..
In any case, let me address a bit of that garbage you spewed:
That leaves you with 2 out 10. It's still pretty damning, but it's even more damning that 8 out of 10 of your accusations have no basis. So I repeat, stop taking yourself so seriously. Try seeing past the dogma for 5 mins, so you can respond with something related to the article itself rather than this off-topic drivel.
ARM had a bigger problem holding it back from Windows than raw speed -- RAM. It's dirt cheap on a PC, but hideously expensive on microcontrollers -- the universe where ARM dominates --
Is a ARM11 based Freescale i.MX31 with all its stuff onboard a microcontroller? Is a PIC16F88 a microcontroller? What do these two devices have in common. Really, almost nothing at all.
It really sounds like you're not considering the application space for ARMs at all. Except for some ARM7 stuff, an ARM core is much more capable of running software with a 256KB working set. The applications being discussed (netbooks, PDAs) couldn't do anything useful with 256KB no matter what the architecture.
Almost all modern ARM cores are implemented along with an SDRAM controller, which in many cases will support DDR2. This is the exact same RAM used in many PCs and since this is a commodity its trading price will be exactly the same. Obviously the unit cost for raw DRAM chips will be lower than that for a DIMM stick from Newegg. So really, no, there is no reason why RAM is any more costly for these "microcontrollers" as you call them.
Also realize that onboard memory for these devices is typically SRAM and in some ways acts like an L2 cache for these devices. The per-bit cost is many times that of DRAM. Since, DRAM is cheap and the controller is builtin, the cost of memory for these ARM "microcontrollers" is just as cheap as PC RAM, because it is PC RAM. You are simply wrong.
Even in a number of somewhat embedded applications, the cost issue in an ARM based platform will generally not be constrained by RAM prices, but by Flash prices. In most applications that require the horsepower of a ARM9, the use of a non upgradeable components is very limited, so these systems WILL have Flash. It is quite common to design a system with 16MB of RAM and 1MB of Flash with a total unit cost of sales of $20. (The ARM MCUs are in the $4-6 range in modest ~1000 quantities)
Probably not identical, but nothing like the difference between x86 and M68k, or x86 and ARM. Multiple sources means you can get away with Just-in-Time supply-chain management,
I really question your background in this area. This is just not true. In fact it is quite wrong. Despite all the problems with PCs, there is more standardization with ACPI, PCI, and x86 then there is with anything ARM based.
How many sources are there for a Samsung S3C2442: 1
i.MX31: 1
Marvell PXA320: 1
If you had a complete custom embedded system based on the peripherals of one of these and you had to create a new driver set from scratch, how long would it take? Let me tell you from first hand experience that it is not a weekend project.
The only thing that those three examples have in common is *some* of the instruction set architecture (not even the cores are the same--in fact, actually the ISA diverges in a number of non-fundamental ways). And even if they had identical cores, that is not a complete system. Merely an important part.
If you really think if you have a hardware and software design with say a Freescale ARM based device and you can just drop-in a PXA320 and be done in a couple weeks, you are smoking something, or really don't know how much has to be accomplished in that couple weeks.
The reason that we get away with these single sourced components is because we are relatively certain that if Motorola or Intel decides to get out of the business, the product is still enough of a cash machine that other companies will spin-off or buy it (eg Freescale and Marvell) and in reality there are usually contractual agreements and last-time-buys and a number of economic considerations that a major manufacturer goes through. It has nothing to do with any (nonexistent) technical uniformity in the ARM core based MPU/MCU industry. Nothing at all.
Trust me, I do low-cost embedded systems design for a living, and most of what you say just doesn't make sense.
Having developed 386SX based industrial systems in the early 90s, if you think some SoC with 386SX hardware has anything to do with ARM's roadmap, you really don't know a thing about either.