Hva er AArch64? Hva du trenger å vite om denne CPU-arkitekturen

Det er mange CPUer arkitekturer der ute, med de største x86 og VÆPNE. Når det er sagt, har AArch64 sannsynligvis fløyet under radaren din. Selv den ganske beleste teknologientusiasten har kanskje aldri hørt om den, til tross for at den finnes i millioner av enheter. Vel, saken er at AArch64 ikke er mystisk så mye som det er et veldig forvirrende teknisk begrep. Her er det du trenger å vite om AArch64.

AArch64 er ARM64, liksom

Kort sagt, AArch64 er det offisielle navnet på Arms 64-bits instruksjonssettarkitektur (ISA) som ble introdusert med Armv8-A-oppdateringen. Det refererer nesten alltid til AArch64. Det er ikke klart nøyaktig hvorfor ARM64 ofte brukes i stedet for AArch64, men en del av forvirringen ser ut til å stamme fra to steder. En del av det er fordi 64-biters utvidelse av x86 er x86-64, så naturlig nok bør ARMs 64-bits utvidelse være ARM64. Apple så absolutt ut til å mene det og refererte til AArch64 som ARM64 frem til 2014. For de fleste er "AArch64 er ARM64" en svært tilfredsstillende forklaring.

Hvis du ønsker å bli virkelig teknisk, er AArch64 ikke ISA, men snarere henrettelsestilstand som lar ARM CPUer bruke (og bare bruke) A64-instruksjonssettet til ARMv8 ISA, som først ble introdusert med Armv8-A-arkitekturen. Hvis dette høres forvirrende ut, er det fordi det er det. Selv om du er kjent med datamaskinarkitektur, kan dette være vanskelig å forstå, så jeg skal forklare dette trinn for trinn.

Så teknisk sett er AArch64 en stat, ikke en ISA, men ingen bryr seg, ikke engang Arm selv.

ARM er en familie av relaterte ISA-er, og selv om forskjellige ISA-er vanligvis innebærer inkompatibilitet, er det strengt tatt ikke sant. Ulike versjoner av ARM ISA kalles ARMv1, ARMv2 og så videre, men disse ISA-ene inneholder det som i hovedsak er under-ISAer: A-profil, M-profil og R-profil. Den grunnleggende forskjellen mellom disse under-ISA-ene er minimumsmengden av instruksjoner hver enkelt bruker, med A-profil som bruker mest og M-profil som bruker minst. Så ARM ISA er delt inn i individuelle versjoner som ARMv8, og deretter er disse versjonene videre delt inn i forskjellige implementeringer av ISA.

Armv8-A er den første A-profilimplementeringen av ARMv8 ISA, som la til to nye ting: AArch32 og AArch64. Disse blir referert til som tilstander eller moduser, og de lar ARM CPUer få tilgang til forskjellige instruksjonssett, med AArch32 som inneholder 32-bit A32 og T32 instruksjonene, og AArch64 inneholder 64-bit A64 bruksanvisning. For eksempel, hvis en prosessor for øyeblikket er i AArch64-tilstanden og ønsker å bruke A32-instruksjoner, må den endre tilstanden til AArch32. I tillegg, i AArch64-modus, er både 32-biters og 64-biters registre tilgjengelige, mens i AArch32-modus bare 32-bits registrene er brukbare. Den mest forvirrende delen av alt dette er at alle disse tingene varierende refereres til som ISA-er og til og med Arm (selskapet som utvikler ARM ISA) er skyldig i dette.

Men hvis vi er supertekniske, er det slik det faktisk er: den åttende versjonen av ARM ISA, ARMv8, ble først implementert med Armv8-A, som inneholder to tilstander kalt AArch32 og AArch64. Når en CPU er i AArch64-tilstand, kan den utføre 64-bit A64-instruksjoner. Så teknisk sett er AArch64 en stat, ikke en ISA, men ingen bryr seg, ikke engang Arm selv.

Hvorfor både 32-bit og 64-bit betyr noe for ARM

Så AArch64 er faktisk ganske komplisert, og å måtte bytte tilstand bare for å bruke 32-biters og 64-biters instruksjoner virker tungvint. Saken er at støtte for både 32-bit og 64-bit var for viktig til å la være, så det må bare være slik. Det kom egentlig ned til to hovedproblemer: å måtte støtte gammel 32-bits programvare, og å forfølge moderne, høyytelses databehandling.

Hvis Arm ikke inkluderte innebygd støtte for 32-bits programvare i sin første 64-bits ISA, kunne det ha vært en katastrofe fordi, enkelt sagt, ingen ønsker å skrive om kode. Hvis ARMv8 krevde at alle skulle skrive ny programvare fra bunnen av, kunne det ha satt ISA inn i en dødsspiral, der ingen lager eller kjøper ARMv8-enheter på grunn av mangel på programvare, og så lager ikke utviklere apper på grunn av mangel på brukere, i det uendelige før Arm må ringe det slutter. Så 32-biters støtte var ikke omsettelig.

På den annen side var det heller ikke et alternativ å ikke implementere 64-bits databehandling. Intel og AMD, selskapene bak x86, hadde brukt 64-bits arkitekturer siden tidlig på 2000-tallet for sine fantastiske CPUer, selv om det på den tiden ikke var behov for 64-biters ARM-brikker da telefoner ikke trengte dem. Men oppfinnelsen av smarttelefonen endret alt, og alle ville at telefonene deres skulle gjøre flere ting. Ikke bare ville 64-bits støtte hjelpe smarttelefoner med å bli kraftigere, men det åpnet også døren for selskaper å lage ARM-brikker for markeder der x86 tradisjonelt dominerte, som bærbare datamaskiner og servere.

I utgangspunktet oppsto hele denne navneforvirringen fra at Arm måtte modernisere teknologien sin som svar på endrede prioriteringer. Arm trengte kanskje ikke å implementere 64-bits støtte på denne måten, men det gjorde den, og det var slik AArch64 ble til. Selv om AArch64 ikke er en ISA, er det slik de fleste bruker begrepet, på godt og vondt.