Intel en MIPS willen Android 4.0 op hun processors laten draaien

Reacties

« 1 2 »

Door herbie5300, zondag 6 november 2011 10:22

Door satoer, zondag 6 november 2011 10:33

Nou ik ben er anders minder blij om. Dan moet je dus voor elk programma dus een x86, ARM of Mips versie compileren. Net als vroeger weer met de PDA's, moest je ook kiezen tussen een ARM of MIPS. Het zal de prestaties van de programma's ook niet ten goede komen. Nu werkt tenminste alles wat je uit de android market download zonder er verder bij na te denken.

Door Trinitronic, zondag 6 november 2011 10:45

Onzin, applicaties op android draaien op een java engine van google.

Door Dreamvoid, zondag 6 november 2011 11:04

Lang niet allemaal, veel ervan draaien Android native code.

(edit: jezus mensen, hou t eens relaxed)

[Reactie gewijzigd door Dreamvoid op zondag 6 november 2011 16:04]

Door mad_max234, zondag 6 november 2011 11:18

Als je niet weet hoe het werkt, doe dan niet interessant! Dat is alleen de taal waar het in geschreven word, of je nu C, C++ of native andriod taal gebruikt de compiler of VM zet het in gewoon om naar code voor andriod. Code van de NDK draait gewoon in de VM!

Staat zelfs op de pagina die je linkt, dus als je het nog niet wist had je het door je eigen link kunnen weten.

"If you write native code, your applications are still packaged into an .apk file and they still run inside of a virtual machine on the device. The fundamental Android application model does not change."

[Reactie gewijzigd door mad_max234 op zondag 6 november 2011 12:14]

Door coretx, zondag 6 november 2011 11:23

Als je niet weet hoe het werkt, doe dan niet interessant!
Ik heb genoeg apps die *echt* native draaien op mijn android tel. Zonder NDK troep.

Door mad_max234, zondag 6 november 2011 11:55

Als je niet weet hoe het werkt, doe dan niet interessant!
Ik heb genoeg apps die *echt* native draaien op mijn android tel. Zonder NDK troep.

Volgens mijn onzin, welke taal is dan native voor andriod? Neem aan dat je gewoon een van de hogere programmeer taal is? En welke app heb je dan gemaakt? Ook assembler op andriod word nog omgezet naar code die VM snapt, en draait allemaal in VM!

Onderbouw je bewering eens wat meer!

[Reactie gewijzigd door mad_max234 op zondag 6 november 2011 11:56]

Door Arcticwolfx, zondag 6 november 2011 11:59

Door CptChaos, maandag 7 november 2011 01:00

Volgens mijn onzin, welke taal is dan native voor andriod? Neem aan dat je gewoon een van de hogere programmeer taal is? En welke app heb je dan gemaakt? Ook assembler op andriod word nog omgezet naar code die VM snapt, en draait allemaal in VM!

Onderbouw je bewering eens wat meer!

Aannemende dat de VM dan tevens dienst doet als sandbox, zou ik gokken dat CoreTX bedoeld dat ie zijn telefoon geroot heeft: dan kun je buiten de sanbox om (en dus buiten de VM om) apps draaien.

Door ncoesel, maandag 7 november 2011 10:13

Als je de link van Dreamvoid had aangeklikt en de site had gelezen dan had je geweten dat het om een C/C++ ontwikkelomgeving gaat die native ARM code uitspuugt. Dankzij de MMU zit e.e.a. netjes in z'n eigen omgeving.

Door Wolfos, zondag 6 november 2011 11:32

En waarom draaien applicaties zoals Firefox dan niet onder ARMv6, maar wel onder ARMv7? NDK applicaties worden gewoon naar binary omgezet.
Alleen zal het meerendeel van de applicaties WEL gewoon draaien onder X86, en recompilen is zeker niet moeilijk wanneer dezelfde libraries aanwezig zijn.

