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."
First Post yuuuuppiiii
In this field no matter how much you know, You still don't know anything.
Google allowed them to mess with the graphics engine? OMFG, we'll end up with tablet devices that run 1990's era graphics tech. One thing that Intel sucks hard at, is their graphics hardware and software. Letting them touch anything related to that in Android and Android devices is a freaking mistake.
@Mindless Drivel: 100% of Twitter posts ever Tweeted.
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.
I thought x86 is a power hog compared to ARM. It seems like that is a serious consideration for mobile devices to me. I'll be interested to see where this goes. In the mean time, x86 chips are going to have to get a lot cheaper to compete with ARMs prices.
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!
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.
Add some x86 optimizations to the battery.
...Intel also wants a piece of the pie. Intel.Atom.Ant awayyy
If you want a software platform to be able to build native code to your hardware you add code to their software base.
Having to work for a living is the root of all evil.
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
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.
LOL. Tits on a bull much?
Intel isn't just a chip maker (it has oodles of software experience)
Has Intel ever done any software other than to boost hardware sales?
Sure, they write lots of software, but they *are* just a chip maker.
x86 arch will mean that Android will be a great virtualization platform in the future. Its already being done with android but with x86... much much easier!
VMware... where are you?
The only benefit to native support of x86 is to run existing code* at high performance. If speed is not important, then emulate the instruction set. 9and then you will need to emulate the OS to for win32 compatibility, which is beyond the scope of this)
If you create a brand new instruction set and offer it to the world, there is a real issue that no one will buy it and the market will go a different direction and buy a competitor's product.
*If it is windows code, in my AC opinion, you are daft to want to run a program, written 5+ years ago, as fast a it can be run, on a tablet. Novelty/hobbyists aside, who is going to buy a shiny tablet with (oh say) windows 8, and install Office 2003 on, and be pissed that is doesn't run as fast as it does on their desktop.
Yay.. universal binaries again, like apple had the foresight to do but then later quit. ( no, that was not sarcasm, just disappointment )
---- Booth was a patriot ----
You forget too easily that many people depend on this legacy code to run software of thousands or even millions of dollars.
Then keep your legacy code and run it in an emulator on an ARM CPU. The legacy code was probably written so long ago that it'd run as fast in a JIT emulator today as it did natively then.
You know, like Quake 4, Doom 3, Vendetta, and X3
Vendetta is from 1991. It's like pointing out that Mega Man X3 runs in a Super NES emulator: interesting, and probably fun for a while, but not what grandparent had in mind. As for Quake and Doom, can you recommend things other than first-person shooters that commonly get ported to Linux, especially well-praised E or E10+ rated game series?
And nevermind that wine actually works really well
Only on x86 phones. Most existing smartphones are ARM; let me know when Atom phones start to come out. And even if you stick to games from the Pentium 4 era, knowing that Atom is roughly comparable to a similarly clocked Pentium 4, you'll still have to work around copy protection measures that rely on the machine having an internal CD-ROM drive.
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.
It's not like Android is going to run on top of Windows.
Let the Linux kernel loose Intel.
Really? I worked there for a long time and aside from a few handfuls of people in the architecture labs, there are few companies I've been involved with that had such a low understanding and weak efforts involving software design. I cant think of a single vice president or anyone who reported to a VP who had much of an inkling about software.
Heck, one look at the long running issues with integrated graphics device driver development is a pretty good indicator.
Mind you, I have a fairly recent quad core Intel proc in my Windows 7 workstation, and it runs software only available on Windows (which is why I have it) pretty well.
But, rightly or wrongly, I associate Intel with big hot power hungry hardware, that you *must* have if you have apps that need Windows, and ARM with low power battery sipping appliances. Android seems made for the latter, and out of place on the former. I can understand why Intel wants to get a piece of the Android pie -- they are protecting their market, and they want to have a cohesive appliance design that will run both Metro and Android. But do we really *need* Android on Intel?
I don't really need Android running on my workstation. That's what Winders is for. On the other hand, I don't really want a white hot Intel proc in my tablet. What am I missing?
Adobe is working on porting their products to Android/touch, and eventually I may be able to jettison Windows [1]. At the same time, my intention is to jettison the traditional KVM and switch to touch. [2] At that point I'm not sure why I would still need Intel.
[1] Parenthetically, Microsoft had a chance to jump on the touch market early, with a superior interface, but chose to relegate Surface to Movie Prop status and missed their chance to survive when Windows finally becomes irrelevant. But that's another story.
[2] It should be repeated, Windows is not an application, it's a program loader and resource manager. All those effects we struggle to turn off just makes the hardware run hotter.
Oliver's law of assumed responsibility: If you're seen fixing it, you will be blamed for breaking it.
Games stress emulators in a way that business applications do not because games tend to use dirty I/O tricks to increase smoothness of animation. Business applications tend to use better-known I/O methods.
I'm wondering if they're optimising for x86 so that it's possible to test 4.0 code using the Android emulator. It was near-impossible to use 3.0 in the emulator due to speed issues, and we found it was easier to buy a 3.0 device for testing on than trying to use the horrendously slow 3.0 emulator.
Ha, one of those people that thinks there's a clean, perfect RISC architecture inside Intel CPU cores.
First off, everything is microcoded. Power is microcoded. SPARC64 is microcoded. Itanium isn't, but it's an oddball in that regard. Microcode just lets you hide implementation details and potentially simplify internal design.
Internal microcode isn't necessarily fun to play with. Look up the articles on RealWorldTech on the guts of Transmeta's CPU's if you're interested, and that used a significantly higher-level microcode than Intel does, from what I understand. Most of x86's microcode is related to stuff like turning direct memory references in instructions into load/store instructions. Taking that away does not make the chip magically faster. If you took away the decoder, and just ran on the metal, you'd probably encounter something that wasn't really any faster and felt vaguely like an x86-like microcontroller or a DSP from a programming perspective.
I bet if intel just licensed the ARM architeture, but did their own implementation of it, using all their techniques and their 22 nm fab, it would be a lot faster and eat less power than any other ARM cpu on the market.
Well that is based on an Intel platform, so they do have some experience
Cause we're gonna need a bigger battery.
This is a hacked account, for which the owner can not be held responsible.
guess who dave ditzel works for now?
NetBSD: the cathedral vs the bizzare.