Intel en MIPS willen Android 4.0 op hun processors laten draaien

Intel en MIPS hebben gezegd dat zij Android 4.0 willen porten voor processors die gebruik maken van x86- en MIPS-architectuur. Google heeft zijn nieuwe Android-versie ontwikkeld voor op ARM-gebaseerde processors.

Dat laten beide bedrijven weten aan ComputerWorld. Volgens Intel bevat Android 4.0, dat als codenaam Ice Cream Sandwich heeft, optimalisaties voor x86-architectuur. Hierdoor kan de nieuwe versie van het mobiele OS gemakkelijk draaien op Intels processors, ondanks dat Google zich bij de ontwikkeling op ARM-architectuur heeft gericht. Android 4.0 is gemaakt voor Omap4-processors van Texas Instruments. Intel zou met de Android-maker hebben samengewerkt voor x86-ondersteuning, waarbij de eerste smartphone met een dergelijke chip in de eerste helft van 2012 op de markt wordt verwacht.

MIPS Technologies, ontwikkelaar van de MIPS-instructieset voor processors, heeft aangegeven Android 4.0 te zullen porten naar zijn processors zodra Google de broncode openbaart. Daardoor zal het bedrijf nog even moeten wachten, omdat de internetgigant deze pas vrijgeeft nadat de Samsung Galaxy Nexus met de nieuwe Android-versie op de markt is. Het bedrijf zegt slechts 90 dagen nodig te hebben voor de benodigde modificaties om Android ICS op MIPS-processors te laten draaien, omdat de nieuwe versie van het OS veel weg heeft van Honeycomb. MIPS werkte al aan een port van deze versie naar zijn processors.

Het eerste toestel met Android ICS, de Galaxy Nexus van Samsung, draait op een OMAP4460 van Texas Instruments, die op een ARMv7-instructieset is gebaseerd. Deze tweekernige soc doet zijn werk op een kloksnelheid van 1,2GHz. De smartphone wordt naar verwachting binnenkort uitgebracht in Nederland.

Reacties (66)

[TD-er]

Het porten hoeft toch ook niet zo heel veel werk te zijn?
Kwestie van alle processor-specifieke optimalisaties opsporen en kijken of dat net zo goed geoptimaliseerd kan worden voor de nieuwe architectuur en opnieuw compileren.
Het meeste ervan zal in de kernel voorkomen vermoed ik en daarvan is voor het grootste deel toch al een kernel te maken voor dat MIPS platform.
Zo heel veel zal Google er niet aan veranderd hebben.
Die 90 dagen lijkt mij dus helemaal niet zo gek en misschien zelfs wat ruim.

[taeke18]

Je kunt dit gaan doen, maar het makkelijkste en goedkoopste voor Google is het optimaliseren voor alleen ARM. Als tweede zit je er mee dat het compleet andere architecturen zijn. En de x86 is niet 1 architectuur het zijn verschillende. De x kan ingevuld worden met verscheidene getallen. Om 2 voorbeelden te geven heb je de bekende 386 maar je hebt bijvoorbeeld ook de 686 architectuur. Dit zijn allemaal modificaties o de x86 architectuur dat als oorsprong bij de 8086 vandaan komt.
momenteel bevinden we ons in de 9e generatie van deze architectuur zoals te lezen is in mijn 3e bron. Dit is dan ook alleen nog maar puur de kijk op intel. Google kennende willen ze het zo breed mogelijk houden en eventueel ook AMD een kans geven om Android te gebruiken. Dus kan ik begrijpen dat ze hier even mee bezig kunnen zijn.


Enkele handige bronnen om door te lezen zijn:

http://en.wikipedia.org/wiki/P6_%28microarchitecture%29
http://en.wikipedia.org/wiki/Intel_80386
http://en.wikipedia.org/wiki/X86

[Emielio]

Hoewel de in X86 de X staat voor de diverse getallen zullen in de praktijk alleen nog maar de 686 voorkomen. Alles vannaf de "Pentium II" en de "AMD K7" is 686. De "pentium 1 MMX" en de "AMD k6-3" zijn de laatste 586 procs, en die zijn al 12 en 14 jaar oud.

Dus in de praktijk zul je alleen rekening hoeven te houden met 686 en 686-64.

Ik zeg overigens verder niets over de moeilijkheid van het porten, daar heb ik geen verstand van. Ik heb alleen vroeger veel gedaan met architectuur geoptimaliseerde linux distros om zo veel performance uit oude beestjes te halen.

[taeke18]

In de praktijk hoef je volgens mij op het moment rekening te houden met de 6-9_86 varriant, tussen deze 3-4 generaties zitten de meeste pc's. Hoogstwaarschijnlijk verwacht ik een cpu uit de 9e generatie dus zal op papier de optimalisatie voor i989 voldoende zijn.