Ik denk dat voor de meeste applicaties Dalvik een uitkomst is, en de meeste applicaties maken daar ook gebruik van. Als een applicatie niet geschikt is voor het apparaat, dan staat het ook niet in de Android market op dat apparaat.

Voor applicaties die echte performance nodig hebben is wel een port nodig, maar aangezien je het nog steeds over hetzelfde OS hebt hoeft dat niet moeilijk te zijn.

[Reactie gewijzigd door Wolfos op zondag 6 november 2011 11:34]

Door BumEyes, zondag 6 november 2011 11:33

Wat Dreamvoid zegt is wel waar hoor.

What is the NDK?
The latest release of the NDK supports these ARM instruction sets:
• ARMv5TE
• ARMv7-A
• x86 instructions
(...) You can target either or both of the instruction sets — ARMv5TE is the default, but switching to ARMv7-A is as easy as adding a single line to the application's Application.mk file, without needing to change anything else in the file. You can also build for both architectures at the same time and have everything stored in the final .apk.

Je kan dus builden voor verschillende architectures. Lijkt me sterk dat het dan daarna omgezet wordt in 'code voor android'. Dat het in een VM draait sluit niet uit dat het echt native code is.

[Reactie gewijzigd door BumEyes op zondag 6 november 2011 11:35]

Door mad_max234, zondag 6 november 2011 12:05

Nu even de eerste regels van jou link ook even hier posten, draait dus net zo hard in VM. Welke taal je in het geschreven maat niks uit, daar ging het niet om, ging of het in VM draait of niet. Alles word dus omgezet(als het nodig is) naar iets wat VM begrijpt.

"The Android NDK is a toolset that lets you embed components that make use of native code in your Android applications.

Android applications run in the Dalvik virtual machine. The NDK allows you to implement parts of your applications using native-code languages such as C and C++. This can provide benefits to certain classes of applications, in the form of reuse of existing code and in some cases increased speed."

Lees dat C en C++ native is voor andriod, dat is hogere taal en word niet door machines begrepen, word dus door VM of compiler alsnog omgezet naar code die de arm begrijpt.

[Reactie gewijzigd door mad_max234 op zondag 6 november 2011 12:10]

Door H!GHGuY, zondag 6 november 2011 12:21

Hou nou even op met de betweter uit te hangen.

Uit je eigen quote blijkt: de NDK laat je native libraries gebruiken vanuit Dalvik.

Met andere woorden: in de .apk file zit dan een byte-compiled stuk en een native stuk.
Ja, dat native stuk wordt 'vanuit' de VM aangeroepen, maar het is en blijft platform afhankelijk. Het stuk wat je in C/C++ schrijft wordt niet omgezet in bytecode.
De NDK zorgt enkel voor de interfacing tussen beide.

Door 272924, zondag 6 november 2011 22:50

Hè, eindelijk iemand die het begrijpt.

De NDK staat je toe om stukjes native code toe te voegen die je even later van uit de Dalvik omgeving (Java) weer kunt aanroepen. Om dat te kunnen moeten de stukjes native code aan een aantal voorwaarden voldoen (Dalvik interface spec.) en ze moeten in een .apk verpakt worden. De NDK maakt dat mogelijk. That's all.

Maar on topic, voor zover ik weet zit er al x86 support in in de Linux kernel van Android, dat is dus niet het probleem. Wat moet er dan nog meer geport worden? Dalvik? Dat is alleen maar een Linux applicatie, een questie van wat hercompileren dunkt me. Of zie ik nu iets simpels over het hoofd?

Door kidde, zondag 6 november 2011 23:56

[quote]zover ik weet zit er al x86 support in in de Linux kernel van Android. Wat moet er dan nog meer geport worden?[quote]

x86 is weinig boeiend, vermoedelijk daarom is de titel dat Intel Android 'op haar processors wil laaten draaien' (waarbij processors wijst op de applicatie processor / SoC als geheel, en niet op de CPU), niet dat ze het 'op x86 willen draaien'.

