Torben Mogensen header

64-bit ARM

I går annoncerede ARM den længe ventede 64-bit version af deres processor. Det skete i form af ARMv8 -- version 8 af arkitekturen. Man skal ikke forveksle versionsnummeret med produktnumre såsom A8, A9 og A15, der alle bruger v7 arkitekturen. ARM har ellers holdt kortene tæt til kroppen og ikke officielt meldt ud, at de arbejdede på et 64-bit design. Der er dog næppe mange, der bliver overrasket over udmeldingen -- jeg havde selv regnet at se en 64-bit ARM for over et år siden. Men ARM har vel tænkt, at hastværk er lastværk.

I stil med tidligere udvidelser som f.eks. Thumb er 64-instruktionerne samlet i en processor mode kaldet AArch64, hvor AArch32 er det eksisterende v7 instruktionssæt. Ellers er der ikke mange detaljer om instruktionssættet.

En 64-bit processor er direkte rettet mod servermarkedet, så Intel må for alvor se skriften på væggen nu, hvor ejere af store serverfarme har mere og mere fokus på strømforbrug og køleudgifter. ARM har på dette område langt mere erfaring end Intel, selv om Intel halser efter med produkter som Atomserien. En 64-bit ARM giver også god mening for full size laptops, spillekonsoller og lignende. Måske kommer den næste XBox, Playstation eller Wii til at køre på ARM.

Kommentarer (20)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Casper Bang

En 64-bit ARM giver også god mening for full size laptops, spillekonsoller og lignende. Måske kommer den næste XBox, Playstation eller Wii til at køre på ARM.

Den vil helt sikkert også ende i rigtig mange medie-bokse, NAS osv. til hjemmebrug. Dejligt med noget konkurence til x86.

  • 9
  • 0
#2 Torben Mogensen Blogger

Se http://www.arm.com/files/downloads/ARMv8_Architecture.pdf

Her står blandt andet, at instruktionerne er 32-bit lange (ingen 16/32 bit blanding som i Thumb2), at der er 31 general purpose registre (mod 16 i 32-bit udgaven) og et konstant-0 register (som i MIPS). PC og stakpegepind ligger ikke længere i almindelige registre. Dertil kommer 32 128-bit registre, der også kan opdeles i 64 64-bit registre.

  • 3
  • 0
#6 Casper Bang

Tror du mener x64

Næ, siden Intel erstattede deres 8bit 8008 med deres 16bit 8086, er x86 betegnelsen sådan set brugt omkring samtlige Intel CPU'er (bortset fra Itanium der er en IA-64 arkitektur). Så x86 siger intet omkring bredden af memory bussen og registre, men noget om arkitekturen når det kommer til byte order, memory segmentering, overflow semantik osv.

Har disse boxe brug for at adressere mere end 4 GB RAM?

Husker du "640K ought to be enough for anybody" ? Anyway, selv om du ikke vil proppe mere end 4G RAM i, kan software stadig drage fordel af at kunne bruge memory mapped filer oppe i den størrelse, og udnytte de ekstra registre til at udføre det dobbelte (32bit) arbejde på den samme tid.

  • 6
  • 0
#8 Baldur Norddahl

Næ, siden Intel erstattede deres 8bit 8008 med deres 16bit 8086, er x86 betegnelsen sådan set brugt omkring samtlige Intel CPU'er

Hvad med 8088/80188? Nå dem kalder vi også x86.

De er i øvrigt mere eller mindre kompatible med 8080 og 8085 forstået som at 8086/8088 kan køre programmer lavet til 8080/8085. Det nye er så vidt jeg husker muligheden for at adressere mere end 64 Kb (segmenter). Segmenter bruges ikke længere, de blev i 80386 protected mode afløst af selektorer.

Det er da også først langt senere at man begyndte at bruge betegnelse x86 og da var disse ældre CPU'er for længst glemt.

  • 0
  • 0
#9 Jens Dalsgaard Nielsen

faktisk var den banebrydende arkitektur 286 som kom før 386. arkitekturen. Blev brugt i "PC AT" type maskiner. x86 var betegnelsen for instruktionssæt fra og med 8088/8086 som push ax pop ax osv Da der kom 32 bit på kom de til at push eax osv. 32 bit istedet for 16 men den binære opcode var den samme :-) Der er en del der mener at denne "binære" kompabilitet har kostet en del rent performancemæssig.

  • 0
  • 0
#11 Morten Andersen

