Intel port Android 3.0 naar x86-architectuur

Intel werkt aan een port van Android 3.0 voor x86-processors, zodat er tablets met Atom-processors en het OS van Google kunnen verschijnen. Bovendien wil het bedrijf met zijn cpu's snel de overstap naar 22nm en daarna naar 14nm maken.

Intel heeft bij de presentatie van zijn jaarcijfers, tijdens een vraaggesprek waarin onder anderen ceo Paul Otellini het woord voerde, meer bekendgemaakt dan alleen de financiële resultaten. Die logen er overigens niet om; het bedrijf heeft in het eerste kwartaal van 2011 opnieuw een recordomzet en winst behaald. De omzet bedroeg 12,8 miljard dollar, met een winst van 3,2 miljard dollar. Vooral de introductie van het Sandy Bridge-platform droeg bij aan die resultaten, waarbij veel is verdiend op markten als China, Oost-Europa en Zuid-Amerika. Ook in de toekomst moeten die gebieden veel groei mogelijk maken, zo verwacht de chipfabrikant.

Intel heeft een aanzienlijk deel van zijn uitgaven besteed aan de uitbreiding van de ontwikkelfab voor het 14nm-productieprocedé. De transitie naar 22nm is weliswaar eerder aan de orde, maar Intel wil in een vroeg stadium een groot deel van het portfolio op 14nm gaan produceren. In het verleden werden vooral de high-end producten naar nieuwe nodes gebracht, waarna de midden- en lage segmenten in een later stadium volgden. Over enkele weken zou Intel 'revolutionaire' features van het 22nm-procedé bespreken, terwijl volgens de planning de overstap naar 14nm nog altijd twee jaar later zou plaatsvinden.

Naast de processors voor laptops en desktops tracht Intel ook draagbare apparaten aan te drijven. Vooral tablets en smartphones zouden van x86-processors voorzien moeten worden, maar vooralsnog bleken Atoms daarvoor weinig gewild. De op 32nm geproduceerde Medfield-Atoms moeten daar volgens het bedrijf verandering in brengen. Al tijdens Computex, begin juni, wil Intel een flink aantal tablets, zo'n 35 voornamelijk op Android-gebaseerde ontwerpen, met Intel-processor laten zien. "We hebben de Honeycomb-versie van de Android-code van Google ontvangen en werken actief aan een port", vertelde Otellini. In de loop van het jaar zouden Atom-tablets met Android Honeycomb moeten verschijnen, verwacht hij.

Ook telefoons zouden binnen een jaar verkrijgbaar moeten zijn, verwacht Intel-ceo Paul Otellini. Die zouden vooral voor telecombedrijven geproduceerd worden en tevens 32nm-Medfields aan boord krijgen. Bovendien verwacht Intel dat besturingssystemen voor mobieltjes relatief eenvoudig van de huidige ARM-architectuur naar Intel-processors geport kunnen worden.

Reacties (65)

[CyBeR]

Leuk idee, maar is dat wel nuttig? Volgens bij doet Atom nog altijd een stuk minder zuinig met energie dan ARM ds dan moet je een flinke batterij meeleveren voor een redelijke battery life.

[knirfie244]

Dan heb je je duidelijk nog niet ingelezen in de techniek achter Moorestown, Medfield en de opvolgers.

Met volledige clock en powergating, en het laten vallen van wat legacy (zoals PCI, en bepaalde timers die voor Windows/Dos nodig zijn) is de Atom extreem zuinig te maken. Er is weinig dat x86 tegenhoudt om dezelfde prestatie/watt te bieden als ARM.

Overigens is het niet zo bijzonder dat Intel aan Android 3.0 voor x86 werkt, ze hebben eerder ook al andere Android versies geport. Wat me echter wel een beetje verbaasd is dat ze niet meer samenwerken met AMD op dit gebied, gezien AMD ook tablet plannen heeft voor de Brazos familie. Nu kan AMD straks gratis/goedkoop (nog een klein beetje optimaliseren voor Brazos) meeliften op het werk van Intel.