Voor zover ik begrijp zit het als volgt:
In een TI OMAP, Samsung Exynos, SE Nova of welke applicatie processor ook zit allerlei 'randapparatuur', maar wel op dezelfde plak sillicium als de CPU.

Dat is doorgaans een 3D versneller, 2D versneller, video codec, audio codec. En daar zit dan vaak een 'losse' chip bij voor 'connectivity' (bluetooth, gsm, wifi etc.) Die hebben allemaal drivers nodig. Vaak is er ook nog wat logica nodig om de CPU'tjes samen te laten werken, een OMAP 4 bijvoorbeeld heeft nog 2 Cortex-M3 microcontrollertjes. En die werken weer niet op de ARMv7-A instructieset, maar met de ARMv7-M.

Intel echter gebruikt natuurlijk andere 'componenten' (GPU, video codecs, geheugencontroller, crypto-unit, etc) dan Texas Instruments, dus Intel moet ook drivers leveren voor alle specifieke componenten die ze vastkoppelen aan de CPU. En als de Atom bijv. geen crypto-unit heeft (volgens mij heeft die dat niet), dan moet die dus softwarematig 'nagemaakt' worden.

Verder is het zo dat de ARM-versie van de Linux-kernel (of eigenlijk de losse OMAP/Exynos/Tegra takken) boordevol zit met allerlei methoden om stroomverbruik terug te dringen.

Natuurlijk ondersteunt Linux x86, maar die 'tak' heeft vziw vrij weinig optimalisaties voor vermogen. En natuurlijk is er voor ontwikkelaars vaak nog een 'emulator' nodig, zodat ze op de PC zaken voor een Intel SoC kunnen testen.

En de gcc compiler is vrij belabberd (in ieder geval voor ARM), dus ARM en Intel maken ook nog eens zelf compilers beschikbaar. En die compiler van Intel moet dan weer de nieuwste functies uit de nieuwste Atom's ondersteunen.

Verder is het zo dat veel Atom's nog 'ouderwets' een losse chipset nodig hebben (SM35 express iirc), maar daar is Android voor ARM natuurlijk niet op berekend. Weet niet of het verschil maakt voor de programmeur, maar fysiek is het wel een groot verschil.

Door ncoesel, maandag 7 november 2011 10:17

Sorry, maar je hebt het niet begrepen. Je maakt 'plugins' die door Java code kunnen worden aangeroepen. De plugin zelf is ARM machinecode die door de C compiler is gegenereerd.

@kidde: hoe kom je erbij dat GCC voor ARM belabberd is? ARM werkt zelf mee aan de ontwikkeling ervan. GCC is juist 1 van de betere ARM compilers! Het is niet voor niets dat veel bedrijven die zelf compilers maken (denk aan Keil, IAR, etc) zijn overgestapt op GCC voor wat betreft ARM omdat GCC veel beter is dan hun eigen compiler.

[Reactie gewijzigd door ncoesel op maandag 7 november 2011 10:50]

Door - peter -, zondag 6 november 2011 13:28

De NDK is juist geschikt voor C en C++, en die code is wel degelijk gecompiled naar native code. Daarom is het ook de Native Development Kit. Code wordt wel gepackaged in de APK en de app zelf draait natuurlijk in java, maar kan callbacks naar je native code maken. Je kan niet een complete app in je NDK maken, maar wel hulproutines.

Zonder NDK draait alles gewoon in Java. Misschien geJIT, maar gewoon in de Dalvik VM.

Door ro8in, zondag 6 november 2011 19:57

Wat een ongeloofelijke onzin zie ik hier. Dat het in een VM draait wil nog niks zeggen over de platform afhankelijkheid. Een VM is platform afhankelijk en zo is ook de software dat binnen de VM draait. Volgens velen van jullie logica als ik Windows in een VM zou draaien zou het opeens niet meer uitmaken welke CPU eronder zit. Misschien als de hypervisor cpu sets zou kunnen emuleren, maar ik ken er geen die dan doen (zou ook niet bepaald soepel lopen dan..)

