Ice Cream Sandwich Ported To X86

angry tapir writes "Google's open-source Android 4.0 operating system for smartphones and tablets has been ported to work with x86 processors. The port means that tablets with Android 4.0 based on x86 chips could be on the horizon. Intel is the top x86 chipmaker, and the company has already said it is working with Google to bring Android 4.0 to smartphones and tablets."

Comments

Singularity

[cyachallenge]

It seems our technology continues to expand in all directions and then collapse into a single device. TVs, PCs, and phones are becoming part of the same thing.

Re:Singularity

[Ethanol-fueled]

It's like Ubuntu's Unity, except that it'll get good reviews!

Re:Singularity

[akirchhoff]

This sound like Microsoft's strategy all over again. Anyway you cut it a single platform ecosystem is ugly, as it just lets another monopoly.

New boss same as the old boss

Re:Singularity

[fuzzyfuzzyfungus]

Microsoft's strategy in an alternate universe where large swaths of the Windows core are gpl2 or apache, every x86 whiteboxer has their own "Windows Distribution" and their primary leverage consists of the licensing requirements to ship Office out-of-box..

Re:Singularity

[shellbeach]

This sound like Microsoft's strategy all over again. Anyway you cut it a single platform ecosystem is ugly, as it just lets another monopoly.

Sure, Microsoft's strategy, only with an open source OS being built in this case by hobbyists and enthusiasts. Definitely sounds like monopoly building at work to me ...

Re:Singularity

[mjwx]

Microsoft's strategy in an alternate universe where large swaths of the Windows core are gpl2 or apache, every x86 whiteboxer has their own "Windows Distribution" and their primary leverage consists of the licensing requirements to ship Office out-of-box..

RMS went back in time to stop Microsoft before they could begin, but it went horribly horribly wrong, Microsoft sent their best man back in time to stop him...

Balmer still wasn't good enough.

Re:Singularity

[Anonymous Coward]

Android is nice but don't kid yourself: it is not built by hobbyists and enthusiasts. It's very tightly controlled by Google -- I really appreciate them making source releases when it suits them, but that doesn't change the fact that it's still controlled by them.

In case you were referring to the kernel: linux is partly built by hobbyists but it just isn't a major part of the Android strategy so I don't see how that applies here... Google will keep their linux fork and could even swap the kernel if kernel developers really started being difficult -- it wouldn't be painless but it would definitely be possible.

The point is: Android is tightly controlled by a single entity. Letting them become a monopoly (or even close to one) would be bad. It would be different from Microsoft but still bad.

Power?

[Daniel_is_Legnd]

What is the power consumption like on an x86 tablet vs. an ARM tablet? Seems like running Android, x86 would still be much less efficient than an ARM core.

Re:Power?

[Anonymous Coward]

Yes, but on the other hand, even an Intel Atom is significantly faster than even the fastest ARM... pity Intel insists on supplying their own GPU with Atoms, because the NVidia Ion + Intel Atom.combo was actually pretty sweet.

Re:Power?

[vivek7006]

Why? x86 or ARM, both obey the same laws of physics. There is nothing inherent in ARM which makes it better at running Android. The x86 benchmarks are looking very good http://i.i.com.com/cnwk.1d/i/tim/2011/11/30/intc113011aa_610x466.jpg

Re:Power?

[dbc]

Yes, interesting question, but difficult to ask correctly. x86 power consumption is all over the map, varying with features, and the same can be said for ARM. More interesting numbers are MIPS/Watt, FLOPS/Watt, and MACS/Watt. Then of course, MIPS don't translate directly into whether or not the platform "feels snappy". Some of those Watts might be better spent on fast display updates than on MIPS when you look at the total platform experience.

Re:Power?

[afidel]

Intel has a major process advantage over everyone else in the industry and with the introduction of the 3D trigate they'll be able to bring leakage current down significantly. I imagine they'll be able to get similar battery life to ARM based solutions with significantly better burst performance. However I'm not sure how much that matters since quad core A9's are already pretty powerful for most users, especially with GPU cores available for the heavy lifting in games and video.

