Slashdot Mirror
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."
All major processors except Itanium use microcode, including most ARM implementations. It's not an x86-specific thing.
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."
"A person is smart. People are dumb, panicky dangerous animals and you know it." - K
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
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.
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.
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.
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.
SJW n. One who posts facts.
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).