[Verwijderd]

Er is echter een veschil tussen de x86 architectuur en de x86 intructieset (ISA). Er zijn twee bekende x86 gerelateerde sets op dit moment, de IA-32 en de x86-86 (superset van IA-32, en dus niet IA-64, want dat is de 64-bit instructieset voor Itanium).

Het is alleen de instructieset waar software normaal rekening mee houd, en ook al komen er elke keer uitbreidingen (Extenstions) bij, zoals SSE4.2, SSE5, AVX, etc is er opzich weinig verandert aan de core instructieset.

Je kan daarom ook nog steeds moderne gecompileerde software draaien op een 386, zolang er niet geforceert gebruik gemaakt wordt van bijvoorbeeld SSE4.2 , wat alleen op een Nehalem+ core werkt.

Het is vaak wel mogelijk om elke nieuwe instructieset te doen via een omweg en is het is ook zeer gemakkelijk om dat op compiler niveau op te vangen. Echter dat kan soms leiden tot een forse vergroting van het binaire resultaat. Je komt het daarom nog wel eens tegen dat er meerdere versies van een x86 programma worden gecompileert, waarbij er dan geen gebruik van emulatie wordt toegepast en er dan bijstaat bijvoorbeeld: "een CPU met SSE2 ondersteuning is nodig".

Het is voor Intel in dit geval bedoeld voor de Atom CPU en die heeft buiten de standaard x86 instructieset ook ondersteuning voor talloze uitbreidingen, waaronder MMX, SSE, SSE2, SSE3, SSSE3, Intel 64, en NX/XD bit (voor hardwarematige ondersteuning van DEP). De aankomende 32nm modellen einde van deze maand zullen zelfs waarschijnlijk ook SSE4 krijgen.

Voor AMD is dit meerendeel ook geen probleem via de Brazos APUs, al zullen die wel een nieuw ontwerp krijgen om nog minder energie te gebruiken voor dat ze echt goed toepasbaar zijn in tablets en helemaal smartphones.

AMD heeft tevens een licentie op de meest gebruikte Intel instructieset uitbreidingen (SSE1, etc), en Intel heeft een licentie op de AMD instructieset uitbreidingen (AMD64, etc). Dit is een zogenaamde cross-licentie overeenkomst, die nog steeds lopend is. Wat de exacte voorwaarde zijn weet ik niet, het kan dus zijn dat Intel geld ontvangt van AMD, of andersom, of dat het resultaat $0 is. Tevens hebben ze beide varianten van waar de andere mee uit is gekomen, zo heeft Intel VT-x voor hardwarematrige virtualisatie en is dat bij AMD via AMD-V gekomen. Het kost een compiler echter weinig moeite en een paar extra bits om beide te ondersteunen. Software zoals Xen kan dus met gemak beide sets ondersteuning, en voor sommige host/guest setups is die ondersteuning zelfs verplicht.

[rschwartnld]

juist de andere instructie sets vallen geen van allen onder deze overeenkomst met beide bedrijven anders dan sse en amd-64

[QDrive]

AMD gebruikt ook de x86 instructieset, een x86 port zal dus net zo goed op AMD processors werken...

[taeke18]

Dat klopt, maar AMD heeft weer zijn eigen implementaties op deze architectuur dat net zoals bij de android distrobutie een mooi voorbeeld te geven een versnippering geeft van de x86 instructieset. Hierdoor zijn er miniscuule verschillen die toch grote invloeden geven op alledaags gebruik.

Kijk als voorbeeld naar bepaalde benchmarks zoals superpi/hyperpi deze zijn helemaal niet representatief omdat deze benchmark geschreven is voor een intel CPU en niet voor een AMD varriant. Hierdoor kan bij porten ook problemen komen als het voor intel geoptimaliseerd is, dat AMD er niks van kan bakken.

Om dan meteen het verschrikkelijke te vertellen over dit gehele verhaal, als deze optimalisaties in Intel hun richting wordt gemaakt, en AMD gaat daar op inspelen, dus hun cpu's gaan op die van intel lijken, dan krijg je weer een niet eindigende patent claim etc. Ookal heeft AMD het recht door de aangeschafte licentie op de x86 architectuur kunnen ze er nog steeds door aangeklaagd worden.

Totale conclusie het werkt niet even goed, of het werkt beter, maar gelijke prestaties haal je alleen maar als het voor bijden geoptimaliseerd is, en dit is ene zeer complexe invalshoek. Dit zal dus zijn tijd nodig hebben.

[Blokker_1999]

Tussen AMD en Intel bestaat al jarenlang een contract waarbij ze gebruik mogen maken van elkaars patenten wat betreft X86 en X86-64. Ze zijn tot elkaar veroordeeld.

