ARM angriber Intel - satser på multicore-processorer til pc

produkterne vil ikke kunne bruges med Windows.

Kan man ikke snart formulere det korrekt - det er Windows der ikke kan bruges på en ARM processor!

ARM har tidligere meldt ud, at firmaet forventer, at Microsoft bliver nødt til at porte den fulde udgave af Windows til ARM-arkitekturen inden 2013. Ellers vil styresystemet hurtigt blive overhalet af alternativerne, fordi fordelene ved at bruge ARM-processorer i stedet for Intels x86-arkitektur er så store, lød det dengang selvsikkert.

Og det er nok endnu mere tilfældet i dag, da der er en masse nye fabrikanter af nye netbooks på vej.
Og disse fabrikanter baserer sig udelukkende på ARM, og har ingen bindinger med MS' omkring underlige OEM aftaler, og ingen restriktioner på skærm og diskstørrelse, hvorfor de ikke er følsomme over for bøllemetoderne som f.eks. Asus skal lægger ryg til:
http://www.semiaccurate.com/2009/06/12/ms-steps-snapdragon/

Herudover sidder ikke-MS ret lunt på serversiden, og med nye high performance ARM processorer, så vil der være rigtig meget strøm at spare der.

/Christian

Det er jo desværre ikke kun Windows, som skal porteres. Alle non open source firmaer, som har native software ude på windows platformen vil hænge i håndbremsen. Der er ingen firmaer, som ønsker at bruge penge på at portere gammel kode til en ny hardware. Alternativet er virtuelle x86 maskiner på ARM og så er der ikke vundet noget.
Selv projekter som Wine er afhængig af at køre på x86 hardware.

Ehh, kunne du ikke være lidt mere klar?

Mener du programmer som Photoshop og tilsvarende programmer der kun er skrevet til Windows?

Det problem tror jeg er til at overskue når folk kan få en netbook preloaded med det mest almindelige de skal bruge til ca. 1000 kr.

/Christian

Selv projekter som Wine er afhængig af at køre på x86 hardware.

Wine er netop et barn af Windows-dominansen. Brydes Windows-dominansen, vil software-branchen blive nødt til at lave portabel kode hvis de vil ud til flere brugere - og så vil Wine miste eksistensberettigelsen.

En ARM-baseret netbook kan i stedet komme til at køre Android, Windows Mobile eller en række forskellige Linux-varianter.

