Intel's Plans For X86 Android, Smartphones, and Tablets

MrSeb writes "'Last week, Intel announced that it had added x86 optimizations to Android 4.0, Ice Cream Sandwich, but the text of the announcement and included quotes were vague and a bit contradictory given the open nature of Android development. After discussing the topic with Intel we've compiled a laundry list of the company's work in Gingerbread and ICS thus far, and offered a few of our own thoughts on what to expect in 2012 as far as x86-powered smartphones and tablets are concerned.' The main points: Intel isn't just a chip maker (it has oodles of software experience); Android's Native Development Kit now includes support for x86 and MMX/SSE instruction sets and can be used to compile dual x86/ARM, 'fat' binaries; and development tools like Vtune and Intel Graphics Performance Analyzer are on their way to Android."

Comments

x86

[Unclenefeesa]

Since most of x86 architecture and related hardware is getting smaller and most smartphone are getting bigger, they are bound to meet somewhere.
hmm, I guess it will be called a tablet or an i(ntel)Pad. ehm ehm

Re:x86

[Anonymous Coward]

Given the choice, everyone who actually has to code for those CPUs (e.g. compiler makers), without a doubt prefers ARM over x86. Simply because of how shit x86 is.
It's the Windows ME of machine code. It started out as a DOS, and kept the cruft all the way to today. While piling more and more bigger and bigger stuff on top. Ending up with a upside-down pyramid, held in balance by a billion wood sticks.
And I know that even Intel itself couldn't stand it anymore. That's why they implemented that microcode solution with a RISC processor on the inside.
If only they would give us direct access to that core, but leave the microcode in there for 1-2 processor generations for legacy reasons.
Then nobody would willingly keep doing x86, and before those 2 generations would be over, it would be locked away and forgotten.

I, for one, plan a 265-core ARM CPU as my next desktop system. (Yes, ARM cores are slower per clock cycle. But they are *a lot* more efficient and *a lot* cheaper too. [No, ATOM does not count, unless you add that northbridge that's so big and gets so hot that looking at the mainboard 10/10 people think it's the actual CPU. Which is closer to the truth as Intel ever wants to admit.])

Re:x86

[chill]

Not while keeping a straight face, no.

Re:x86

[tlhIngan]

What i would like to see is a CPU architecture that can have asymmetric cores:

Similar to your design, the Tegra 3 ARM SoC does that. It has a quad-core A9 running at 1.5GHz or more, but it also has a "slow" core running at 600MHz or so. When things are idling, the slow core takes over and does the job while the hefty quadcores are powered off, saving tons of power.

Marvell I think also has a similar idea for their SoCs. And ARM's A15 design is supposed to incorporate that as well.

Re:Intel's Software Experience...Graphics

[gl4ss]

have you used intel graphics lately(stuff they're shipping in 2011)? it's like having a discrete mobile gpu from 2004.

but this article is not news of any kind. intel has had these plans out in public for years and years, android ndk has support for multiple targets. if they actually started shipping _that_ would be news.

Intel Softcores

[inhuman_4]

While it is always nice to hear about companies contributing to opensource, I don't see there being a big demand for x86 android. Who would use it? It's not low power enough for most tablets/phones. And while the ability to run existing x86 apps is nice they are mostly tied to Windows which is also not likely to see much traction in the mobile space. So what is the point?

What I would like to see is Intel creating a SoC and softcore suite. Intel has some big advantages that they could use to seriously compete:
1) Lots of experience in chip design. I don't see why they can't create an ARM-Core competitor.
2) They can start from scratch. Unlike ARM there is no need to legacy support or backward compatibility.
3) They have in house designers for everything from graphics, wired, wireless, etc. chips. I don't see why they cannot design from this a whole suite of modules that work on their SoC platform.
4) They have (to my knowledge) the best chip fab plants in the world by a sizable margin. Die shrinks offer a great way to reduce power consumption.
5) They have produced great x86 compilers for years, so producing a new compiler for a new chip shouldn't be too difficult since they are already experienced with x86 and Itanium.
6) They have shown that they already know how to support Android.
7) They have the cash and business partners to make it work.

I'm not saying they are guaranteed to make big bucks. Fighting an intrenched ARM with wide industry support will be hugely difficult. But if any company can do it it's Intel. Of course this means they would have to get over the Itanic debacle and stop trying to shove x86 down the throats of every problem.

Re:Intel Softcores

[Gaygirlie]

It's not as if "x86" means much from an architectural standpoint. It is a choice in instruction set and is a good choice for new products given your (5) above -- what's got better payoff, making a new instruction set or reusing an existing one that is supported exceedingly well? Intel's 386 and AMD's 64-bit conventions are common ground for many wildly different CPU architectures.

Actually yes, "x86" does mean a lot even from an architectural standpoint. For example it means you have to carry along all the instructions and their related mechanisms concerning 8086 Real Mode, and 80286 Extended Real Mode, plus all the horribly clumsy register types. That means you'll be wasting die space just to support stuff that isn't even used anymore, not to mention the time wasted on actual hardware design. With a completely new processor design you can just scrap all that, add much more flexible registers plus more of them, and get a more efficient CPU as a result. Every little bit of space saved is meaningful on a processor aimed for mobile devices, and it does help on desktops, too, if not as much.

Re:Intel Softcores

[TheRaven64]