Door CTVirus, zondag 6 november 2011 10:46

Gelukkig draaien de meeste apps op Android in een virtual machine (http://en.wikipedia.org/wiki/Dalvik_%28software%29) dus dat zal niet zo'n groot probleem zijn.

Door MacWolf, zondag 6 november 2011 11:09

Wellicht zijn fat binaries ook een optie. Voor ontwikkeling van iOS apps gebruik ik soms fat binaries voor bibliotheken en dergelijke. Dan heb je 1 binary die zowel voor x86 als ARM architecturen gebruikt kan worden (bevat gecompileerde code voor beide). Op deze manier kan je dus je app draaien op zowel je device (iPhone / iPad) als de iPhone simulator. Apple levert een tool met de SDK waarmee een ontwikkelaar zo'n fat binary kan maken.

[Reactie gewijzigd door MacWolf op zondag 6 november 2011 11:11]

Door dtech, zondag 6 november 2011 12:32

De Android market heeft al vrij uitgebreide mogelijkheden om de goede .apk's te installeren voor verschillende toestellen. Voor google is het eenvoudig de instructieset toe te voegen als condition en voor developers is het ook niet moeilijk hun build-instructions zo aan te passen dat x86 en/of MIPS ook worden meegenomen.

Sowieso zal dat alleen nodig zijn bij apps die native code gebruiken. In tegenstelling tot iOS zijn Android apps grotendeels gebaseerd op het architecture-independant Java (alleen zware games en andere apps met native code moeten opnieuw gecompiled worden)

Het is misschien wel een idee om de native code compiler zo aan te passen dat de code voor alle 3 de architecturen in de .apk wordt gestopt. De size hit zal relatief klein zijn omdat slechts een klein deel native is.

Door IJssiej, zondag 6 november 2011 11:37

Door Grauw, zondag 6 november 2011 12:19

Als ontwikkelaar vind ik het juist een goede zaak. Waarom? Omdat de Android-emulator op het moment altijd ARM code moet emuleren en daardoor bijna onbruikbaar traag is. Terwijl een emulator in principe heel handig is, dan hoef je niet de hele tijd naar een device te uploaden en kan je makkelijk op verschillende resoluties testen.

Als er kernel-images van Android op x86-architectuur beschikbaar zijn, dan kan de emulator in x86-modus draaien en daardoor veel sneller werken (met performance vergelijkbaar met de iPhone simulator).

Door TD-er, zondag 6 november 2011 10:23

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.

Door taeke18, zondag 6 november 2011 10:35

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

Door QDrive, zondag 6 november 2011 10:57

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

Door taeke18, zondag 6 november 2011 11:15

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.

Door Blokker_1999, zondag 6 november 2011 11:36

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.

Door the_stickie, zondag 6 november 2011 11:48

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.

Door rschwartnld, maandag 7 november 2011 09:57

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.

Door Iblies, zondag 6 november 2011 11:18

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.

Door blouweKip, zondag 6 november 2011 22:36

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 zondag 6 november 2011 22:37]

Door mux, zondag 6 november 2011 11:31

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.

Door Emielvenlo, zondag 6 november 2011 11:03

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.

Door taeke18, zondag 6 november 2011 11:17

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.

Door Ron.IT, zondag 6 november 2011 11:25

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.

Door rschwartnld, maandag 7 november 2011 10:04

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

Door dtech, zondag 6 november 2011 12:35

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

Door robogast, zondag 6 november 2011 10:23

Door Glashelder, zondag 6 november 2011 10:31

In welk opzicht denk jij dat het dan een hele andere telefoon wordt? Welke instructieset een proccesor onderhuids gebruikt, daar merk je als gebruiker niets van. Mogelijk kan je (zonder emulatielaag) alleen geen apps draaien uit de market; maar die emulatielaag zal er vast wel komen.

