Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

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.'"

Compatibility layers are much different than emulation. To run a DOS/Windows 3.1/Win 95/etc. program in Windows 7 all you need is the old libraries. I assume the x86-64 instruction set includes stuff to make x86 emulation faster. My guess is that emulation x86 on an ARM processor is nowhere near fast (otherwise they'd just always run them in emulation mode and compete with the Intel Atom and Via Nano).

I must admit, personally I'd have a preference for x86, because of compatability with PCs (which I will always prefer as a platform over locked down phones), but it's not like ARM are some niche player here.

Compatability? I thought we used.net these days in Windows.
Why are we using a VM if the code isn't portable?

To have managed memory. It takes a lot to track pointers, more than a hack on to existing x86 can manage (libgc tries, quite well, but it isn't perfect).

Yes, I'm being completely serious.

However,.NET is apparently portable across architectures, as Portable.NET supports several.

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.

And does ARM actually make a desktop-class CPU (as compared to Intel/AMD's mid or high end cpu's)?

ARM CPUs are advancing faster than x86 CPUs.

The Cortex A8 has roughly P3 performance (per clock), and clock speeds varying from 600-1000mhz. This is without Out of Order execution, 64bit support, or any other fancy stuff. The power envelope is about 50 milliwatts load. Most SoCs bundling GPU, DSP, LCD controller, wifi, etc. consume around or under a watt.

The Cortex A9 should be significantly faster. If I recall correctly, it has OoOe and sports a 2-4 core multicore architecture, with increased clockspeeds, in the same power envelope. Look up TI's OMAP4 SoCs. When these are released in 2010, we'll have Pentium D/GeForce 6600 level performance using up a hundred or so milliwatts, and generating a completely negligible amount of heat.

How on earth is something that slow supposed to handle the behemoth that is Windows Vista? Even with a 3000 megahertz P4, my brother's machine runs like a snail. I don't see an ARM processor with about 1/6th the power working well with Vista, unless you enjoy watching your programs operate in slow motion.

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 Vis

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.

Heh... In the case of your laptop and netbook, the odds are good you don't have the power management turned on or turned up much. Stock configs for Linux leave that turned off. Windows turns it on and you deal with it or turn it off after the fact. Without the power management, it eats batteries like candy.

Now... To put this in a perspective you and others can clearly understand:

The netbooks we're about to see from ARM licensees are roughly in the same ballpark of performance and capacity (depending on RAM included with the devices...) of the eeePC when it first came out to the 900 series devices.

The Intel based devices for these models needed a 49 watt-hour battery to do 3 or so hours runtime, whether you're talking Linux or WindowsXP.

The OMAP3 boards I've had the fortune of having in my possession at one point in time were able to go roughly 10 hours...on a 13.5 watt-hour battery. While I've not abused it as much as others, some were not letting it just set idle- it did these amazing runtimes with emulators running full-tilt. It'd probably get approximately 8-ish in the same configuration if you had the 3D accel running.

Oh... By the way... That was without any power management- not that it'd been kicking in with what they did to it.

This is using the Cortex-A8. The A9, is out-of-order plus SMP capable, and has a few other gems going for it. It's like having 1-4 of the pre-Core P4M devices at the same rated clock speed as the ARM based SoC- and consuming only slightly more juice per core than the A8. That's NEXT year's crop of fun from ARM.

I've looked at BeagleBoard and some other TI OMAP3 board specs. They all have PowerVR video/3D accelerator, which does not have any open-source drivers. And I'm not even sure about closed source ones. These boards lose 90% of their cool without them.

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 o

Flash is pretty inefficient, but it does run (admittedly not great) on the N810 [wikipedia.org] which has a 400MHz ARM processor, which is a generation behind the Cortex A8s, so a Cortex A8 should have no real trouble with Flash.

I hope some non-Adobe Flash implementation is ready for real use soon as the only possible reason for Flash to be as slow as it is is that Adobe must not care at all about its speed.

But it wouldn't be a straight fight between ARM and Intel. It would be a fight between ARM, StrongARM, Asynchronous ARM (yes, there really is an asynchronous CPU based on the ARM core), and every other ARM variant out there.

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?

Apple already ships a huge number of OS X machines with ARM chips, they just brand them as iPhones and iPod Touches. OS X makes it easy to add another architecture for fat binaries and most OS X apps have already been ported from PowerPC to x86 so have no CPU dependencies; porting them to ARM would be relatively easy. That said, since Apple bought PA Semi, I wouldn't be entirely surprised if they released a PowerPC chip that competed in the same area as ARM.

It uses the same kernel. It uses the same CoreGraphics, Foundation, and CoreAnimation frameworks as well as countless others. About the only difference is that OS X on the iPhone does not have AppKit or Autozone.

Windows on ARM would be as pointless as every other port Microsoft has tried and eventually killed off. And for the same reason, lack of applications.

Microsoft itself has never bothered porting any of their consumer apps such as Office. Remember DEC having to use FX!32 to get Office running via emulation at a fraction of native speed... leading customers to fail to see the advantage of the Alpha. Now we are to expect the hundreds of large and small shops making the Windows apps people associate with "Windows" to all port to a platform where there are no suitable developer workstations available and Windows development tools lack much in the way of cross compiler support.

Compare to Linux on ARM where pretty much the entire Debian/Ubuntu collection is up and running and Adobe has ported the one key closed piece, Flash Player.

> Remember DEC having to use FX!32 to get Office running via emulation at a fraction of native speed

I'm assuming by fraction you mean somewhere between.9 and 1.1. Yes, if you had some ancient, assed-out Multia running at 166MHz you weren'tgoing to be happy compared to a then-smoking 450MHz P3. However, at the same time Intel was stuck around 450MHz, Digital was cranking theirprocessors to much higher clock speeds.

P.S. Word and Excel had native AXP ports. You were stuck using FX!32 to run Outlook, bu

I'm assuming by fraction you mean somewhere between.9 and 1.1. Yes, if you had some ancient, assed-out Multia running at 166MHz you weren't going to be happy compared to a then-smoking 450MHz P3. However, at the same time Intel was stuck around 450MHz, Digital was cranking their processors to much higher clock speeds.

Except the example you use is of a more powerful server or workstation-class behemoth trying to run x86 desktop/notebook class software. That's doable and probably quite useful. But here, we'

Windows on ARM would be as pointless as every other port Microsoft has tried and eventually killed off. And for the same reason, lack of applications.

Microsoft itself has never bothered porting any of their consumer apps such as Office. Remember DEC having to use FX!32 to get Office running via emulation at a fraction of native speed... leading customers to fail to see the advantage of the Alpha. Now we are to expect the hundreds of large and small shops making the Windows apps people associate with "Windows" to all port to a platform where there are no suitable developer workstations available and Windows development tools lack much in the way of cross compiler support.

Compare to Linux on ARM where pretty much the entire Debian/Ubuntu collection is up and running and Adobe has ported the one key closed piece, Flash Player.

With.NET getting more popular, maybe now (or at least the near future) this will be less of an issue?

> 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.

That's the really nice thing on Linux. You can recompile nearly all of your 13745 applications (current Gentoo Portage app count) for ARM, and do everything you want. Firefox, Amarok, VLC, OpenOffice, you name it...

Don't even bother trying to make a deal with the devil. The rotting corpses of the scores of companies screwed over through their dealings with Microsoft line the landscape of the past decades tech industry. Instead, make them come to you and don't make any deals with them either. If ARM based netbooks start becoming a huge commodity, Microsoft is going to have to port a version of Windows to run on ARM processors or they'll end up missing out on sales.

It would probably make a great deal of sense for Microsoft to work on this as well as it would most certainly help out their ailing phone technologies as well. They'd probably rather that ARM-based netbooks not take off in the market, but if they were to do so, Microsoft wouldn't be able to ignore them. I wouldn't bother making any plans with them at this point; they'd only find some way to fuck you over.

Microsoft fucked-over IBM when they suddenly decided to develop Windows 3 as their main OS, instead of sticking with the original OS/2 agreement. For the rest of this post, I'll just quote wikipedia because it saves typing effort:

"The majority of criticism has been for its business tactics, often described with the motto "embrace, extend and extinguish". Microsoft initially Embraces a competing standard or product, then Extends it to produce their own version which is incompatible, which in time Extin

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..

You don't think Active-X was simply a plugin architecture? Why do you suppose other browsers have plugin architectures? All of them are trying to break compatibility with each other???

"Microsoft put pressure on AOL to make its IM networks ** interoperable ** with competing instant messaging services, an outcome that eroded AOL's market leadership."What exactly are you complaining about here???

"A decade after the original Netscape-related antitrust suit, the web browser company Opera Software filed an antitrust complaint against Microsoft with the European Union"Find me a 100% standards-complaint browser, I'll show you a software maker who has a right to complain. Opera and Safari do a better job than most, but nobody is 100% compliant.

Spreadsheet non-conformance with ODF standards" -- ODF 1.0 and 1.1 do not support formulas. The result? All ODF spreadsheet implementations are application dependant. See here [msdn.com] for detials. Note MS's complete transparency in the implementation process.

"Apple Inc., Mozilla Foundation, and Opera Software formed the Web Hypertext Application Technology Working Group to create open standards. Microsoft has so far refused to join."See here [wikipedia.org]: (Chris Wilson of Microsoft was invited but did not join, citing the lack of a patent policy to ensure all specifications can be implemented on a royalty-free basis.) - What, again, was your objection?? Also note - WHATWG was formed to accelerate standards creation - not to avoid browser war incompatibilities as you claim.

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.

Talking to someone who is in love with Microsoft, is like trying to convince a girl not to marry her abusive boyfriend. Nigh-impossible. You sir are an apologist trying to defend actions that are not defensible. (Similar to how the record companies' actiosn to fix CD prices at $12 were indefensible, and eventually led to a U.S. FTC lawsuit.)

As for ARM -

Microsoft could screw them the same way the screwed PowerPC Mac owners. Sign an agreement to develop the software, do it for five years and gradually win

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?"

"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?"

I find your thoughts intriguing and wish to subscribe to your newsletter!

It's probably a lot easier to convince application makers to port their application from Windows (x86) to Windows (ARM) than from Windows (x86) to Linux (x86). There's a pretty good chance that switching architectures for most applications just requires a recompile, like porting from x86 to amd64. It's not always that simple, but in this case you'll still have all your Win32 APIs available, whereas porting to Linux will often times mean rewriting the whole thing in GTK or QT.

Someone here is ignoring one of the biggest draw of Windows. People can run *their programs* on Windows. They wont be able to do that with Windows on ARM. Then they might as well be running Chrome OS or some other variant of Linux. At least with most variants of Linux they'll have huge selection of software that runs on ARM.

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.

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

Hardware x86 was dropped from Itanium when Itanium 2 came out, from then on it's a software emulator. So if your ZX6000 has an older Itanium processor then it probably has the x86 hardware on the chip.

NT was originally designed to be portable. Whether that has been retained since the abandonment of support for Alphas and PowerPCs is something I couldn't say. However, it wasn't an insurmountable effort to port other operating systems like Linux over to new infrastructures, so I doubt it would be that horrifying awful for Microsoft. In fact, I'd be damned surprised if Microsoft, like Apple before it, didn't have some resources quietly working on it.

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 abstrac

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.

If Microsoft does again decide to start pushing portable multi-platform versions of Windows, then I guess Microsoft developers are just going to have to learn what folks who develop for other operating systems have done for decades; and that is how to construct directives and a proper makefile, or move to.Net or Java. Microsoft has obviously wanted to push developers away from native compilation for a few years now, but let's face it, there's still a helluva lot of Windows software being pumped out that's

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.

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: 1i.MX31: 1Marvell 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.

A binary translator would be used to dynamically recompile x86 code as ARM code, taking care of "legacy" x86 applications. Only the OS kernel would need to be native. Eventually, software makers would produce Mac-style "fat binaries" with support for both architectures, but the binary translator would be used in the meantime.

In the *best* case, you could expect performance on your ARM netbook similar to running PPC code on an Intel Mac. However, if you could run your desktop apps on an ARM, natively or with

Digital made the best binary translator ever made (FX!32), it didn't help the adoption of NT/Alpha despite the fact that Alpha was about twice as fast as the fastest PPro available at the time. Now you think that people are going to run an alternative processor that's several times slower just to get somewhat better battery life? You have got to be joking.

Most of windows is probably written in C/C++ or C# by now, so I'd say its pretty portable that way anyway. All the major APIs have been recently re-written recently, and moving to a new architecture would allow them to drop a lot of legacy x86 shit... I'd hazard a guess that Microsoft has Windows running on various other platforms in some way internally already. They'd be stupid not to.

Actually it's kind of true. And that's only part of the reason that this is a good idea (for Microsoft).

AFAIK (and I don't know much) - ARM chips don't require a translation layer that converts machine code to microcode - and this results in huge efficiency gains (compared to x86/x64 chips). If that's the case (second disclaimer - I don't know much about this so I could be wrong) - but if that's the case, the future of laptops/netbooks/mobile devices/perhaps even datacenters probably has ARM in it somewhe

If they keep it to netbooks (most don't have optical drives), then they'd ostensibly create a windows market of sorts that contains only ARM-compiled apps. Get enough ARMbooks in the wild, and the vendors will just make fat binaries for both arches.

Get enough ARMbooks in the wild, and the vendors will just make fat binaries for both arches.

Yeah...

Imagine, for a moment, that some people would buy a netbook with no third party software; they just use Microsoft products (assuming MS ports more than just the OS). Are those the people who are going to buy enough software to create a viable market? After all, if they wanted third party software, they probably would have gone with an x86 to begin with.

Well they've been selling Linux netbooks. Remember that lots of people are buying these to access the Internet, and not to run general applications. An ARM Windows netbook won't have the disadvantages of unfamiliarity, or people who insist on Windows because that's all they know. It'll also be much easier to port apps to it from x86 Windows, than to Linux.

Porting isn't THAT huge of a deal. Very low level libraries would need to be ported and compilers and the kernel, but everything above that usually isn't that huge of a deal. Modern OS's are pretty darn abstracted. Look at how quickly Apple ported Mac OS to Intel.

^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.

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?

MS could use the transition to marginalize Windows application competitors unwilling or lacking resources to support the ARM version of Windows. For the most part that process was completed with the transition from DOS to Windows (bye WP and Lotus 123).

Does it Freeze, lock up, blue screen, crash & reboot like a full windows OS too?

Where is this freezing, locking, BSODing, crashing, and rebooting Windows OS that you speak of? Aside from a few driver conflict issues, I haven't had many problems since Win2k (and XP). I have yet to have a Windows issue on Vista x64 and Windows 7, actually... although I still really didn't like Vista at all.

Disclaimer: No, I am not a Windows fanboy. Yes, I run Linux. I work with AIX, HPUX, Solaris, Windows, and Linux as my day job. I don't like Macs out of principle.

Was it Linus who said that Microsoft hating was a disease? I am a Linux user at home. I'm not much of a fan for Windows XP and I loath the Vista user interface. Windows 7 actually has me a little excited. And all of these are stable systems. The benefit to Windows XP being around for so long is that Microsoft had a long time to make it stable. I haven't had a blue screen of death on Windows in years. It's time for people to move on from knocking Windows for instability. It just makes them look like lackeys.

I've stuck with Intel motherboards, intel CPUs and Nvidia video for the past 6 years, and the only blue screen i have seen in that time (on my desktop, don't get me started on the BIOS and driver issues on my P.O.S. Dell E6400 under Vista) was due to faulty RAM.

But again, blue screens on the E6400 are Dell's fault. As proven by them coming and going with various BIOS and driver updates.

It's pretty hard to blame the OS for a game lockup. In most cases it's the graphics driver getting woefully confused and eating it, resulting in a hard lock, or the game just wedging (if you could get the processor time to switch out you could kill the process, but often you can't--this happens in Linux gaming, what little there is of it, too).

I used Vista x64. No problems with Oblivion, one of th few games I do play. Maybe it was a hrdware or driver issue, I don't know. Hooray for two conflicting anecdotal evidences!... hehe.

Windows 7 seems much smoother, so far, than Vista - even though I just said I didn't have too many issues with Vista, hehe. I've run some pretty old programs on it with no problems. If you do use Windows, I'd actually recommend it. Oblivion "has issues," according to MS - which I think is an alt-tab issue - but it han

We've never been at a point where we could run a full OS in a mobile profile.

What's your definition of "a full OS"? Presumably you're not counting iPhone OS, even though it's based on much of the same core OS code that Mac OS X is based on (heck, jailbreak it and you can even get a terminal emulator with a shell prompt). (I don't know whether the rumored Nokia N900 would be a phone or not, or whether it'll be Maemo-based.)

Only five years ago, people would have laughed at the idea of music and video on computers

I'm guessing the OP meant to say "on phones", not "on computers".

Even on phones, I doubt people would have been laughed at the idea five years ago. Remember that the Motorola Rokr (the iTunes compatible phone) was out almost four years ago, and it's not like playing MP3s on your phone seemed such a big deal even then.

Ten years ago, perhaps. It's almost exactly 10 years since Napster arrived, and most people at that time hadn't even heard of- let alone listened to- MP3s. The first style/youth-oriented phone, the Nokia 3210, had only just arrived as well, offering (*gasp

It depends, except for the stupidity of app "approvals" the iPhone is pretty much a perfect phone and runs a pretty high level OS which is basically Mac OS X ported for ARM minus the GUI. The difference is the applications. If I have Linux on my phone I can run a -ton- of applications even with almost no commercial support (see the GP2x) because most apps are OSS. On the other hand Windows will fail because of the fact that it relies so much on proprietary software. ARM CPUs aren't fast enough for emulation

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 wit