Re:Power?

[Max Littlemore]

But isn't the x86 instruction set inherently silly? I thought modern processors run RISC cores with shenanigans wrapped around to implement the x86 legacy. Surely that means that they are inherently less efficient even if it's only marginal.

Looking at the 4+1 thing that NVidia has done with Tegra3 I think it may be too late for x86 and it may finally die a death. We can only hope.

Re:Power?

[ArhcAngel]

The better question is why the submission focuses on Intel when the port currently only works on AMD?

"The release isn’t fully stable — missing sound, camera, ethernet, and hardware acceleration for Intel chipsets. What will work however is Wi-Fi, sound, and hardware acceleration for AMD chipsets."

Re:Power?

[Anonymous Coward]

The X86 instruction set was silly, then it stopped being silly as instruction bandwidth became a limiting factor for RISC processors. Ideally you want a kind of huffman coding for instruction sizes, so that the most frequent instructions are the smallest. Traditional RISC makes all the instruction the same big size, so you get the worst bandwidth through a limited instruction bus.

In today's world, where on chip busses are so much faster than off chip busses and instruction bandwidths are limiting, having compact instructions over the pins, being converted on chip to regularized RISCy instructions makes complete sense. So X86 stopped being silly a while back.

If you wanted to design a new instruction set today, you'd optimize for things like instruction bandwidth minimization, security, parallelizability and important application loads (e.g. more DSP). In that light, X86 might be a bit messy, but it is far from silly, especially after the 64 bit cleanup.

Re:Power?

[Anonymous Coward]

Actually the Cortex A9 found in Tegra 2 and Ti's OMAP 4 series are at the same clockspeed marginally faster than even the top end Atom cpus, IONised or not, even at their standard speeds the differences in performance are not that huge.

http://parisbocek.typepad.com/blog/2010/11/arm-outmuscles-atom-on-benchmark.html

Re:Power?

[Anonymous Coward]

Pretty sure things like the tegra 3 would blow away any atom.

But, even things like the omap4 and tegra 2 might be pretty close. Memory bandwidth sucks on the omap, so for some things like large transfers of data atom may excel over omap but not really cpu speed issue. Tegra doesn't share this flaw with the omap.

I never did / read any benchmarks, but I have a dev board with an omap4 on it, and it "feels" just as fast as my netbook. The dev board is currently doing duty as the guest web browsing machine, wifi access point (two radios), radius server, ldap server, firewall, squid proxy, webserver, dhcp server, dns cache, network USB server (serves up a dvd writer to my netbook over wifi this way), and fileserver (laptop hard drive) for the house. It is running Debian wheezy armel (need a few more things to work on armhf before pulling that trigger, but armhf will make it even faster).

As for power, even with all the peripherals (radios, spinning hard drive, USB hub, doing a native build), it is pretty rare to see system power hit 5 watts. Atom is left in the dust here too.

Re:Power?

[catmistake]

As others have pointed out, Atom is pretty weak. It has a rep for being powerful, idky. The Atom is on par with the PowerPC G4... an old chip that uses a lot more energy. I'd be very surprised if ARM couldn't easily match it. If you want more proc power in a low power chip, AMD E-350 blows Atom away. I really don't undertand everyone's crush on Atom.

Re:Power?

[Guy Harris]

All major processors except Itanium use microcode, including most ARM implementations. It's not an x86-specific thing.

The second sentence is true. The first one, well, do you consider SPARC and Power Architecture processors to be "major processors"? If so, where's a citation to indicate that they use microcode? Even if not, where's a citation to indicate that most ARM processors use microcode?