De verschillen in de CPU zijn enkel van belang voor de compilers en de drivers. App schrijvers moeten zich daar niet veel van aantrekken. En aangezien Android in de basis een linux kernel heeft moet zelfs de basis vrij eenvoudig te porten zijn naar x86.

[the_stickie]

klopt, maar toch bevatten beide merkes cpu's eigen (extra) instructies die bepaalde bewerkingenn moeten versnellen. Optimaliseren dmv dat soort instructies kan de applicatie incompatibel maken met het andere merk.

[rschwartnld]

kun je dat onderbouwen, want zover ik weet maakt amd toch ECHT een eigen versie
nog sterker als jou bewering waar zou zijn had elke amd toch echt ssse3 aan boord.
Nu zal je ik je maar meteen uit de droom halen, dat heeft geen enkele amd.
Alle instructie sets op amd zijn eigen bouwsels en zijn in veel gevallen sterk afwijkend van de intel versie.
In de distributed computing wereld word dan ook gesproken over sse3 van intel en sse3a van amd en hetzelfde geldt voor de sse4 en de amd sse4a.
Dus voor je iets roept wel even uitzoeken of het klopt, de nieuwe bulldozer heeft veel vergelijkbare instructie sets als de i7 modellen maar je zal zien dat ssse3 ook daar mist en als je de sets vergelijkt ook echt zien dat ze anders zijn. Het enige wat je kunt zeggen is dat ze beide dezelfde naam hebben gegeven aan de vergelijkbare sets.

[Iblies]

Idd,
AMD is wat dat betreft zelfs vooruitstrevender dan Intel aangezien ze al stappen ondernemen om bepaalde instructiesets die al achterhaald zijn te verwijderen omdat die al worden uitgevoerd door vb geluidskaart en/of cpu gedeelte.

Ontwikkelen voor andere platformen is in mijn optiek een tactiek van grotere producenten om een stok achter de deur te houden en marktverstoring tegen te gaan.

Windows kan vrijwel overal op draaien als je het geld hebt, maar je hebt niet alle functionaliteit.

Windows CE voor draait op arm, mips en x86, maar je moet iemand hebben die het gaat compilen, is dus niet off-the-shell.
Daarnaast hebt je x86 en x86-64.

Linux, BSD etc draait overal op.

Google weigert pertinent om Android beschikbaar te maken voor andere platforms. Ze maken nu zelfs de keus om het eerst voor hun (bijna) eigen product te ontwikkelen, en vervolgens voor anderen. Gezien de positie die google nu heeft is dat niet wijs, en ze zouden lering moeten trekken van de lessen van MS,
hoe groter je marktaandeel, hoe opener je moet zijn naar afnemers. Zeker niet exclusief blijven.

[blouweKip]

Google weigert pertinent om Android beschikbaar te maken voor andere platforms. Ze maken nu zelfs de keus om het eerst voor hun (bijna) eigen product te ontwikkelen, en vervolgens voor anderen. Gezien de positie die google nu heeft is dat niet wijs, en ze zouden lering moeten trekken van de lessen van MS.

Want MS is zo multiplatform? het is toch google's keuze om zich primair op ARM te richten, net zoals microsoft zich kwa pc platform altijd op x86 gericht heeft en pas onder druk van de markt nu besluit om ook arm te gaan ondersteunen voor hun primaire OS (alpha en itanium waren/zijn zeer kleine submarkten dus die tel ik niet mee), ook op het pc platform is er weinig multiplatform aan MS (of is direct3d tegenwoordig ook beschikbaar voor linux, bsd en osx?).

Wat google hier doet is niets andere dan andere bedrijven, ze focussen zich met hun product op hun eigen markt, itt tot de andere grote spelers hebben ze tenminste wel het meeste geopensourced (met een gedeelte van honeycomb als uitzondering maar die code zal ook openbaar worden zodra de nieuwe nexus verschijnt: daar kan ms misschien lering uit trekken).

If google then bash? (of sh voor de liefhebbers)

[Reactie gewijzigd door blouweKip op 23 juli 2024 19:36]

[mux]

Nope, niet zomaar. i386-compatible software draait wel automatisch op AMD processoren, maar bijna alle andere varianten van x86 hebben intel- of amd-specifieke zaken die apart moeten worden gecompileerd. Alleen binnen een OS, waar het e.e.a. geabstraheerd is, kun je meestal (met de juiste kernel drivers) op alle x86-processoren hetzelfde doen ongeacht de onderliggende variaties.

[dtech]

Uiteraard heb je dit soort problemen niet meer bij een moderne implementatie van x86 voor een nieuw platform: daar wordt gewoon x86 of x86_64 met alle features (uitgezonderd misschien de laatste versies van SSE e.d.) geimplementeerd.

Bovendien heb je ditzelfde probleem bij ARM: ook deze heeft ARMv1 t/m ARMv8 (op het moment) waarbij sommige van die versies zelfs weer subversies hebben

