ARM Hopes To Lure Microsoft Away From Intel 333
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.'"
Re:Dream on (Score:3, Interesting)
JVM/CLR (Score:3, Interesting)
The problem isn't the OS, it's the software for the OS. On Linux, you port the kernel, and then simply rebuild your distro (fixing portability bugs in the process relatively rarely). Job done. On Windows, you need mom & pop go to the car boot sale, buy Knitting Extravaganza 4.0, and still have it install/run successfully.
I think this is the whole reason why microsoft is pushing dot-net and higher-level languages -- not because they care about the languages so much, but because they care about abstracting the windows platform away from PCs until a virtual machine, like Java has been doing for years. Whether Windows, OS X, Linux, or something else wins the desktop wars, Java will survive. Microsoft wants to survive that loss too.
Re:Good way to enter the market (Score:3, Interesting)
I don't even want to know what ix86 emulation on ARM is like...
Well, it was ok for light use in 1988 [chriswhy.co.uk] (NB: PDF file, parent page is here [chriswhy.co.uk]). That was back in the day when ARM was pitched as a high-performance workstation chip rather than a low-power option.
Seriously, though, the windows back-catalogue might not run on ARM, but the .NET framework is MS's preferred platform for new apps, and that is VM-based and supposed to be CPU independent, is it not?
Re:Make MS come to you (Score:3, Interesting)
Do you mean, like they fucked Intel over on IA32/IA64?
Or the way they fucked Alpha over (when NT used to run on that arch.)?
Oh that's right -- they didn't!
And for that drivel you wrote to be ranked +3 Insightful just goes to show how worthless this site has become.
Re:Full Windows on a phone? (Score:4, Interesting)
Applications? (Score:5, Interesting)
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 [wikipedia.org] 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.
Re:ARM? x86? (Score:2, Interesting)
Re:Applications are the problem (Score:4, Interesting)
> With .NET getting more popular, maybe now (or at least the near future) this will be less of an issue?
I'm old enough to remember when people said these silly things about Java. No it won't help much. As someone else in this topic has already noted most non-trivial .net apps use native .dlls to make up for the performance problem with .net. Just like Java did. Then there is the problem that while Microsoft has spent oddles optimizing the compiler and virtual machine to perform fairly well on x86 it is doubtful much effort will be expended on ARM. Again Java is the reference model except Sun did make Sparc a first class Java platform along with x86.
But finally there is the bigger question, just how many application domains are even suitable for .net? Anyone expecting games (not counting little cellphone suitable stuff) to EVER be released as managed code will grow old and die waiting. Tier one applications will also be unlikely to forego the performance advantages of native code. Adobe won't be releasing Creative Suite on .net. And don't expect Microsoft to eat their own dogfood anytime soon with IE or Office.
And since I'm posting a followup anyway I forgot one other point in my assertion that few 3rd party ISVs would bother with ARM. Windows is mostly a platform for commercial applications and shareware. This means they expect to have people actually pay money for applications, usually a pretty nice price. What market segment is ARM netbooks targeting? $300 will likely be the high water mark this Xmas, never to be seen again as by Xmas '10 the ever lowering price tags will have moved down again. How many copies of Creative Suite would Adobe expect to sell? Even Intuit would probably be dubious as to how many units of Quickbooks they would move to such price sensitive customers.
Note, I believe the ARM advantage is more than price but doubt the market will realize that anytime soon and produce my dream machine. I want a replacement for my Thinkpad X31. Something with a 12" widescreen with at least 1280x720 resolution, 2 GB ram, 32 or 64GB of SSD and with the ARM enough staying power to run all day (12+ hours at least) while still being lighter than the X31.
Re:That's pretty amazing... (Score:2, Interesting)
He's still wrong - I'm pretty sure mp3 phones were around before 5 years ago, and it was also around 2004 that companies were hyping viewing video on then new 3G phones.
Now 11 years ago, that's when we laughed at the idea of video on compuers [theonion.com] :)
"nothing other" (Score:2, Interesting)
When the first decent mass produced netbook -running ARM- hits the status of "blisterpack computer hanging near the checkout @ $99.95".. right next to the prepaid cellphones..I think the sales will be a lot better than "nothing other" and there will be browsers and media players and chat clients and wifi and so on, on it. Who knows, I could see a combo package, the netbook AND a cellphone in the same blisterpack.
And people will not care if it isn't microsoft, or x86, just like they don't care much today with cheaper phones. If it does some basic expected things, that's all it needs. They will sell millions of those machines. Browse, watch vids or listen to tunes, do some email, do some messaging...they'll sell. Nailing that C note is a huge marketing psychological advantage, first company there with something that doesn't suck and is "good enough" will get "*rich*. At 3-5 hundred bucks like they are today, nope, just little laptops with no DVD drive, they sell good enough, but... when netbooks crack $100...license to print money almost. More apps and developer interest will follow shortly.
Re:Applications? (Score:3, Interesting)
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.
Microsoft actually does have some experience with this. The XBox 360 is PowerPC-based, but it's able to run games from the original XBox, which was x64-based. I'm not sure, but this is quite possibly done using the very software you mentioned from Connectix.
At any rate, if Microsoft were to release an ARM port of Windows, it'd very likely be some kind of Windows Netbook Edition, and application providers would release versions of their apps for the netbook edition. It seems like the trend is largely towards smaller computers, and software companies would be stupid not to make sure they support this space too.
Re:JVM/CLR (Score:3, Interesting)
To be fair, IIRC, Alpha's x86 emulation could actually run about as fast as the fastest x86 machines back then...
But, Alpha ran at literally DOUBLE (or more) the clock speed, and had roughly equal integer IPC and better floating point IPC.
ARM has a clock speed deficit and somewhere in the same IPC ballpark as Atom, the weakest of the current x86s.
They are working on that, though. And, ARM did start out as a couple engineers at Acorn designing a custom CPU for a desktop machine, and they had one of the fastest desktop chips by a LOT when it came out. (They were gunning for the Amiga and the like, and an 8 MHz ARM2 just SLAUGHTERED the 7 MHz 68000. Yes, the 386 was about as fast at 25 MHz or so. But in 1987, a comparable 386-based machine was several times more expensive.)
I'd like to see ARM be a viable alternative to x86, but I don't think it's happening for a while. Windows is necessary, and that won't happen until ARM is fast enough to emulate x86 at near-Atom speeds. Good news is, an ARM in the Atom power envelope could probably do that.
Re:JVM/CLR (Score:4, Interesting)
> A .NET app isn't a native app anywhere, so it's a level playing field.
At least, until Intel, AMD, or somebody else adds native .CLR acceleration, kind of like ARM did with Jazelle. ;-)
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 -- and the moment you decide to add a single byte of external RAM (SRAM, PSRAM, or otherwise) to a MCU design, you've just doubled to quadrupled the system's cost. That, more than anything, is what's killing embedded Java -- the CPU and its speed are the least of anyone's problems. You can buy a cheap ARM with enough onboard SRAM to run most embedded tasks written in C(++) or assembly for under $20 in single quantities, and slap it on a board with minimal external parts & due something useful with it.
The last time I checked, the most sinfully ram-laden ARM was made by Atmel, and had a whopping 256kB of it. That's *almost* enough memory to do something trivial in Java... except if you were doing something THAT trivial, you'd do it in C and build the hardware for $20 instead of $100. I think it's safe to say that implementing hardware CLR acceleration won't be much harder/easier OR more/less resource-demanding than hardware Java acceleration... and with Java, nothing determines the system's ultimate performance and cost more than the amount of RAM it has.
I'm sure ARM will fight a hard, valiant battle, but I think they're going to have a hard enough time fighting off x86-on-a-chip microcontrollers. I think there's already a German or Israeli company that's been showing off what's essentially a single-chip 386SX PC with a meg of RAM, VGA-ish graphics, and a reference BIOS that can make SD cards look like floppies and hard drives. Trust me... THAT more than anything scares the bejesus out of ARM, even MORESO because it's not even Intel that's pushing the embedded x86 envelope the hardest (Intel's earliest x86 patents are already expiring, and Intel ALSO happens to be one of the biggest manufacturers of ARM chips.
ARM didn't become pervasive because it was the cheapest or best... it became pervasive because it was good enough, cheap enough, and available in roughly equivalent form from multiple companies. If Atmel's factory in Singapore goes up in flames, there are dozens of other foundries making ARM chips that are roughly similar. 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, instead of having to order and stockpile chips months before you're ready to start using them.
Re:ARM? x86? (Score:4, Interesting)
Mod parent up. He's the only guy in this whole tree of posts to understand mhz isn't everything.
Many ARM SoCs have co-processors called DSPs, which can help decode video. Last-generation DSPs could manage 720p/1080p, so Youtube shouldn't cause it to break a sweat.
Or if it does break a sweat, at least it won't stutter. ;)
Re:ARM? x86? (Score:3, Interesting)
I don't know - Windows 7 feels pretty snappy on an old 3.0ghz P4 I have sitting next to me. Snappier than Vista on a Q6600, actually.
Vista has a noticeable delay whenever doing anything. It's short, but it's many miliseconds slower than the P4, and many miliseconds slower than my old Athlon XP w/ Win2k.
I'm talking about stuff like opening the start menu, clicking a systemtray icon and waiting for a menu to pop up, or opening a folder and waiting for the contents to display. (this last one is horrible on Vista)
Want proof? Open your System32 folder (or equivalent, for 64bit Vista/Win7) and see how long it takes to display. After a reboot, my Win2k box takes approximately a quarter to a half second, to display in list format. The P4/Win7 box takes about a second. Vista takes about 3-4 seconds to pop up.
Why? No clue. Logically, older computers with older HDDs would take longer. Clearly Microsoft mucked something up.
Re:ARM? x86? (Score:4, Interesting)
Yes, I'm being completely serious.
However,
However, as with Java, your application is only as portable as your libraries. Take web browsers, for instance, I don't know of any rendering engines in real use that are written in a managed language. A lot of good, difficult to replace code is written in languages that aren't easy to port.
Re:ARM? x86? (Score:3, Interesting)
On such a small system, Linux really can play its cards. Full HD + Flash in browser + 10 hours of battery life + nearly no heat = $100-$200. Out this fall.
That would be nice.
The batteries of both my laptop and my netbook drain in much less time when booted into Linux, compared to booting them in XP. Especially the battery use while idle, in full powersaving mode, still seems disappointing. I'm not a noob, I've been using Linux as a server OS since the mid 90's, I'm just not entirely convinced by your claims of superiority on mobile hardware, as compared to gadgets running Windows or OSX.
Re:JVM/CLR (Score:1, Interesting)
What else is a netbook besides a computer based around a processor that is "several times slower just to get somewhat better battery life"? On my netbook, the most cpu-hungry thing I do is to watch YouTube videos, and frankly, I could easily do without YouTube entirely.
I love my netbook; it runs Fedora and occasionally Moblin, and goes everywhere I do. I'd trade it in a heartbeat for something that got the same battery life as a Kindle. If you make a small, cheap computer that will run for days on a single charge, of course people will buy it. You can even market it as a green alternative.
Take a look at the market for netbooks. Take a look at the demand for aftermarket netbook batteries with increased capacity. You have people paying as much as the rest of the hardware to have a four-hour battery instead of a three-hour battery. Battery life is a much bigger deal than processor speed.
Re:JVM/CLR (Score:4, Interesting)
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.
Open source 3D acceleration (Score:3, Interesting)
Reading these specs felt like kissing a girlfriend and then getting kicked in the groin... Especially at a time when it is becoming possible to have a 100% open-source supported hardware in desktop machines (ATI drivers started supporting new cards, lots of opensource wifi drivers are mature, etc).
--Coder
Re:Dream on (Score:1, Interesting)
Oh but I can't run $software_2_people_use! It's useless!
That's not insightful, that's a troll.