Also, what "run RISC cores with shenanigans wrapped around to implement the x86 legacy" means is that, on at least some modern x86 processors (dunno about Atom, but Intel's other processors since Pentium Pro, as well as, I think, all AMD processors since the K5), the x86 instructions are decoded into one or more presumably-RISCy "microoperations" which are what are scheduled and executed by the execution units. Some of them might be implemented with "microcode" in the sense of microoperations fetched from a ROM rather than generated on the fly by the decoder.

Re:Power?

[pjr.cc]

While slightly off topic - if you like ion, try amd fusion (e350m series)... very much like atom, but actually worth having (faster, and generally better hardware).

I liked the idea of atom, until i got one and compared to a (at the time) 8 year old epia (N10k)... the atom was about 1.5 times the speed and sucked down more juice... I was really disappointed with the atom processor... ION made it worth while, but in reality the atom is a POS bang per W is very low on the platform and the atom has had several functions torn out of it (compared to a i3/i5/i7 or core/core2) which i personally found kind of annoying..

But, back on topic. This should run on the embedded cpu AMD fusion boards (such as the e350 mentioned above) and if i get the chance i do plan on giving it a shot.

Re:Power?

[gman003]

Clock speed != performance. Especially not between such divergent systems as x86 and ARM. Even comparing clocks between Atoms and Cores is an unreliable indicator of relative performance, let alone comparing different fundamental architectures.

Re:Power?

[symbolset]

Intel's not the only foundry on 22nm. Obviously not, since they buy their lithography equipment from third parties that must have more than one customer. They're investing heavily in this area it's true. Trigate is slick, but there are a lot of up-and-coming technologies Intel can't prevent. Apparently Intel forgot to patent the 90 degree rotation of trigate.

Intel's problem isn't their hardware, it's the software that runs on their hardware. In the executive suite they've got a Windows habit that's hard to kick. That worked for a while, but that day is coming to an end. People are starting to look from their WinTel PC to their iPad, iPhone, Android tablet or phone and ask: WTF? Why is this all-day battery-powered thing more capable and responsive than the half-kilowatt new desktop before me? For a lot of years the proclivity of Windows to consume all of Intel's Moore's law progress in hardware with slower software was a good thing. It moved a lot of units - encouraging people to upgrade both hardware and software, but Apple and now Google have spoiled that game. It was a trick and now the trick is told, all bets are off. It's a new game now.

Truth be told I was always amazed that people with a 3GHz dual-core processor just accepted that to get a desktop they should fire it up and go get coffee because they knew it took five minutes. That's performance we wouldn't have stood for in 1984 when processors were less than 0.01GHz and storage was slower still. A 3GHz single core Intel processor from 2005 retiring 4 instructions per clock retires 3.6 trillion instructions in five minutes. A modern SATA hard drive can deliver something like 4.8GB in five minutes. A modern gigabit network connection passes 6GB in five minutes. A reasonable desktop environment takes about 3MB and a few million instructions to present. Do you get what I'm saying? The hardware isn't the problem and it hasn't been since about 1993. Just abandoning crap software isn't going to get Intel out of the woods though now. That might have worked in 2003.

Intel's software partner Microsoft got the clue first, and now the word is that Windows 8 will be expressive and performant even on Windows XP machines, and run on ARM too. That's not going to move a lot of Intel CPUs any more. By all reports the WinTel marriage is on the rocks and could be over soon.

In the executive suite Intel's focused on exactly the wrong things: improving what they're doing, not cannibalizing their current markets. That was a good strategy for a while, but it's not going to weather the current changes - as I tried to tell them seven years ago. Now they need something... different.

So now Android runs on X86. That's a good thing. It can run in a VM on your modern Windows desktop in W7 with Microsoft Virtual PC, and give you the Android apps from your phone in a window on your PC. They can share accounts and data in the cloud. HP should have (and I believe planned to) done this with WebOS, but I believe caved when MS explained the consequences. But Intel's focus is still on the widget, not solving the real problem. Android on x86 is just going to move people to ARM faster if Intel doesn't get their software religion under control. This should be dead simple. Intel doesn't sell Windows and they should not care whether Windows lives or dies. They sell platforms, and help software vendors implement those platforms. They need to shift from that to delivering experiences, and controlling those experiences to a limited extent.

There are others without Intel's history and established markets who are ready to solve the real problem. Intel can join them or get out of the way. This is going to happen very fast, so Intel doesn't have forever to dither about figuring out where the road ahead might be.

Re:Power?

[PaladinAlpha]

Processors are not atomic physical units -- or, put another way, the "laws of physics" don't get your software running as anything besides first principles.

Processors are one of the most complicated engineering feats of the human race, and performance characteristics of same are very, very complicated. Even such detailed factors as the relative size of an instruction word in the chosen instruction set have tremendous implications for power consumption and processing speed. In addition, even between processors that most would agree are comparably powerful, a program of given execution characteristics could easily differ wildly in execution time on both.

ARM was designed for efficiency, and so it's reasonable to think that it won't be easily beaten in that field -- but Intel has been designing very good processors for (in IT years) a very long time, and knows the issues and tradeoffs. Nonetheless, marketing materials from Intel based on a reference design do not an answer make, and only deployed, running handsets can answer this question.

Re:Power?

[Anonymous Coward]

True. But did you read what the post you were replying to, which said that ARM Cortex A9 is *faster per clock* than Atom. The Atom is an in-order, dual issue processor with no speculative execution. The Cortex is a reordering dual issue with speculative execution. And the lack of register renaming on the Atom means its 6 general-purpose registers compare particularly badly with the Cortex's 15. Of course it's faster.

Now, OK, the faster A9's I've seen clock at 1.3GHz, compared to the Atom's 1.8GHz, but that means the two are in similar ballparks, and the A9 is *much* cheaper and *much* lower power. And a quad-core A9 typically draws less power (about 1.3W with all 4 cores running flat out) than a single-core Atom (about 2.5W). And there are no quad-core Atoms as of yet, so the A9-based systems (eg Tegra 3/iMX6) are clear winners in total peak performance in a mobile chip.

Re:Power?

[serviscope_minor]

That was my thought too, but according to this chart the E-350 is pretty much on par with D525.

Benchmarks, eh?

This benchmark seems to be very favourable to the atom. Not to say that the benchmark is bad, but YMMV, especially depending on the task. It is possible to squeeze quite a bit of performance out of th atom since it clocks quite fast and can issue two instructions per clock. But lacking out of order execution makes it very hard to keep the ALUs busy, which is why hyperthreading helps relatively more on an atom than fatter intel CPUs.

Nevertheless, OoO can help a huge amount on many tasks.

If you look at the benchmark, the atom 1.8GHz is only a hair below the Core 2 Duo at 1.4 GHz. I have fairly extensive experience with a single core Pentium 3 M (eee 900) and 1GHz atom single core (Toughbook CF-U1). For most things, I found the atom much slower.

Re:Power?

[serviscope_minor]

I hear this thing about instruction compression quite a lot.

On high end CPUs like the core iWhatever, basically the decoder makes little difference. The power budget goes into the massive array of parallel execution units and a honking great out of order register renaming unit to keep the execution units busy. The transistor and power budget for the decoder is minimal.

On lower end CPUs, especially the Atom, ARM and so on, you still need the same size decoder, but now the overall transistor budget is much smaller, so it takes up a much larger fraction of the transistor and power budget.

It certainly does offer some compression, though it is wildly ad-hoc. However, one could essentially replace the decoder with an equivalent number of transistors in the instruction cache. That would probably help a lot. Expecially as the small instructions that do complex things are not favoured by compilers (hard to use) and so little effort has gone into making them fast.

Also, the ARM chips have the thumb instruction set which is purposfully designed to be compressed. It is much less ad-hoc and I would suspect it gives better compression than x86. Also, because it's been designed with compression and simplicity in mind, it doesn't have all of the variable length with evil dependencies nastyness that x86 has.

On the very low end in today's world, you have something like the PIC 12F675 which heroically squeezes a RISCy instruction set into a 14 bit wide bus. Quite entertaining to program as you have to work around the hoops they jumped through for extreme cheapness and low power.

Re:Power?

[serviscope_minor]

Why is this all-day battery-powered thing more capable and responsive than the half-kilowatt new desktop before me?

Really depends on what one is doing. Generally the all-day battery powered things can't do all that much, otherwise they start to loose the all-day thing. I wouldn't dream of replacing one with the other though. The idea of a locked-down single tasking workstation is terrible.

Truth be told I was always amazed that people with a 3GHz dual-core processor just accepted that to get a desktop they should fire it up and go get coffee because they knew it took five minutes.

It's a mix of things. The bootup is slow for three main reasons. The first is that PCs do a lot of stuff before even getting to the hard disk. Things like self-testing, running weird ROMs of random PCI cards probing hardware, firing up USB so you can change BIOS settings, checking RAM, probing disks and so on. I've had workstations before than between the SCSI and network cards could take about 10 minutes to boot. Of course that is all great because it means that they CAN support all the weird and wonderful crap that PCs support.

The second is that the OSs have to do rather careful hardware probing. You can dumo a random linux kernel on a random PC and it will probably boot whatever the hardware. PCs provide a rich mechanism for discoverable hardware that allows for wonderful possibilities for expansion. There is also a lot of cheap hardware thancan do very silly things if you are not very nice to it, so the probing has to be rather conservative.

The final stage is between kexec("/sbin/init") and the desktop (or equivalent). That's generally inexcusably slow. A lightweight system (like my eee) can do that lot in about 3 seconds. People seem to be working on solving the speed problems for fatter systems.

But the first two problems are a blessing and a curse. Devices like phones etc have fixed hardware, and so don't need to do the first two stages in any meaningful manner, massively speeding boot. It also means that a lot of per-system hand hackery has to go into the kernel (and there are some good rants on that topic).

So PCs are slow to boot but you get a lot of benefit for that slowness. But I really don't care much. My laptop comes out of sleep in under half a second. My workstation stays on 24/7. Boot time has pretty much ceased to be a problem.

And your memories of yore are (as is often the case) rather rose coloured. Take, for example my faithful BBC, running at a glorious 0.002 GHz. So you switch it on and...

ZWOOWWW BOOP!

>

booted in about .5 seconds! Great now what? Well, you either have to start typing BASIC, crank out the ole' tape drive or floppy drive and wait a very long time or a bit of time for the software to load.

If you were posh and had a master, then it came with things like an editor in ROM, so you could do ome fairly limited stuff instantly. Well, ASUS motherboards seem to be able to boot to some cut-down desktop Linux before doing most of the biosy stuff, just like that.

But I never use it since I never reboot.

Re:Power?

[hairyfeet]

Totally agreed on the AMD E-350 as that is the reason i finally bought a netbook. After dealing with customers constantly saying "can you make this....I don't know...faster somehow?" and having to tell them that without ION Atom was pretty much a lame duck I avoided the hell out of them until I got to work on a customers E-350 and thought "Hell yeah, this is actually usable!"

As for TFA....why? if you want a killer low resource Linux on X86/64 frankly all you have to do is go buy the AMD E-350 based EEE (don't know if they have it on the Atom) and enjoy expressgate. Instant on, adds a couple of hours to the battery, at least for me, nice GUI, its all easy peasy. If the community would just get behind expressgate/splashtop and be writing apps for it frankly i could easily see the fabled "year of the Linux desktop" meme becoming reality.

If you want to beat MSFT the trick is NOT to try to get rid of Windows, its to go around it. With EG/ST they still have windows if they need it but as they play in EG/ST and if the community backs it I could easily see them not really needing to go back to Windows much. It already plays most media, has a nice book store and piles of radio stations, all it needs is more apps and games and you could slowly but surely wean users off constantly needing Windows.

Re:Power?

[Hast]

One alternative use for this is to use it as a "simulator" for developing Android applications.

The emulator that is included in Android SDK really emulates ARM code (it's actually running QEMU with ARM v5 code). The problem with this is that it's rather slow, even on high end computers. Anything that runs opengl is extremely slow and not usable.

The Android X86 project makes it possible to run Android in eg VirtualBox. You can then test applications in a much better environment. (Well, currently OpenGL still doesn't work, but it's a work in progress.) Since this is actually running the full Android environment, but compiled for X86, it's possible to get pretty close to real Android behavior on the system.

So that's one nice benefit of the system. Otherwise I imagine that it could be useful to run Android on an old netbook which has problems running a full OS. (And to be frank, many netbooks with Atom seems to have this problem. At least mine does.)

Re:Power?

[TheRaven64]

Thumb-2 is very dense. All of the ARM instructions that common compilers generate are there. There are several other things about ARM that make it better for low-power systems:

16 registers and no register-limited instructions mean that you have far fewer register-register moves than in x86 (the x86 register-memory instructions offset this somewhat). This is one of the big improvements that x86-64 brings to the table.

Predicated instructions mean that you can avoid a lot of short branches. This is great on a pipelined superscalar chip - you execute all instructions and just don't retire the results on the ones that shouldn't have been executed. This means that ARM chips need a less complex branch predictor to get similar performance to x86. Less complexity means lower power. ARM didn't even bother with branch prediction until a few years ago.

A single instruction format. Both ARM and Thumb2 have very simple layouts. Decoding an ARM or Thumb instruction is really easy. The Thumb-2 decoder is about as complex as the micro-op decoder in an x86 chip.

ARM and thumb instructions are fixed length. This means that you never get an instruction spanning multiple cache lines. On x86, you'll often see compilers insert no-ops to ensure that you won't see this problem.

There are also some very dense instructions. The load / store multiple instructions, for example, let you push and pop an arbitrary subset of the registers. Saving all of the caller-save (or all of the callee-save) registers is a single ARM instruction. This means that you can have very small function prologs and epilogs in ARM code. In fact, you can implement setjmp() and longjmp() with a single ARM instruction too.

Load and store instructions that make address computation easy and support addressing relative to any register. This makes library code (which needs to be position independent) a lot denser on ARM than x86. On x86 you need to call and then pop to get the current instruction pointer, and then you can use this value (in another register, costing you one of your four approximately general-purpose registers) as a base for address computation. With ARM, you just do a ip-relative load (and ARM loads let you do things like r1 + r2 << 4 in a single instruction, so you can store an array start in r1, an index in r2, and access array elements in a single instruction).

In terms of compression, I implemented the same function recently for ARM, x86-64 and x86. The sizes of the text section from the assembled versions were:

• ARM: 360 bytes
• x86-32: 471 bytes
• x86-64: 651 bytes

The 64-bit version is slightly more complicated, but only very slightly (the extra complexity is about 4 instructions, the rest is the same).

Re:Power?

[robthebloke]

One of the biggest myths in the industry, and one that is not exactly true. If you specifically select "Optimise for Intel i7", then guess what, it only runs on an i7. If however you specify the option to optimise for all platforms (/QxO) you'll have no such problems with AMD chips. The Intel compiler can be instructed to insert two codepaths into an exe. So you can have one specified as /QxO, and a separate codepath for i7. At startup, the app will indeed check for the intel vendor string, and will check to see if it's an i7. If it doesn't find it, it will run the codepath optimised for all processors, rather than the one specifically for the i7. In this regard there is absolutely no difference to running the exe on a Core2, or an AMD chip. In both cases the exe will run the second codepath. The problem only arises if the developer has simply chosen one codepath (or failed to select an optimised codepath for the second one, which could indeed look like a deliberate retardation of performance to a layman).

So the complaint about the CPU dispatcher basically boils down to this: Why does specifying "Optimise for Intel i7" mean exactly that, rather than "Optimise for any CPU supporting the same features as an i7". I can't answer that, and I'd certainly prefer the latter, however it is information that is clearly documented.

To be fair, you have a valid point about rigged benchmarks, but your reasoning is entirely incorrect. The simple fact is that the ATOM is significantly different enough from other x86 processors as to make any comparative benchmarking entirely redundant. You either compile a binary explicitly for ATOM (and it runs quite well), or you choose a general x86 compiler option (and it runs like a dog). Most benchmarking software will not have been compiled with the ATOM in mind, so chances are it will run like a dog, making the processor look worse than it actually is....

Samsung Slates

[exomondo]

Presumably this would work on existing tablets like Samsung's series 7? The ones similar to (or maybe the same) as those that were given away at BUILD.

Emulator?

[mustPushCart]

Does this mean i can run the apps natively without using an emulator on a windows box?

Re:Emulator?

[Hast]

There is a guide for Android X86 on VirtualBox on their wiki (http://www.android-x86.org/documents/virtualboxhowto).

I've tried Gingerbread and Honeycomb before and they work reasonably well. (OpenGL isn't well implemented yet, so Honeycomb and likely ICS will have some performance problems.) I haven't tried to use them as emulator replacements though, not sure how much work it is to actually make it possible to get ADB working with Android X86 in VirtualBox.

Just make sure you disable "Enable absolute pointing device" in the VirtualBox motherboard settings to get the mouse to work.

Previously I've used the Eee PC build of Android to get it to work, I haven't tried getting the ICS port to work in VB yet (there isn't a Eee PC build of it yet).

Desktop Distro?

[datavirtue]

I vote for a desktop distro. I take back everything I've said about LibreOffice, I shouldn't have judged it by its stupid name. I discovered that it can use .docx the other day, I was somewhat shocked since that was the only reason I was hanging onto MS Orifice, which, as pretty as it is, is getting quite annoying these days. I would definitely try an Android desktop distro! I've been using Mint 12 for a couple of days and I'm still experiencing quirky behavior. It was pretty bad with Gnome 3, and MATE is not much better, oh well, back to Gnome Classic (No Effects). Installing an Android desktop would be like Christmas morn. It would be oh so sweet to see laptops available "like your phone" for consumers....with free Microsoft compatible office software!!

Re:Desktop Distro?

[jamesh]

I vote for a desktop distro. I take back everything I've said about LibreOffice, I shouldn't have judged it by its stupid name. I discovered that it can use .docx the other day, I was somewhat shocked since that was the only reason I was hanging onto MS Orifice, which, as pretty as it is, is getting quite annoying these days. I would definitely try an Android desktop distro! I've been using Mint 12 for a couple of days and I'm still experiencing quirky behavior. It was pretty bad with Gnome 3, and MATE is not much better, oh well, back to Gnome Classic (No Effects). Installing an Android desktop would be like Christmas morn. It would be oh so sweet to see laptops available "like your phone" for consumers....with free Microsoft compatible office software!!

I wonder if one day we'll see MS Office sold with "Compatible with Google Apps" on the box...

Re:Desktop Distro?

[clarkn0va]

Well i guess that settles the question of what a chatbot with ADHD might say after reading the entire history of /.

BlueStacks

[Namarrgon]

You could already do that.

Well, more or less. It's a port of the Android libraries to a Windows JVM, which is sufficient to run many/most Android apps (much like what RIM are doing). It's not a port of Android itself. But it does run Android apps in windows on your desktop (or fullscreen).

Re:So 2012 is the year of Linux/Android desktop?

[Tr3vin]

This was a direct response to Windows 8 on ARM.

Not quite. There have been projects adding x86 support to Android since 2009. There have even been devices that used x86 chips, such as the Cisco Cius. This move is more along the lines of Google supporting as many chips as possible to open up the opportunities for manufacturers and developers. So far, the focus has been on ARM chips since they are low power and well suited for mobile phones.

If anything, Windows 8 is on ARM as a direct response to Android and iOS.

Re:So 2012 is the year of Linux/Android desktop?

[0123456]

Every build of Android since, as I recall, 1.5, has been ported to x86. It's part of Intel's (silly) strategy to put Atoms in cell phones and tablets.

I'd like an Atom in my cellphone. Then I could use it as a hand-warmer in the winter.

This is not what the singularity is

[symbolset]

It's called a singularity because like the singularity of a black hole it's impossible to see what's beyond it. We can see what's beyond this: more progress and more competition. More diversity, more sales, more fitness of technology to our human needs. More connectivity between people.

We've gone beyond moving the buttons around on the word processor to sell it again to the same people who bought it before. But we can still see the future from here and it looks grand.

The Singularity is an even bigger deal, and further out.

Re:Misleading title

[BluBrick]

Intel! Make me a sammich!

Ah-ah-aah! You didn't say sudo.

The CISC vs RISC issue is dead

[symbolset]

Don't mix your memes.

Long ago CISC vendors implemented RISC as a sublayer, and the two merged. This flamewar is officially over.

The 4+1 thing is a different flamewar: SMP vs AMP (Asymmetric vs Symmetric MultiProcessing). This one is still hot because AMP is fairly new. I'm a big fan of AMP, but the SMP camp is rightly concerned about complexity of compilers and tools, race conditions and what not. Too soon to tell, but here's a thing: we dealt with the transition to 486 pretty well, and that was a merging of heterogeneous cores - a processor and a math coprocessor. We integrated GPUs and physics coprocessors pretty well, and I/O offloading too. I think we'll weather this change and come out the other side for the better. But the outcome remains uncertain. The problems involved are certainly challenging.

Re:Interesting

[TheReaperD]

Google stated that they intend the two codebases to merge at some point in the future. They wanted to start at the two ends and meet in the middle. So, it's not so much a death as an assimilation.

If I run this on VB...

[tombeard]

Can I spoof Carrier IQ?
What is it when you feed fake data to someone stealing/selling your personal business; we need a new word?
In any event, here's to poisoning the cache.

Re:When will the Linux layer be replaced another O

[brian.swetland]

By Google? Highly unlikely that we'd ever do that. We're pretty heavily invested in the Linux kernel and it's been working well for us in Android.

By some other entity? Could happen, but the mid and lower layers of the Android stack depend pretty heavily on running on a Linux kernel. It'd be a bunch of work for questionable gain.

hmm...

[justforgetme]

x86 never was a champ in power efficiency. It excels in instructions (performance) though, that's why it has come to dominate the "productive computing" market. The architectures Android was tailored towards both in backend and in api were designed and utilized with instruction frugality and hardware limitations in mind.

Making Android available on the much more powerful x86 ecosystem and its hardware net is counterproductive at best. Why imped a device with the limitations of a toy OS when you can utilize a complete desktop environment?

Re:hmm...

[Rennt]

Who said anything about desktops? Intel's idea is to get x86 into the Android mobile device market. Not Android into the traditional x86 market.

Re:hmm...

[somersault]

It's strange to be being sarcastic to someone rebuffing your original post, as that implies that your whole first post was stupid..

Re:hmm...

[Joce640k]

The architectures Android was tailored towards both in backend and in api were designed and utilized with instruction frugality and hardware limitations in mind.

Is that why they used Java?

Re:hmm...

[TheRaven64]

They use Java, but not for anything performance critical. The rendering GUI are all C/C++ and they use an LLVM-based DSL compiler for things like animations. Most of the time the Java code is either sleeping waiting for user action or calling into non-Java code.

Re:hmm...

[TheRaven64]

Eventually, but usually indirectly. For example, you write some Java code for compositing an image or drawing a line on Android - most of the time that's executing it will be in the Skia library, not in the Java code.

Android native on every computer ASAP

[IGnatius T Foobar]

Listen, Google: I know you and Intel want Android running on x86 in order to diversify the ecosystem, and that's all well and good, but there's something you need to do as quickly as possible.

You need to get Android apps running on every desktop computer, at the same snappy speed they run on cell phones.

Microsoft is looking to sneak this in the back door by forcing Windows 8 users to become Windows Phone users. You can counter this by putting a full Android runtime into Chrome, and perhaps even making it dockable in Linux/Mac/Windows as well. With the full catalog of Android apps available on every desktop, Android will become the de facto new standard operating system for everything, everywhere.

Do this now. Before Microsoft does.