[Reactie gewijzigd door knirfie244 op 23 juli 2024 00:30]

[Verwijderd]

Met volledige clock en powergating, en het laten vallen van wat legacy (zoals PCI, en bepaalde timers die voor Windows/Dos nodig zijn) is de Atom extreem zuinig te maken. Er is weinig dat x86 tegenhoudt om dezelfde prestatie/watt te bieden als ARM.

Dit is iets wat al lang geroepen wordt. Maar er is nog steeds geen echte ARM concurrent.

Daarbij wordt de ARM veel sneller ontwikkeld omdat er veel meer partijen zijn die deze processor licenseren en produceren.

Kijk maar naar de performance winst van de ARM11 t.o.v. de Cortex.

[Verwijderd]

Dan heb je het nog over de A9 terwijl de opvolger op papier volgens mij al af is.
De ARM Cortex-A15:
http://www.arm.com/produc...s/cortex-a/cortex-a15.php

Schijnt ook weer qua performance flink boven de A9 te stijgen. ARM heeft dus goeie ontwikkelingen. ARM groeit in performance zonder veel te verliezen op efficiency. Dit is een winnende factor omdat de batterij industrie namelijk niet erg hard gaat!

En je ziet dat veel OSen overstappen op ARM. Zo ook Windows. Is dit niet een soort noodkreet van Intel van. Wacht even jongens!! Ons x86 kan ook Android !!

Nee.. lijkt wel alsof intel beetje benauwd begint te krijgen van ARM.

[Niles]

Natuurlijk wil Intel niet blijven toekijken naar de gigantisch grote (en nog altijd groeiende) markt van smartphones en tablets. ARM doet daar nu erg goede zaken en Intel zal zeker balen dat ze daar toch min of meer de boot hebben gemist.

Aan de andere kant is Intel natuurlijk wel hét bedrijf dat de resources en het kapitaal heeft om binnen een relatief korte tijd een compleet nieuw platform op de markt te zetten (en dus de verloren tijd in te halen). Als Intel er echt werk van gaat maken ben ik er van overtuigd dat intel x86 energiezuinig genoeg kan maken zodat het concurrerend is voor de ARM chips. Misschien is deze port dus wel een test voor wat er achter de schermen allemaal al ontworpen is

[Reactie gewijzigd door Niles op 23 juli 2024 00:30]

[Verwijderd]

Zal dit niet worden gelicenseerd door Intel? Aangezien Intel de port maakt en dus Android 3.0 x86 hun software is.

[zeduude]

tis en blijft gpl.. (en apache license)

(wijziging : te laat gelezen paar posts hieronder)

[Reactie gewijzigd door zeduude op 23 juli 2024 00:30]

[latka]

x86 is veel complexer dan ARM, dus meer transistoren dus minder zuinig. Natuurlijk zet je dingen die je niet nodig hebt uit, maar als er gerekend moet worden heb je dus meer transistoren nodig.
Waar intel het wel op kan winnen is productie faciliteiten, niet veel CPU bakkers kunnen zo klein bakken als intel met allerlei voordelen vandien. Maar het probleem hiervan is dat iedereen dit op termijn kan, dus dan is ARM op hetzelfde process als x86 nog steeds eenvoudiger en dus zuiniger.

[Patine]

De atom is per clock zuininger dan arm, je hoeft hem dus alleen maar onder te clocken. Probleem van de atom is de chipset, die verbruikt relatief veel stroom, maar ik neem aan dat intel hier aan werkt om, bv, bij de tijd dat android geport is er een enrgiezuinige chipset op de plank ligt.

[Verwijderd]

Hier een een link.

En deze link.

The n450 SOC and the NM10 companion chip(set) still works in a 6.5w TDP while the dual-A9 SOCs are expected to work in a 2W TDP. This is massive difference and makes it likely that the same battery will last much longer with an A9 smartbook than with an N450 netbook.