Det er heller ikke umuligt, at en ARM netbook kommer til at køre RISC OS, det første desktop/laptop operativsystem, der blev udviklet til ARM. Det er ved at blive porteret til OMAP platformen (som blandt andet bruges på Always Innovating's Touch Book) og til en platform baseret på ARM Cortex A8. RISC OS er efter min mening et udmærket OS til formålet, dog mangler der endnu en del drivere og visse netteknologier (f.eks. Flash), men det skal nok komme.

Mener du programmer som Photoshop og tilsvarende programmer der kun er skrevet til Windows?

Photoshop er mainstream software, som der hele tiden bliver udviklet på. Det skal nok blive porteret. Jeg tænker mere på de store mængder dedikeret windows software/drivere som f.eks. bliver leveret sammen med alskens apparater.
Tag f.eks. et firma som Garmin. Det bliver ufatteligt svært at overbevise dem om at de skal bruge resourcer på at portere deres kort software. De har en fungerende x86 windows version.. Take it or leave it.

Tag f.eks. et firma som Garmin. Det bliver ufatteligt svært at overbevise dem om at de skal bruge resourcer på at portere deres kort software.

Op i r.... med Garmin, hvis de er så dumme at de benytter Windows til embeddede enheder, så er det da deres eget problem.

Og de får altså svært ved at overleve, når dels deres produkt er dyrere pga SW licens, og dels kun holder halvt så længe på batteriet - husk på at her taler vi commodity produkter på linie med mobiltelefoner, og der er kunderne ret ligeglade med hvilket OS der er på, der er det pris, features og batterilevetid der tæller.

TomTom kan jo ligesom godt finde ud af det.

Og så er hovedparten af alt embedded udstyr jo alligevel baseret på *nix af en art.

/Christian

Lidt interessant artikel på CW:

http://www.computerworld.dk/art/53083/nec-og-renesas-danner-gigantisk-ch...

Renesas producerer ARM baserede processorer, og det har de så tænkt sig at gøre i stor stil!

/Christian

Det, der adskiller den nu annoncerede Cortex A9 core fra den tidligere er, at der er tale om en "hard macro", dvs. at layout er specificeret og optimeret for performance på en specifik fabrikationsproces. Den tidligere A9 core var en "soft macro", dvs. en beskrivelse af komponenter og forbindelser men uden layoutoptimering til en specifik platform. Denne skal så (sammen med evt. andre komponenter, som et firma vil bygge sammen med processoren) sendes gennem en "silicon compiler", der genererer layout til en specifik proces.

ARM forventer, at den "hårde kerne" kan yde op til fire gange mere end den "bløde".

Den nye A9 er optimeret for performance, så den vil nok bruge lidt mere strøm end den "bløde", så ARM tiltænker den ikke til håndholdte enheder, men til servere, PC'er (inklusive laptops) og spilkonsoller. Jeg kan sagtens forestille mig, at Apple vil bruge den (i en SoC med selvdesignede grafik og i/o processorer) i næste generation af deres desktop/laptop serier.

Jeg sysnes ikke det er klart hvad man kan forvente af ARM processorerne m.h.t. hastighed. Eet er jo en angivelse af MIPS på CPU'en. Men det er mere uigennemskueligt hvordan de bliver at arbejde med når man kører et generelt desktop system (eller en windows hvis det nogensinde bliver aktuelt). Hvad med tung grafik? Der er nvidia jo i forvejen alt dominerende. De kan vel ikke bare skrue op for ydelsen fordi cpu'en bliver en ARM?

Min helt subjektive forventning er at alt hvad du smider windows på vil køre langsomt ;-)

Er der planer om at lave en 64-bit udgave af ARM? Jeg sætter i praksis en lille smule større pris på det større addresserum end en ekstra kerne, selvom jeg da helst vil have begge dele.

Som CPU alene yder ARM generelt bedre pr. MHz end x86, specielt i forhold til Atom, som yder forholdsvist lidt pr. MHz sammenlignet med desktop x86'ere.

Grafik kræver selvfølgelig en dedikeret grafikprocessor -- her er det ikke anderledes end x86. NVidia har lavet en ARM med indbygget grafikchip, som de kalder Tegra. Den yder ikke som deres topniveau grafikkort, men en del bedre end Intels egen standardgrafikprocessor til Atom. Der er i øvrigt intet til hinder for, at man sætter et topniveau grafikkort på en ARM processor -- der skal bare laves drivere.

Jeg har ikke hørt om planer for en 64-bit ARM, men ARM er nok klar over, at det bliver nødvendigt på et tidspunkt.

I en multikerneprocessor kan man komme et stykke vej ved at lade de forskellige processorer mappe deres logiske adresserum til et større fysisk adresserum. Det er sjældent at man (som almindelig PC bruger) skal bruge mere end 4GB til en enkelt proces, så ved at fordele processor over flere kerner, kan man bruge et større samlet lager.

ARM er i øvrigt eksperter i at lade en enkelt processor køre med flere forskellige instruktionssæt -- Cortex A8 kan f.eks. køre både det oprindelige 32-bit instruktionssæt, Thumb, Thumb2, et vektor FP instruktionssæt, et SIMD instruktionssæt og Jazelle (Java bytekode). Så det skulle ikke være noget problem at tilføje et 64-bit instruktionssæt samtidig med, at processoreren understøtter de "gamle" instruktionssæt.

