Intel preps ARM-to-x86 porting tool for iOS apps Intel has said it is developing software to make it easier to port iOS applications to other mobile operating systems - in particular, MeeGo, the mobile OS favoured by the chip giant. Doug Fisher, Intel's senior software guy, didn't say when the utility will appear, IDG reports. In an interview with the news service, Fisher …
The x86 apps will take more ROM and run more slowly than their ARM equivalent (because of ARM predication, ARM Thumb, loads of good stuff that ARM has got and x86 hasn't. Even PowerPC has these things. x86 doesn't).
The x86 will need more chippery for that extra ROM. ROMs in consumer electronics are always full, right, so the other option is to save costs by offering less functionality in the same ROM size, which will go down a treat won't it.
That extra chippery will need more power (more watts), which will be in addition to the extra wattage of x86 instead of ARM as CPU.
That extra wattage will need a bigger more expensive battery or the operating time will be shorter. Yeah, that should go down well shouldn't it.
And then there's the various ARM licencees years of experience in massively integrated low wattage high performance per watt system on chip design vs Intel's decades of experience of... high wattage abysmal performance per watt multi-chip systems, northbridge chip, southbridge chip, graphics chip...
But the equipment manufacturer gets to put an "Intel Inside" sticker on, and presumably Intel pay for half the advertising or some other "marketing incentive" like that.
So this is good for end users because?
Just remember the Dell/Intel deals, guys.
e.g.
http://www.theregister.co.uk/2010/07/26/after_the_dell_settlement/
http://www.theregister.co.uk/2010/08/04/ftc_settles_with_intel/
I hardly think ROM size is a relevant limiting factor in modern hardware, and it's power consumption is negligible. Anyway CISC CPUs tend to have better code density than RISC CPUs, which is probably why ARM decided to introduce Thumb in the first place.
Having said this, I don't disagree with you that ARM is a better architecture for low power devices. Though I see no technical reason why an x86 or AMD64 design in the same league as the ARM's power efficiency is not possible. The transistor overhead due to the extra instructions should be small at modern manufacturing scales.
GNUStep is a reimplementation of the Nextstep/Openstep API (this is the Cocoa API for OSX). According to gnustep.org::
"GNUstep provides a robust implementation of the AppKit and Foundation libraries as well as the development tools available on Cocoa, including Gorm (the InterfaceBuilder) and ProjectCenter (ProjectBuilder/Xcode)."
(This leaves out any mention of ObjectiveC, but that is supported by GCC...)
From what I've read, OSX up to 10.4 used (updated) Nextstep code for Cocoa; 10.5 has a from-scratch implementation for full 64-bit support as well as the Nextstep runtime (for compatibility? For use with 32-bit apps? I don't know). But both are compatible, so I don't think it matters which iOS uses.
Anyway.. whatever Meego is missing directly, gnustep should fill in a majority of the gaps.
It's interesting to see x86 on the wrong side of compatibility for a change... Intel had better get used to this, or forget about the mobile/netbook market altogether.
@AC: x86 (and especially x64) codesize is indeed far larger than Thumb-2, but not enough to matter for a smart phone/netbook. Flash is so cheap that needing a few GB extra is no problem, and the extra power required for this is small. Power consumption and performance (at low power) is the main thing x86 is very bad at - the latest ARM cores like Cortex-A9 thrash Atom on both. This inefficiency of x86 is not something Intel is able to work around, despite a huge advantage in process technology.
Why would you want to run iOS apps on an x86 ? Don't x86s have enough apps already out there already ? How about making better software and licensing cores instead of porting software from a vigorously defended walled garden to a more costly and less efficient platform ?
Compare and contrast:
1) DEC trying to punt VAX-11s into the PDP-11 land. Did anyone really run PDP-11 code on VAX-11s ? It seemed like a very expensive and unrewarding way to burn a lot more electricity and spend more on software licensing to me.
2) Intel trying to punt Itanics emulating x86s.
Hopefully Intel will repeat DEC's next phase of history, namely producing something very good and then going tits up.
Mine is the one with the RH780 in the pocket. ;)
Why it's the smell of Intel collectively soiling themselves as ARM chips get more and more powerful and more and more widespread.
Whilst 'logical', this move smacks of desperation ... the vast majority of iphone apps are so cut down as for it to be non-sensical to port them. Others are ports of pre-existing apps on other platforms.
I really don't see any way for Intel to stem the tide at the moment, especially given that it looks like AMD will finally be VERY competitive in the low power and netbook / laptop segment from Q4 '10 / Q1 '11.
"Flash is so cheap that needing a few GB extra is no problem" (and similar ones).
That depends. We're not usually talking about changing one flash card for another in the ARM market. In the Atom market, maybe, but Intel want to go lower don't they? If there's plenty spare memory, you're OK. When it's full, and the SoC or some other aspect of the design has no room (or $ or power budget) for more, how much does that cost to fix?
Example: Linksys WRT54G [1] routers used to come with enough ROM and RAM to hold a Linux. But on each unit they sold it was costing Linksys money that they didn't need to spend. There are other lighterweight OSes around but they (a) aren't so widely known and supported so there's a porting cost (b) depending on the licencing arrangements these alternatives can cost a fortune up front (if you want to avoid a per-box fee).
Linksys decided it was worth the time, effort, and cost of moving their software from Linux to VxWorks (a commercial RTOS with substantial licencing costs) because over the lifetime of a product it would save them money - it allowed them to halve the amount of ROM (16MB->8MB) and RAM (4MB->2MB).
Yes, it's an extreme example and maybe not as significant as some of the other factors. At least till you overfill your ROM. Then code size is the only thing that matters (using less data is rather trickier).
[1] These are Broadcom ie MIPS-based not ARM-based but the principle is the same; memory is cheap till you run out.
Surely this needs to be more about porting to different API's not a different CPU.The iOS development tools already happily build for i386 - the iPhone/iPad simulator runs code natively on the development machine (which must be a Mac with an Intel CPU).
Porting across to a different OS and an UI framework is where the fun is going to be. If the app in question is a game which takes over the display and does its own thing, that's probably not too much of an issue. If, however, its a utility which is displaying everything using Cocoa touch, maybe using Core Data on the backend, you'll probably have an easier time starting from scratch...
if the description is correct. Its a tool for the source code, not the 'machine code'. It just marks out what function calls need to change and what to change em to.
Which is what you'd want, not a low level 'change this instruction to this'..
Of course, with some developer setups, you'd have a cross platform codeset anyway.. (with as little obj-c in it as possible ;) )..
"Though I see no technical reason why an x86 or AMD64 design in the same league as the ARM's power efficiency is not possible. The transistor overhead due to the extra instructions should be small at modern manufacturing scales."
An x86 chip has to be several orders of magnitude more complex than an ARM in order to both support translating the hideous legacy x86 instructions in to something a modern processor can execute efficiently, plus the huge amount of baggage from the various instruction set extensions which have built up over the years.
On the same physical process each part of the chip can be just as power efficient as an ARM, but there is always going to be more parts of the x86 to power.
Wouldn't this be more about taking MeeGo apps from ARM based smart phones and getting the same binaries to run on the Intel based netbooks (which would have faster processors / more memory / etc)?
And the Apple slant was purely because it was reported on MacWorld?
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