Zie ook deze link.

[Laptom]

Volgens mij klopt het niet geheel wat je zegt. ARM architectuur is extreem zuinig in vergelijk met de ATOM.

Daarnaast zegt het niets over energie per clockcycle.... Geldt hetzelfde als voor performance per clock cycle.
Het zijn 2 totale verschillende architectuurs en niet zomaar te vergelijken.

[_Thanatos_]

Natuurlijk zijn ze te vergelijken. Het zijn beide in essentie CPU's die gewoon dom rekenwerk verrichten. Daar kun je een generieke benchmark op loslaten en aan een performance-rating komen. Dat kun je dan weer omrekenen naar performance-per-watt.

[Verwijderd]

Maar zoals worldcitizen zei... er zijn geen x86 cpu's die op een 2W TDP werken. Dus intel moet nog hard aan het werk. Dus ARM zit nog steeds in een heel ander gebied te werken dan X86.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 00:30]

[_Thanatos_]

TDP is juist precies wat je niét moet vergelijken. TDP is niet het maximale vebruik. Bovendien gaat het om, zoals ik al zei, over de performance-per-watt (en die watt meet dan ipv de TDP af te lezen). Zo kun je misschien best aan een x86/64 CPU komen met een gelijke (zo niet hogere) performance per watt dan een ARM CPU.

"2W TDP" roepen zegt in ieder geval niets.

[Left]

Dus de overstap naar 14nm is kennelijk al geen probleem meer ..

Is er al iets bekend over de volgende stap, 10nm? Ik kan me namelijk wat verhalen herinneren dat er met 15nm een grens bereikt zou worden waarbij normale chipfabricage processen niet meer zouden werken. Maar die grens begint nu wel heel dicht bij te komen ..

[Hakulaku]

Als dat het geval was zouden ze denk ook niet naar 14nm kunnen gaan?

Daar zullen ze waarschijnlijk al iets voor verzonnen hebben.

[Kahlan]

De gangbare litho-technologie gebruikt licht van 193 nm en dat gebruiken ze al een tijdje om patronen af te beelden die kleiner zijn dan de golflengte van het licht. Truuks als immersie (vanwege de hogere brekingsindex) en double-patterning helpen daar dan bij.

Blijf dat toch apart vinden, met mijn theoriekennis van Niquist dacht ik dat het helemaal niet kon, wat ze bij ASML doen. Maar het licht is zo mooi gepolariseerd dat ze, in combinatie met op de juiste manier vervormde reticles (de dia die geprojecteerd wordt op de chip) op de interferentiepatronen kunnen belichten. Daarmee kom je ver.

Daar zullen ze waarschijnlijk al iets voor verzonnen hebben.

Dat heet EUV. Alleen heeft ASML nog wat moeite om dat productierijp te maken. EUV is 'licht' op een golflengte van 13.5 nm, en dat is dus klein genoeg om patronen te belichten van 14nm (gezien het bovenstaande). De "euv-lamp" is momenteel het grootste probleem; die geeft te weinig "licht".

[roland83]

Ik ben wel benieuwd of ze de sourcecode zullen vrijgeven, of dat Google toch echt afstapt van het open source idee. Verder een goede ontwikkeling!

[Robinski]

Waarom zouden ze afstappen van het open source idee?

Het lijkt mij dat als er een Android versie komt welke draait op x86 hardware, dat hiervoor ook de code beschikbaar moet komen. Overigens is Android bovenop een linux kernel gebouwd, dus grote kans dat er niet eens heel erg veel aangepast hoeft te worden om een en ander ook onder x86 werkbaar te krijgen.

[roland83]

Ik zou geen goede reden weten voor Google om af te stappen van open source-software. Ik ben er alleen bang voor, omdat ze de sourcecode van de nieuwe Android ook nog niet hebben vrijgegeven. En dat hadden ze wel beloofd.