What I would like to see is Intel creating a SoC and softcore suite

They did that, what, 18 months ago now? Total number of people who licensed it: zero. Why? Because x86 absolutely sucks for low power.

Lots of experience in chip design. I don't see why they can't create an ARM-Core competitor

Ah yes, all those massive commercial success stories that Intel has had when it tried to produce a non-x86 chip, like the iAPX, the i860, the Itanium. The closest they came was XScale, and they sold the team responsible for that to Marvell.

They can start from scratch. Unlike ARM there is no need to legacy support or backward compatibility.

Intel has two advantages over their competition: superior process technology and x86 compatibility. Your plan is that they should give up one of those?

They have produced great x86 compilers for years, so producing a new compiler for a new chip shouldn't be too difficult since they are already experienced with x86 and Itanium

Hahahaha! Spoken like someone who has never been involved with compiler design or spoken to any compiler writers. Tuning a compiler for a new architecture is not a trivial problem.

Re:Intel Softcores

[yoshman]

The mistake most people seem to make here is to compare ARM to IA32, when they should be comparing ARM to Intel64/AMD64 (x86_64) since even Atom can run 64-bit code these days.

Going to 64-bit does increase code size a bit, but one of the good things about x86/x86_64 code is that it is VERY dense. This document

http://www.csl.cornell.edu/~vince/papers/iccd09/iccd09_density.pdf

suggests that 64-bit x86 code is actually even denser than ARM-thumb code in most cases (which in turn is denser than "normal" ARM code).

High code density means more cache hits, which means better performance and less power-hungry.

x86_64 has the same amount of integer registers as ARM: 16. Every single x86_64 CPU has support for SSE, which means that floating point operations can (and is) handled by the 16 SSE registers instead of the old x87 fpu-stack.

Fact is that the 64-bit specification for x86 fixed a large number of problems that the 32-bit specification had, making x86_64 a really good architecture without any significant flaws.

Re:Intel Softcores

[Short Circuit]

x86 is CISC when we know RISC is better. Intel/AMD do some tricks to make the core more RISC, but why not just cut out the middle man? Why bother with converting it at all?

Pull up a pillow and have a seat around ol' Grandpa Short Circuit. This may come as a shock to you.

Some programs still being sold and run on desktop computers today were compiled over ten years ago. Some programs still sold and run in x86 embedded environments were compiled twenty to thirty years ago. That's why x86 is still around.

x86 is still around for the same reason Windows is still around. It still runs binaries that are really, really old. In some cases (many, I expect), the source code for these binaries no longer exists, or the toolchain for building it is bitrotted. That's why x86 is still around.

Imagine some sci-fi horror film where everyone's forgotten how to maintain the vast infrastructure of their civilization, they just don't poke it because they don't want it to break. That's why x86 is still around.

Meanwhile, every year there are more long-lived applications built for the existing platform, with very little hope for being updated for newer platforms and processors; their binaries are likely to be running for another five or ten years.

Amusingly, open-source software has a clear advantage over closed source software in this arena. Several distributions are actively keeping software packages portable across CPU archs, and even portable across OS kernels. (Debian and Gentoo both support BSD foundations as well as Linux)

Re:Now for step 2

[MysteriousPreacher]

Does doubling its size count as an optimization?

Re:power consumption

[TheRaven64]

It is. The difference between an x86 and ARM core is around an order of magnitude at the moment for the same performance. But the difference between an x86 core and the display is another order of magnitude, so for devices that you mainly use with the screen on there isn't much difference between x86 and ARM in terms of overall power consumption. The difference in battery life between an ARM core at 200mW and an Intel core at 2W is very small when the display is using 10-20W. There are a few display technologies that are supposed to be hitting the market Real Soon Now that ought to make the difference between x86 and ARM a lot more apparent.

Re:power consumption

[craftycoder]

I'd mod up your post, but I want to reply instead. Are you suggesting that the display uses 50-100 times the power of an ARM chip (and therefore 5-10 times an x86)? If that is true, that is very interesting. I did not realize the display was such an outlier in power consumption department...

Re:power consumption

[Mr Z]

Is the display really that much of a hog on a cell phone? Those numbers sound like laptop numbers, but I thought we were talking cell phones.

My phone has a battery that holds around 1300 mAh at 3.7v. That means I can draw 4.8W for 1 hour. If my phone's display really sucked down even 10W, then I wouldn't be able to have the display on for more than about 28 minutes total, which doesn't match my experience at all. I regularly browse the web from my phone for a half hour at a time, without making much of a dent in the battery.

A quick scan through this paper suggests backlight power for the phone they analyzed tops out at 414mW, and the LCD display power ranges from 33.1mW to 74.2mW. If you drop the brightness back just a few notches, the total display power is around a quarter Watt or so, which sounds far more reasonable.

I don't think Intel is standing still on power consumption. Their desktop CPUs are hogs, sure, but they can bring a lot of engineers to bear optimizing Atom-derived products. (We might get an early read from Knight's Corner, actually, although I expect it to still be on the "hot" side. I'm waiting to hear more about it.) Also, ARM's latest high-end offerings (including the recently announced A15) aren't exactly as power-frugal as some of their past devices. In the next couple years, I think the scatter plot of power vs. performance for ARM and x86 variants will show a definite overlap in the mix, with some x86s pulling less power than some ARMs.