Android op x86 of op ARM zal er voor de gebruiker (als het goed is) hetzelfde uitzien.

[Reactie gewijzigd door Glashelder op zondag 6 november 2011 10:32]

Door denniskrol, zondag 6 november 2011 10:31

Fail van de first post

Waarom zouden ze dat niet willen? Als er ook telefoons gemaakt kunnen worden op x86, dan verkopen ze toch (hopelijk) meer processoren? En waarom zou het een andere telefoon worden?

Door Ortixx, zondag 6 november 2011 10:31

Ze willen het voor tablet gebruik aangezien er binnekort een storm loop gaat komen van tablets en slates met x86 architectuur ivm windows 8.

[Reactie gewijzigd door Ortixx op zondag 6 november 2011 10:32]

Door C0rnelis, zondag 6 november 2011 10:51

Wellicht, maar vergeet je toevallig dat Windows 8 ondersteuning biedt voor ARM? (Ook al is het niet compleet hetzelfde als de x86 Windows 8, maar ten minste wordt het Metro gedeelte ondersteund)

Door hav0c, zondag 6 november 2011 10:35

Miscchien dat Intel graag processors wil verkopen? Zomaar een idee hoor.

Wel mooi dat MIPS op deze manier wat druk op Google legt om die source een beetje vlot vrij te geven.

Door Antipater, zondag 6 november 2011 11:18

Jahoor:

* consumenten geven best wat geld uit aan telefoons
* als telefoons intel processors hebben en er intel-inside phones worden verkocht, verkoopt intel meer processors
* meego is commercieel doodverklaard, android is nr. 1 mobile OS
* intel heeft als doelstelling geld verdienen

ergo:

* android porten naar intel en snel ook

Door Dreamvoid, zondag 6 november 2011 16:08

En vanuit MIPS zit er ook wat urgentie achter: een van hun grootste klanten (Broadcom) heeft onlangs een licentie op ARM genomen, dus ook die voelen de hete adem van ARM. Een goede MIPS port voorkomt dat hun klanten naar ARM overstappen vanwege Android.

[Reactie gewijzigd door Dreamvoid op zondag 6 november 2011 16:12]

Door MadEgg, zondag 6 november 2011 10:38

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).

Door Antipater, zondag 6 november 2011 11:33

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.

Door RielN, zondag 6 november 2011 10:39

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

Door C0rnelis, zondag 6 november 2011 10:47

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.

Door ZpAz, zondag 6 november 2011 10:47

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.

Door Trinitronic, zondag 6 november 2011 10:48

neen

Door Dreamvoid, zondag 6 november 2011 11:06

Voor Android kan je ook in native code programmeren.

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

Door farlane, zondag 6 november 2011 10:41

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 ).

Door Dreamvoid, zondag 6 november 2011 11:06

Android is veel meer dan alleen maar een Linux kernel.

Door oliviervdp, zondag 6 november 2011 10:48

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

Door VanStino, zondag 6 november 2011 11:19

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.

Door .ScorpionSquad, zondag 6 november 2011 11:23

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.

Door Game_overrr, zondag 6 november 2011 14:58

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

Door Frank-L, zondag 6 november 2011 11:55

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

Door Arcticwolfx, zondag 6 november 2011 12:09

Nou he

« 1 2 »

Op dit item kan niet meer gereageerd worden.

11:17	'Motorola wil multimediatablet uitbrengen met tv-ondersteuning'
19:31	Diverse providers weigeren iPhone 4S te verkopen

Nieuws I/O

Shortcuts

Categorieën

Lees meer over

Gerelateerde content

Reacties

27-05 Nieuws

00:38 Productreviews

03:03 Vraag & Aanbod

25-05 Jobs

20:30 Etc.

03:50 Reacties

03:52 Forum

25-05 Gesponsorde acties

01:46 Tweakblogs

26-05 Computable headlines

25-05 CRN headlines