[Supremo]

De reden dat Honeycomb nog niet vrijgegeven is door Google aan het publiek, is omdat Google niet wil dat partijen Honeycomb op mobieltjes gaan zetten. Honeycomb is bedoeld voor tablets.

Ik ben ook niet blij met deze situatie, maar Google heeft al aangegeven dat Honeycomb uiteindelijk vrijgegeven wordt aan het publiek. Dit zal waarschijnlijk op het moment zijn dat bijvoorbeeld Ice Cream uitgebracht zal worden, of dat Honeycomb geschikt gemaakt is voor mobieltjes.

Dit is dus slechts een tijdelijk probleem en Google vaart geen wezenlijk andere koers wat betreft open source.

En zoals je uit dit artikel hebt kunnen lezen levert Google de source code van Honeycomb wel aan "vertrouwde" leveranciers. Ik denk dat Google "vriendelijk" gevraagd heeft aan Intel om Honeycomb niet voor mobieltjes te gebruiken.

In plaats van je zorgen te maken had je je ook gewoon beter in de materie kunnen verdiepen.

[Verwijderd]

Icecream is een combinatie van een nieuwe Android versie voor mobieltjes en de tablet versie.

Dus een samengesmolten versie. Hierdoor bestaat er geen aparte tablet versie of telefoon versie.

Android zelf moet dan detecteren of het een tablet is of een telefoon. En dan hieruit kiezen of hij zijn telefoon aard weergeeft of zijn tablet aard weergeeft.

Dit is de reden dat honeycomb een apparte versie is en ze willen geen twee verschillende versies als source code uitbrengen. Vandaar de commentaar dat Honeycomb niet af zou zijn. In principe is hij niet echt af.. maar het tablet gedeelte wel.

Icecream kan dus zowel op een tablet als op een telefoon draaien. En hiervan wordt wel de source vrijgegeven!

[ChrissieOne]

staat ook een bericht over hier op tweakers, over het waarom. Het wordt dus uiteindelijk wel vrijgegeven, als 3.0 er ook voor mobieltjes is.

[Wirf]

Als google afstapt van het open source idee, dan zullen ze eerst de hele Linux kernel waarop Android deels gebaseerd is moeten herschrijven.

De Linux kernel is namelijk GPL, en daarom moeten afgeleide werken ook onder de GPL vrijgegeven worden.
Doe je dat niet, dan worden namelijk de vrijheden die je gegeven zijn door de GPL weer ingenomen, dus dan ben je een copyright-schender van het copyright dat op de Linux kernel zit.

[MsG]

Hoe zit dat op dit moment dan? Aangezien Android grotendeels onder de Apache-licentie valt en niet de GPL.

[Sebazzz]

Android zelf valt misschien onder de Apache license, maar dat zijn de binaries en programma's en het framework van het OS. Niet de kernel zelf. Het is dus geen afgeleid werkt oid.

[PPie]

Niet alle programma's van Android zijn open source.
De delen die Google levert om er 'Google Android' van te maken (GMail, Maps, Talk, Market, etc), zijn closed source.

[poepkop]

Klopt, in theorie zou je dat als fabrikant eruit kunnen strippen en een fork kunnen maken, wat je daar mee opschiet is een 2e vraag.

[LemonC200]

Volgens mij is het beter om te investeren in de ARM architectuur. Dan proberen het vlaggenschip x86 instant te houden. Als windows 8 ook al op ARM gaat draaien...

[ValHallen]

Ga je hier niet met backwards compatibiliteit zitten met de huidige software?
(tenzij iedereen over gaat naar ARM uiteraard)

Persoonlijk gezien lijkt het mij beter om juist meerdere architecturen aan te houden, om zo een betere concurrentie te stimuleren/

[watercoolertje]

