The author is an idiot
For Apple to make an atom version of OSX they just use a the -mcpu=atom flag to gcc instead of the -mcpu=arm one they use for the current version.
No emulation needed.
An Intel executive has apparently claimed a future iPhone will be based upon the chip giant's Atom processor. Speaking in Germany, one Hannes Schwaderer, Intel's MD for Central Europe, made the claim, according to a German-language ZDNet report. Sachwderer also promised a raft of Atom-based devices in the next 12 months, all …
From the story:
"Emulation would be essential to allow Apple to carry forward all the third-party development work done on iPhone software up to that point."
By the time this thing appears - if it appears - there'll be a lot of third-party ARM binaries out there that won't necessarily get recompiled but which users will expect to continue to run.
If it was a simple as these guys say, we'd never have needed 680x0 emulation and, later, PowerPC emulation in Macs. Or Dragonball emulation in ARM-based Palm devices, etc, etc.
I see no reason for Apple to move iPhone or other similar devices to Atom. ARM chips at the same processing power are generally cheaper, less power hungry and more integrated.
The only reasons I an see would be non-technical, such as Intel offering Atom at vastly reduced prices to Apple in an attempt to limit competition from ARM -- and that would be of questionable legality.
macrumors seem to be going with the idea that it'll be a 3rd type of iphone device, more like a tablet, using the current Atom chip:
http://www.macrumors.com/2008/05/14/intel-confirms-atom-based-larger-iphone-mini-tablet/
sounds like the device would be about twice the size of an iphone - if it allowed me to screen share and control my macmini that is wired up to the tv, that would be ideal for me
but then again - with the sold-out WWDC due in just a couple of weeks, i'm expecting we'll see a lot of stories all over the web trying to guess at what will be annouced
I had understood that the "emulator" that comes with the iPhone SDK isn't an emulator at all, really - it runs x86 code, not ARM code. To run under the "emulator", code has to be compiled to target the x86 architecture. Can anybody correct me on that? I've always thought this was a questionable idea; you're debugging your code on a completely different architecture to that on which it will eventually be running.
I don't know whether there exists a suitable ARM emulator for x86 that would provide acceptable performance on a future Atom-based iPhone, but it seems to me that making that work would pose some challenges. The most feasible option seems to me to be some kind of translator that would convert ARM to x86 binaries as a one-off operation at install time, for example.
There's already a denial by Intel that the exec meant it was going to power the next iPhone:
http://www.zdnet.de/news/hardware/0,39023109,39190870,00.htm
If the article's quote here is correct then I don't really see how he said that the next iPhone would be Atom-powered anyway, the Reg article states:
"Sachwderer also promised a raft of Atom-based devices in the next 12 months, all of them "a bit bigger than the iPhone"."
How is something that is described as "a bit bigger than the iPhone" the same as "the next iPhone"? That could mean a whole range of potential products all of which are seen as 'bigger' (i.e. better) than the iPhone, or it could just mean (and yes, I'm being slightly facetious here) a range of devices that are literally just a bit bigger than the iPhone in terms of physical dimensions. Neither of those implies that these devices would be an Apple iPhone.
If the quote in the Reg article is accurate then it's a huge leap to claim that the exec was genuinely claiming that Intel had signed a deal with Apple such that Atom chips are powering the next iPhone.
Obviously if there's more to the original ZDnet article then fair enough, but from what the Reg has printed there is no way the article headline makes sense to me.
Apple went with Intel for Mac stuff because IBM said "fuck off, we're too busy with orders for PowerPC and Cell" and not because it was the better architecture. Intel said "Of course, your Jobness and we'll also do the motherboard design and help you with the ASICs so we can both bask in the media hype".
Intel doesn't and, since it sold the XScale business, probably never will do SoC for mobile phones and that's what the market is which is why the iBrick is ARM. Most of the mobile phone stack is pretty hardware specific which is why a cross-compile doesn't really cut it and why emulation isn't an option. Not sure how ARM versus Intel shapes up in the small device world: Nokia's tablet thing versus the EEE but that's certainly somewhere the Cupertino junkies will want to be. ARM is by far the better architecture on a bangs per buck base but Intel have the best process engineers who will wring every ounce of performance out of the hardware. Be fun to watch and it will probably be very nice kit but I for one would love to see Apple embrace ARM - 20 hours battery life for a MacBook ARM? You bet.
Apple has had a very long history with ARM. Longer than their history with Motorola, IBM, MOS or WDC, actually.
One of the reasons that Acorn Computer spun their ARM development off to a separate company was because of Apple's involvement during the pre-design phase of their Newton handheld. It was a huge boost to Acorn to see Apple as a customer.
Of course, Apple has no loyalty to any given processor manufacturer. We've seen this before. I guess if Intel made the deal sweet enough, it might happen.
As others have pointed out, Intel has already denied this, but nevertheless another thing that shows it makes no sense is the assumption that the ARM chips will just sit still waiting for the Intel Atom chips to catch up. If the Atom chips have finally achieved the same heat/power characteristics as the ARM chips by 2009/2010, won't the ARM chips have done even better in the interim? I guess it's possible that there are other considerations, such as x86 compatibility, Intel's marketing clout etc, but heat/power are very important for a small mobile device.
By the time Intel get x86 down to current ARM power levels, ARM would have moved on to the next level. x86 will always be playing catchup in this space.
As another poster said, most software porting is a matter of setting compiler flags. It is not the software that is keeping designed committed to ARM, it is the fact that ARM uses less power to do the same job.
These days most higher-level software is close to being CPU agnostic: Linux, BSD etc. That's why Ubuntu can roll out an ARM version with a bit of effort.
Most x86 lock-in is forced by Windows. Anyone rolling out portable x86 systems (including EEPC and OLPC) are doing this so that they could keep the door open to run Windows. If these devices were ARM based, you could have better battery life (or smaller batteries), simpler circuit boards (less power being converted, higher chip function densities) and less cost.