Min helt subjektive forventning er at alt hvad du smider windows på vil køre langsomt ;-)

Hvis ARM virkelig kan indfri forventningerne om væsentlig hurtigere arkitektur med mindre strømforbrug, så er jeg sikker på at det vil trække software producenterne til. Men jeg er også sikker på at Intel/MS + mange andre vil slås med næb og klør og forsøge at fryse den ude.

http://www.connexin.net/humor-computer-borg-gates-HAL-upgrade-microsoft....

Jeg tror at ARM vil have bedre chance, hvis de udvikler en intelligent "oversætter", der gør det muligt at køre intel kode. Idéen er, at når koden køres, så lægges en "kopi" af koden på harddisken, som ren ARM kode - og den oversættes under udførslen. Kommer programmet på et tidspunkt ud i ikke oversat kode, går den tilbage og oversætter intel koden, og kører igen i oversat kode. Når et program har kørt et par gange, kører den derved reelt i ARM kode, selvom det er Intel kode. Det interessante ved en sådan oversætter, er at den kan lave kodeoptimeringer ved oversættelsen, og eventuelt laves til, at tage hensyn til de mest brugte compileres måde at oversætte - f.eks. dem der er brugt til Windows. Den "forstår" derved koden, og kan oversætte den "frit" til ARM kode. Er det maskinkode, forstår den det altid som maskinkode, og kan oversætte det til ARM maskinkode. Kommer den ud i hops og branches, oversætter den kun i den retning, som programmet aktuelt tager - den anden retning oversættes først, når den bliver udført.

Det sværeste er at lave en sådan compiler til operativsystemet, der anvender masser af pentium processorens hardware, og ikke kun kræver simulation af kode, men også af hardware. Derimod software der kører under windows operativsystemet, burde relativt nemt kunne køre. Med andre ord, vil Linux kunne oversættes til ARM, og WINE laves til at oversætte koden meddens den udføres, og lægge en kopi af den oversatte kode på harddisken, så programmet kører i ARM kode. Naturligvis skal WINE totalt omskrives til ARM kode, og måske gøres i maskinkode for de dele der indgår i programmets udførselstid.

Skal ARM have chance på PC markedet, tror jeg eneste mulighed er at satse på en ARM UNIX/LINUX, kombineret med en WINE compiler, der udfører windows programmer og oversætter dem on-the-fly til ARM maskinkode. I nogle tilfælde, er den slags oversættelser mere effektive end den originale kode, fordi der kan optimeres kode ved oversættelsen. Er programmet oversat på en optimal compiler, er dog begrænset hvor meget der opnås ved en ekstra compilering.

Typisk, vil en ekstra compilering, tilføje f.eks. bedre registeroptimeringer til koden - hvilket også kan være relevant, når koden skal over i nye registre, på en ARM cpu. Naturligvis kan ARM cpu'en også udvikles så den er nemt at "krydsoversætte" til, og så beholde registre mv. hvorved optimeringen undgås. Det gør naturligvis, at oversætteren ikke vil kunne tilføre ekstra power.

Der har været forsøg, som har vist, at en sådan oversætter, der oversætter fra og til samme CPU, vil kunne øge hastigheden 10%. Dette skyldes specielt optimeringer. Oversætteren, gør naturligvis programmet langsommere første gang noget kode udføres, da det så oversættes og gemmes på harddisk, men herefter er koden gennerelt noget hurtigere.

Da Acorn lavede Archimedes i 1987, var der faktisk en x86 simulator, så man kunne køre DOS under emulering. En 8MHz ARM2 kunne dengang simulere en 80186 på omkring 3MHz, så det kunne lige akkurat bruges.

Det var ikke nogen JIT compiler, men Digital lavede en x86 JIT compiler kaldet FX!32 til deres Alpha RISC processor, og det fungerede også godt.

Så det er langt fra umuligt. Hvis man lægger Wine ovenpå, undgår man endda Microsoftskatten.