Slashdot Mirror


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

31 of 151 comments (clear)

  1. x86 by Unclenefeesa · · Score: 5, Insightful

    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

    --
    In this field no matter how much you know, You still don't know anything.
    1. Re:x86 by Anonymous Coward · · Score: 4, Interesting

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

    2. Re:x86 by chill · · Score: 4, Funny

      Not while keeping a straight face, no.

      --
      Learning HOW to think is more important than learning WHAT to think.
    3. Re:x86 by ozmanjusri · · Score: 2
      I can say "Meh".

      Is that close enough?

      --
      "I've got more toys than Teruhisa Kitahara."
    4. Re:x86 by TheDarkMaster · · Score: 2

      You forget too easily that many people depend on this legacy code to run software of thousands or even millions of dollars. Not because your desktop in your mom basement no longer need it so that the mankind did not need anymore too.

      --
      Religion: The greatest weapon of mass destruction of all time
    5. Re:x86 by mlts · · Score: 2

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

      When the machine is idle, one low-power core handles the OS idle functions while another handles the IP stack, another core handles I/O, and another handles the hypervisor aspect.

      When the machine is running database stuff, first cores that are made for integer operations get used, then the FPUs and GPUs come in.

      Flip to a game, and the cores that mainly are used as GPUs come into play.

      Fire up a modeling task, and the FPU heavy cores take the load first.

      All this while cores dedicated to AES and RSA deal with the hard disk encryption as well as SSL/TLS items.

      As for instructions, I agree with you there. Intel knows that the x86 needs to go, but has to keep that architecture going for legacy reasons. Ideally the best solution would be an Itanium chip with a ton of registers (128 general, 128 FP, etc.) This makes operations easier because all the fetches can be done first, the registers used, then the results stuffed back into memory, making caching easier.

      Even more ideal is putting the x86 emulation into hardware so operating systems that are legacy can run on that and a hypervisor, while programs using the new architecture can run optimally. It might even be good to put the hypervisor on the CPU.

    6. Re:x86 by tlhIngan · · Score: 3, Informative

      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.

    7. Re:x86 by oakgrove · · Score: 2

      But you're kind of missing the point though. If ARM really is that much better than x86 (I don't really know as I don't program on that level) then with the amount of momentum it is catching in mobile devices, ARM overtaking x86 is inevitable. I don't know a lot about x86_64 whatever vs. ARM but I do know that my Xoom outperforms my netbook and it does it while generating no heat and with 3 times the battery life from a smaller battery. Look out, intel.

      --
      The soylentnews experiment has been a dismal failure.
    8. Re:x86 by davester666 · · Score: 2

      Didn't Balmer just threaten everybody with something along the lines of "We'll always live in a Windows era"?

      Or was it more of a warning?

      --
      Sleep your way to a whiter smile...date a dentist!
  2. Re:Intel's Software Experience...Graphics by gl4ss · · Score: 5, Informative

    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.

    --
    world was created 5 seconds before this post as it is.
  3. Debian by mschoolbus · · Score: 2

    Just give me a debian build for my phone including dialer, messaging, etc..

    Then I can play REAL games on my phone.. Or as real as they get in Linux!

    1. Re:Debian by znerk · · Score: 2

      Just give me a debian build for my phone including dialer, messaging, etc..

      Then I can play REAL games on my phone.. Or as real as they get in Linux!

      Games aren't real on Linux? Yeah, PenguSpy and Linux Gamers don't have real games, really written for real Linux. You know, like Quake 4, Doom 3, Vendetta, and X3 - those aren't real games... oh, wait.

      And nevermind that wine actually works really well, nowadays, running many top games "flawlessly, out of the box", and tons more "run flawlessly with some special configuration".

      --
      This work is licensed under a Creative Commons Attribution 3.0 Unported License.
  4. Intel Softcores by inhuman_4 · · Score: 4, Interesting

    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.

    1. Re:Intel Softcores by Gaygirlie · · Score: 3, Informative

      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.

    2. Re:Intel Softcores by TheRaven64 · · Score: 4, Informative

      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.

      --
      I am TheRaven on Soylent News
    3. Re:Intel Softcores by yoshman · · Score: 5, Informative

      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.

    4. Re:Intel Softcores by Short+Circuit · · Score: 4, Insightful

      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)

  5. Re:Intel's Software Experience...Graphics by ByOhTek · · Score: 2

    Google allowed them to mess with the graphics engine? OMFG, we'll end up with tablet devices that run 1990's era graphics tech.

    Wow. I hadn't realized Intel's graphics offerings have improved to even that point.

    At least it wasn't ATI/AMD, then it would be fast, but crash a lot...

    --
    Self proclaimed typo king, and inventor of the bear destroying coffee table (patent not pending).
  6. Now for step 2 by davidbrit2 · · Score: 2

    Add some x86 optimizations to the battery.

    1. Re:Now for step 2 by MysteriousPreacher · · Score: 4, Funny

      Does doubling its size count as an optimization?

      --
      -- Using the preview button since 2005
  7. Re:Intel's Software Experience...Graphics by sarhjinian · · Score: 2

    Even if they develop their own graphics chip for tablet use, it'll a) probably be enough for what you'd do on a tablet (seriously: on a desktop PC, for anything except gaming, Intel's stuff is good enough), and b) it depends on how well the software's done, anyway (case in point: on many recent Linux distros, and again, unless you're gaming, Intel's chipsets provide a better overall experience than much more capable nVidia or ATI hardware).

    --
    --srj/mmv
  8. Android Distributed on 802.15.4 by Doc+Ruby · · Score: 2

    What's more interesting to me is the Android@Home announcements (from Google IO 2011) that Google is implementing its own networking stack (instead of Zigbee) on 802.15.4. 802.15.4 is a very low power low-level radio network, with cheap embedded microcontrollers that are often ARM. There's probably not enough power in the node's ARM to run Android, but some nodes could have extra power and extra ARM cores that do run Android.

    Android's Java means in addition to network RPC, code can be straightforwardly programmed to safely migrate around the network for distributed local execution near the data, whether that's network metadata, sensor data, or just the power of massively parallel distribution. I wonder whether JavaSpaces or something like it (probably a very lite version) will find a fit in making cheap distributed networks represented in computational tuplespace. Distributed around one's home, office/classroom or car, or among one's clothing (daily worn watch/jacket/shoes/belt/keyring), or eventually merging among those personal spaces as they're either near or just related (linked by the Internet).

    Intel's x86 architecture still has too much power consumption (and the legacy HW baggage that consumes it) to be a design win for this distributed architecture. By the time x86 is suitably low power, Android will probably have defined the space of these smart spaces, and the smart things in them.

    FWIW, there's still few details of A@H, though supposedly there is a reference implementation (network backbone embedded in LED bulbs). Anyone seen any specs, like whether it's really a SNAP/6LOWPAN hybrid, or which specific alternative Google is now pushing? Where to get the devkits (HW and SW)?

    --

    --
    make install -not war

  9. Oh Java to the rescue by thammoud · · Score: 2

    Not very popular on /., but Android being Java based will make life very easy for Intel to crack the mobile market. Most of the apps (sans native ones) will just work. It would have been almost impossible otherwise without some serious virtualization.

  10. Re:power consumption by TheRaven64 · · Score: 5, Insightful

    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.

    --
    I am TheRaven on Soylent News
  11. Re:power consumption by craftycoder · · Score: 4, Interesting

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

  12. Re:Intel's Software Experience...Graphics by Mr+Z · · Score: 2

    Hey, don't knock my Diamond Stealth 64! It's got VLB!

  13. Re:power consumption by Mr+Z · · Score: 5, Informative

    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.

  14. Would be an exercise in uselessnes by Makawity · · Score: 2

    I bet everybody think about Android Market and all the cool stuff there. Well, don't do that unless your Android runs ARM.

    I've got recently my hands on a Android MIPS phone. Extremely frustrating experience -- two of every three downloads from the Market simply refuse to install, because they have some tiny snippet or library compiled to ARM native code. Unless Intel heavy invests in app developers recompiling their works for Android/x86, it will be barely usable outside of the base system.

  15. Re:power consumption by pmontra · · Score: 2

    On my Samsung Galaxy S2 it's between 40 and 50% so maybe the super amoled display is really a power saver despite the 4.3"diagonal. And I use little wifi and little 3g, only when I explicitly need the net, so the display consumption could be even lower in % on a typical always on scenario.

  16. Re:power consumption by zealot · · Score: 2

    Despite what many other commenters will say, no, it isn't a power hog compared to ARM. Or at least it doesn't have to be. Intel/AMD/VIA don't yet offer processors that have as low power as ARM (although some are pretty power/performance efficient depending on your workload), but they will within the next year for smartphones and tablets. On modern manufacturing processes the "x86 tax" becomes almost non-existant.

    --
    He said, "You'll be able to tell your grandchildren that you helped assemble the first NT supercomputer," and I cringed.
  17. Re:power consumption by tycoex · · Score: 2

    I have my phone screen on for about 2-3 hours per day due to bus rides. According to my the Android battery tracking thing my display uses up around 60-70% of my battery for the day, and this is on a Nexus S with the AMOLED screen that is supposed to use less battery than an LCD screen due to not having to light up the black pixels.

    The screen really is huge when it comes to battery consumption.