[RielN]

Alle apps draaien toch op een Java-VM? Maakt de onderliggende instructieset dan verschil?

[C0rnelis]

Het artikel zegt dan ook dat het gaat om het porten van Android 4.0 zelf, niet de apps die op dat platform draaien. Voor Android zal het waarschijnlijk wel uitmaken of het nu op mips/x86 of arm moet draaien.

[ZpAz]

De Java-VM moet dan wel x86 kunnen spreken he. Het is niet de officiële Java VM. En dan kunnen er altijd nog bugs voorkomen die eerst niet voorkwamen e.d.

[Dreamvoid]

Voor Android kan je ook in native code programmeren.

En natuurlijk moet de Dalvik VM zelf eerst ook geport worden, plus alle libraries.

[Trinitronic]

neen

[MadEgg]

Google gebruikt toch de Linux-kernel e.d. voor Android? Dan kunnen ze toch niet naar eigen inzicht wachten met het vrijgeven van de broncode? Die moet toch gewoon op verzoek geleverd worden?

Of bedoelen ze hiermee de user interface? Lijkt me dat daar weinig aan te porten is als het een beetje fatsoenlijk geschreven is (zonder allerlei inline assembly zooi enzo).

[Antipater]

Volgens mij hoeven ze het pas vrij te geven om het moment dat ze hun fork van de kernel naar buiten toe verspreiden. Daarnaast is android een hele stack bovenop de kernel, waarvan niet alles onder de GPL valt of hoeft te vallen. De user interface is inderdaad zoiets, maar er zit nog veel meer in wat niet direct op kernel niveau is en ook zaken achter de schermen regelt. Denk alleen maar aan de software die nodig is om de contacten database te regelen, of nog belangrijker: de hele dalvik vm!

Ik heb werkelijk geen idee hoe android precies geschreven is, maar het zou me verbazen als zelfs voor de user interface er niet hier en daar wat inline assembly of non-portable C++ in zit. Een kleine kern hiervan zal performance critical zijn en dat schrijf je dan niet in Java, hoe snel Java tegenwoordig ook mag zijn.

[farlane]

Snap niet zo heel goed op welke manier Google Andoid "voor ARM" ontwikkeld heeft? Betekent dat dat ze de processorspecifieke dingen kerneldingen alleen in de ARM tak hebben geschreven? Volgens mij heeft de Linux kernel nl alle processor specifieke dingen in arch/* staan en zou het voldoende zijn om die primitieven te porten naar een ander platform ( kort door de bocht natuurlijk ).

[Dreamvoid]

Android is veel meer dan alleen maar een Linux kernel.

[oliviervdp]

Meer fabricanten --> meer concurrentie --> lagere prijs dus dat zit wel goed

[VanStino]

Luidt dit dan een tijdperk in waar je ook Android op de laptop die je op dit moment hebt ook naar Android kunt brengen? Zou wel interessant zijn aangezien je dan ècht binnen een ecosysteem kunt beginnen werken. Nu zit je nog steeds op laptop/desktop vast aan Windows of OSX (goed, Chrome OS bestaat ook, maar vind ik véél te beperkt).

Als Google nu nog eens gaat focussen op Docs om dat "up to par" te krijgen met Office en de Android apps offline ondersteuning geeft zie ik de toekomst rooskleurig in.

[.ScorpionSquad]

dit gaat natuurlijk niet alleen om telefoons en tablets. Als andriod op x86 kan draaien op bijv. Asus Eee Pad Slate (deze heeft de i5 470UM dacht ik), waarom dan niet op de Core i7-2600, 990X of AMD Bulldozer?
dat vraagt volgens mij alleen een goede muis/toetsenbordbesturing en ondersteuning voor andere GPU's en aansluitingen?

ik zou best eens een dualboot met Andriod willen, waarschijnlijk is Andriod veel sneller omdat het een veel lichter besturingssysteem is.

[Game_overrr]

Tja... En wat heb je er aan? Laad dan Ubuntu?

[Verwijderd]

In China heeft Institute of Computing Technology een licentie op de MIPS ISA en ontwikkelt eigen processoren (loongson) wanneer android op MIPS kan draaien hebben chinese bedrijven de mogelijkheid telefoons te maken waarvoor geen buitenlandse technologie meer nodig is.

[devil-strike]

Dit is wel cool dat mips dit gaat doen, dit betekend dan ook dat vele tv's en ook consumenten routers voorzien kunnen worden van android, aangezien vele tv's gebruiken maken van mips socs en voor router helemaal(90 % van de routers draait op mips socs)

[Frank-L]

Offtopic:
Waarom zie ik hier de laatste tijd toch zo vaak Android gespeld als Andriod?

[Arcticwolfx]

Nou he