Bij windows ga je inderdaad geen software draaien die voor x86 is geschreven, bij Android maakt de architectuur niet zo veel uit, enkel voor de Virtual Machine, als de VM op een architectuur draait doen de apps het ook

[Stukfruit]

Niet helemaal. Veel apps maken gebruik van native code en die bibliotheken zijn toch echt voor ARM gecompileerd. Zo zal bv. Angry Birds zoals je die nu in de Market kan vinden niet zomaar op x86 draaien. Daarvoor zullen de makers eerst een x86-versie van de bibliotheek met native code moeten meeleveren in de APK.

[Verwijderd]

Het lijkt mij dat Angry Birds (ik ken het hele spel alleen van naam) in een hogere programmeertaal is geschreven en met bepaalde standaard bibliotheken werkt om zijn ding gedaan te krijgen. Als Angry Birds direct hardware aanspreekt dan is het of super geoptimeerde code of gewoon oer-dom geprogrammeerd (meestal geldt in zo'n situatie het laatste). Zodra de standaard bibliotheken zijn geport naar Intel dan is het, voor een spel zoals Angry Birds, een kwestie van opnieuw compileren of in het geval dat er gebruikt van van een Virtual Machine (zoals in Java of .net) is dit niet eens nodig.

[Stukfruit]

We hebben het hier over eigen bibliotheken. Native code die je onder Android wil uitvoeren zit in een bibliotheek die je moet laden via Java of (in Gingerbread en hoger) via het manifest.

Het is dus inderdaad een kwestie van opnieuw compileren (en gezien de platformen die ze nu al met dezelfde codebase ondersteunen zal dat vast niet moeilijk zijn), maar dit moet wel door de eigenaar van de specifieke app gebeuren omdat zulke bibliotheken (met de functionaliteit van in dit geval een spel) niet standaard met Android worden meegeleverd. En daar zit dan gelijk je denkfout

Rovio gebruikt overigens een eigen game engine met Box2D voor de fysieke eigenschappen van objecten, eigen versies van ZLib, libpng, enz. Allemaal C/C++. Direct de hardware aanspreken kan (als 3rd party ontwikkelaar) niet, dat gaat in het geval van de graphics via OpenGL ES.

[Biersteker]

Angry Birds is al beschikbaar voor x86 trouwens.

[Stoney3K]

Ga je hier niet met backwards compatibiliteit zitten met de huidige software?
(tenzij iedereen over gaat naar ARM uiteraard)

Dat is voor Apple toch ook nooit een probleem geweest? Op OSX heb je Rosetta als emulatie-laag voor PowerPC applicaties en dat werkt net zo goed als een trein. En een x86 emuleren kunnen we al lang en breed, kijk maar naar systemen zoals VirtualBox die net zo goed op een andere architectuur draaien.

Bij windows ga je inderdaad geen software draaien die voor x86 is geschreven...

Windows 7 heeft al een x86 emulator ingebouwd in de vorm van de XP-mode. Kwestie van porten naar ARM en je bent klaar.

[Reactie gewijzigd door Stoney3K op 23 juli 2024 00:30]

[Wim-Bart]

[...]
Windows 7 heeft al een x86 emulator ingebouwd in de vorm van de XP-mode. Kwestie van porten naar ARM en je bent klaar.

Dit is geen emulator maar gewoon een native draaiend OS onder een Hypervisor. Dus een "Virtuele" machine. Alleen de hardware laag wordt "geëmuleerd". Hoewel dit ook niet meer is dan een simpele interface tussen "guest os" en "host os drivers".

Echte Emulatie kennen we alleen maar in de vorm van Z80, 6502, 68000 en andere CPU''s op niet de zelfde architecturen. Bijvoorbeeld een Comodore 64 emulator op een Windows machine.

[Wolfos]

Als alle apps overal op zouden draaien was de massa ook wel naar Linux overgestapt. Windows voor ARM word geen success, want dat is dezelfde ongebruikersvriendelijke omgeving maar dan met 0 applicaties.

[harrydg]

laten we hopen dat alles binnekort op de ARM architectuur werkt. Steekt ongeveer op alle gebied ver boven de intel architectuur uit.
just my 2 cents...

[borft]

al es van high performance computing gehoord?

ARM is leuk voor low power, low performance en embedded toepassingen, maar ik wil de eerste arm cpu nog zien die het wint van een good old I7 op 3.5GHz

[Mellow Jack]

Laat ARM 10 jaar mee draaien in de desktop markt en je hebt dezelfde problemen als X86 op dit moment heeft... ARM heeft het jaren super makkelijk gehad maar krijgt het nu steeds lastiger en lastiger (zie ook het aantal extra onderdelen de SOC nodig heeft)

[WPN]

Dus intel port android naar x86 en haalt daarmee tablet bouwers binnen voor hun processor

dus hoe zit het met updates?
Google brengt update uit, deze moet eerst door intel gechecked/geport worden, dan gaat deze naar de tablet bouwer voor zijn test/aanpassingen en dan pas naar de klant.... hoe lang gaat hierover heen?

[Sebazzz]

Het is waarschijnlijk dat intel x86 aanpassen de source tree weer induwt. Zo werkt het bij veel opensourceprojecten.

[WPN]

google moet dit dan weer controleren natuurlijk. Dus dan duurt het alsnog verdomd lang voor een update alle lagen door is gegaan.
Kan google beter een xx aantal devellopers voor x86 development inhuren en deze met een specialist van intel direct bij google laten werken

Neemt natuurlijk niet weg dat het opzich een leuke ontwikkeling is om multi-platform OS te krijgen, gezien het dan ook de weg opent naar installaties op laptops en netbooks met x86 processoren welke wat makkelijker te krijgen zijn voor de tweaker...

[Verwijderd]

Om eerlijk te zijn. Weinig interessants anders dan dat we Android op X86 kunnen gaan gebruiken. Ik hoop alleen eerlijk dat we Android ook op een niet Intel mogen draaien. Daar de AMD Brazos een heel veel beter alternatief is voor de Atom. Net zo zuinig. Meermaals zo snel.

_{Mompelt iets van Out of Order Execution die intel weigert te implementeren wegens kostenbesparing}

[Reactie gewijzigd door Verwijderd op 23 juli 2024 00:30]

[elzes]

heb je ook geluk zijn er al mee bezig

http://tweakers.net/nieuw...roid-tablets-brengen.html

[elzes]

Er is toch duidelijk genoeg bericht waarom 3.0 nog niet werd uitgegeven aan de vrije markt.

http://tweakers.net/nieuw...ycomb-niet-vrijgeven.html

[Reactie gewijzigd door elzes op 23 juli 2024 00:30]

[mashell]

Dat bericht is inderdaad duidelijk. Maar het kan natuurlijk nog steeds een volstrekte drogreden zijn.

[elzes]

maar klink wel logisch als "azie" slechte ervaringen krijgt zakken ze wel weg.

Maar inderdaad eerst zien..

[Verwijderd]

Allemaal goed en aardig, maar de marges op ARM zijn flinterdun.

Als Intel daaraan mee wil doen moet hun business model om. Van beste tot concurrerend op prijs. Dat lijkt me waanzin als ze zulke marges kunnen maken op de desktop. Dat is nogal een spagaat voor een organisatie.

En tuurlijk, je kan proberen allebei te doen, maar hoe je het wendt of keert, het is productie capaciteit die je gaat alloceren. Daarnaast heb je nieuwe verkoopkanalen e.d. nodig.

Dit wordt helemaal geen eenvoudig project.

[Minaaj]

Dit is heel mooi, stel je voor een Media Centre op android, waar je tevens ook op kunt browsen, films afspelen in HD.

Emails ontvangen, widgets op je TV, wifi keyboard oid. Zie het al helemaal voor me.