Hej Jens, jeg tør ikke sige det med 100% sikkerhed, men er det virkelig rigtigt at Intel i sit 32-bit instruktionssæt (fra og med 386) sigede mod at bevare en vis form for binær kompatibilitet (i den forstand jeg opfatter at du skriver, at et 16-bit program nærmest skulle kunne afvikles i 32-bit)? Det tror jeg ikke er tilfældet, det er muligt nogle instruktioner har samme kodning og blot er gået op i bitstørrelse, men der er også mange andre forskelle, bl.a. forøget ortogonalitet, fuldstændigt ændret adresseringsform o.s.v. 386 og frem indeholder da også en "virtual 86" mode som var tilgængelig når CPU'en kørte i 32-bit protected mode, netop for at gamle 16-bit programmer skulle kunne afvikles heri (fremfor i den normale 32-bit protected mode). Det er denne mode der anvendes af f.eks. DOS-boksen i Windows (i hvert fald på 32-bit Windows'er), og tilbage i DOS blev den anvendt af EMM386 til at forøge den del af det nederste adresserum (< 1 MB) der kunne bruges af devicedrivere m.m. idet ubrugte adresser til option ROM kunne (med paging, som stadig var aktiv i v86) mappes til rigtig RAM højere oppe m.v.

  • 0
  • 0
#12 Poul-Henning Kamp Blogger

men er det virkelig rigtigt at Intel i sit 32-bit instruktionssæt (fra og med 386) sigede mod at bevare en vis form for binær kompatibilitet

Nej, det gjorde Intel ikke.

Intel bevarede bagudkompabilitet med "modes" således at deres CPU kunne sættes til at køre som en tidligere CPU og de bevarede navngivningen i deres assemblersprog ikke ved inkompatibilitet at friste folk til at kigge efter andre platforme.

AMD scoopede Intel totalt med 64 bit arkitekturen, der er radikalt anderledes.

  • 3
  • 0
#13 Jens Dalsgaard Nielsen

helt enig :-)

Det sjove var at de binære koder for en stor del af instruktionssættet var det samme, godt nok gemt i 32 bit ord istedet for 16. Også det samme lave antal cpu registre. Så hvis man skulle skrive maskinkode gjorde man som i gl dage dog blot med eax istedetfor ax. weird . men det holdte måske lidt på folk.

Så som PHK skriver sov de i timen da der stod 64 bit på døren, men de er kommet lidt efter det siden når man ser på hvad de sælges.

Det der gjorde mest ondt var vel egentlig DOS/windows hvor man sad med en 386sx og brugte pharlap dos extender for at på liv mere plads i livet.

Nu er verden jo helt anderledes - set herfra ... - så vi er nogen der ikke kan forstå nytten af at køre 64 bit når 32 bit kører helt fint ;-) men det er jo noget helt andet... ;-)

  • 0
  • 0
#15 Casper Bang

AMD scoopede Intel totalt med 64 bit arkitekturen, der er radikalt anderledes.

Det skal jo så retfærdigvis siges, at Intel forsøgte at lægge x86 med dens svagheder (få general purpose registre) i graven med IA-64 (128 general purpose registre). De undervurderede bare hvor vigtigt binær kombatibilitet var. Ja de var vel på mange måder simpelthen for tidligt ude, i forhold til f.eks. ARM ikke har p.g.a. opsvinget og sammensmeltningen af mobile enheder. Det er ikke urealistisk at vi vil se Apple Macbooks på en ARM CPU om et par år!

Men nu bliver jeg da godt nok nysgerrig. Hvad er det ved AMD64 der er "radikalt anderledes"? Set udefra har AMD tilføjet et par ekstra registre men ellers gjort 32 bit EAX til subset af 64 bit RAX, i stil med hvordan Intel i sin tid udvidede 16 bit AX til EAX.

  • 1
  • 0
#16 Jens Dalsgaard Nielsen

også helt enig. Det var trals de ikke fik den aflivet. Jeg har ikke kigget på den nye ARM - kun rodet lidt med de gamle.

Man kan ikke så nemt spå om fremtiden, men jeg tror at OS snarere end CPU arkitektur blive mere relevant fremover. Det var vel bla ideen bag java, men de fleste fortolkende/JIT sprog er vel på den galej.

  • 1
  • 0
#18 Torben Mogensen Blogger

Hvorfor ikke bare gå helhjertet ind i det og lave en ren 64 bit processor?

Det 64-bit instruktionssæt, som ARM har præsenteret, virker som et ret rent 64-bit instruktionssæt uden alt for meget bagage fra 32-bit instruktionssættet.

Der er god forretningssans i at beholde en mode, der tillader afvikling af 32-bit kode for bagudkompatibilitet, så det er ikke nogen overraskelse. Generelt har ARM sørget for at deres processorer kan køre kode fra mindst et par ISA-versioner tilbage. Og det koster ikke alverden i hardware at gøre det, så hvorfor ikke?

  • 1
  • 0
#19 Torben Mogensen Blogger

Har disse boxe brug for at adressere mere end 4 GB RAM?

Jeg har ladet mig fortælle, at RAM er en af de mest omhyggeligt styrede ressourcer i computerspil, fordi der generelt ikke er nok. Så, jo, jeg kan sagtens forestille mig, at der kan blive behov for mere end 4GB.

Derudover vil forbedringerne omkring SIMD og FP bestemt være nyttige til computerspil.

  • 0
  • 0
Log ind eller Opret konto for at kommentere