Vad är AArch64? Vad du behöver veta om denna CPU-arkitektur

Det finns många CPU arkitekturer där ute, med de största x86 och ÄRM. Med det sagt, AArch64 har förmodligen flugit under din radar. Även den ganska beläste teknikentusiasten kanske aldrig har hört talas om det, trots att det finns i miljontals enheter. Tja, grejen är att AArch64 inte är mystiskt så mycket som det är en mycket förvirrande teknisk term. Här är vad du behöver veta om AArch64.

AArch64 är ARM64, typ

Kort sagt, AArch64 är det officiella namnet för Arms 64-bitars instruktionsuppsättningsarkitektur (ISA) som introducerades med Armv8-A-uppdateringen. Det hänvisar nästan alltid till AArch64. Det är inte klart exakt varför ARM64 ofta används i stället för AArch64, men en del av förvirringen verkar härröra från två ställen. En del av det beror på att 64-bitars förlängning av x86 är x86-64, så naturligtvis bör ARMs 64-bitars förlängning vara ARM64. Apple verkade verkligen tro det och hänvisade till AArch64 som ARM64 fram till 2014. För de flesta är "AArch64 är ARM64" en mycket tillfredsställande förklaring.

Om du vill bli riktigt teknisk är AArch64 inte ISA, utan snarare avrättningsstat som tillåter ARM-processorer att använda (och endast använda) A64-instruktionsuppsättningen av ARMv8 ISA, som först introducerades med Armv8-A-arkitekturen. Om detta låter förvirrande är det för att det är det. Även om du är bekant med datorarkitektur kan detta vara svårt att förstå, så jag ska förklara detta steg för steg.

Så tekniskt sett är AArch64 en stat, inte en ISA, men ingen bryr sig, inte ens Arm själv.

ARM är en familj av relaterade ISA, och även om olika ISA vanligtvis innebär inkompatibilitet, är det inte strikt sant. Olika versioner av ARM ISA kallas ARMv1, ARMv2 och så vidare, men dessa ISA innehåller vad som i huvudsak är sub-ISA: A-profil, M-profil och R-profil. Den grundläggande skillnaden mellan dessa sub-ISA är den minsta mängd instruktioner som var och en använder, där A-profilen använder mest och M-profilen använder minst. Så ARM ISA är uppdelad i individuella versioner som ARMv8, och sedan delas dessa versioner upp ytterligare i olika implementeringar av ISA.

Armv8-A är den första A-profilimplementeringen av ARMv8 ISA, som lade till två nya saker: AArch32 och AArch64. Dessa kallas tillstånd eller lägen, och de tillåter ARM-processorer att komma åt olika instruktionsuppsättningar, med AArch32 som innehåller 32-bitars A32- och T32-instruktionerna, och AArch64 innehåller 64-bitars A64 instruktioner. Till exempel, om en processor för närvarande är i AArch64-tillståndet och vill använda A32-instruktioner, måste den ändra sitt tillstånd till AArch32. I AArch64-läge är dessutom både 32-bitars- och 64-bitarsregistren tillgängliga, medan i AArch32-läge endast 32-bitarsregistren är användbara. Den mest förvirrande delen av allt detta är att alla dessa saker varierande kallas ISA och även Arm (företaget som utvecklar ARM ISA) är skyldig till detta.

Men om vi är supertekniska är det så här det faktiskt är: den åttonde versionen av ARM ISA, ARMv8, implementerades först med Armv8-A, som innehåller två tillstånd som kallas AArch32 och AArch64. När en CPU är i AArch64-tillståndet kan den utföra 64-bitars A64-instruktioner. Så tekniskt sett är AArch64 en stat, inte en ISA, men ingen bryr sig, inte ens Arm själv.

Varför både 32-bitars och 64-bitars betydelse för ARM

Så AArch64 är faktiskt ganska komplicerat, och att behöva byta tillstånd bara för att använda 32-bitars och 64-bitars instruktioner verkar besvärligt. Saken är den att stöd för både 32-bitars och 64-bitars var för viktigt för att missa, så det måste bara vara så här. Det kom egentligen till två stora frågor: att behöva stödja gammal 32-bitars programvara och att bedriva modern, högpresterande datoranvändning.

Om Arm inte inkluderade inbyggt stöd för 32-bitars programvara i sin första 64-bitars ISA, kunde det ha varit en katastrof eftersom, enkelt uttryckt, ingen vill skriva om koden. Om ARMv8 krävde att alla skulle skriva ny programvara från grunden, kunde det ha satt ISA i en dödsspiral, där ingen gör eller köper ARMv8-enheter på grund av brist på programvara, och sedan skapar inte utvecklare appar på grund av brist på användare, i oändlighet tills Arm måste ringa det kvitt. Så, 32-bitars stöd var inte förhandlingsbart.

Å andra sidan, att inte implementera 64-bitars beräkningar var inte heller ett alternativ. Intel och AMD, företagen bakom x86, hade använt 64-bitarsarkitekturer sedan början av 2000-talet för sina fantastiska processorer, även om det vid den tiden inte fanns något krav på 64-bitars ARM-chips eftersom telefoner inte behövde dem. Men uppfinningen av smarttelefonen förändrade allt, och alla ville att deras telefoner skulle göra fler saker. Inte bara skulle 64-bitars stöd hjälpa smartphones att bli kraftfullare, utan det öppnade också dörren för företag att tillverka ARM-chips för marknader där x86 traditionellt dominerade, som bärbara datorer och servrar.

I grund och botten uppstod hela denna namnförvirring från att Arm behövde modernisera sin teknik som svar på ändrade prioriteringar. Arm behövde kanske inte implementera 64-bitars stöd på det här sättet, men det gjorde det, och det var så AArch64 kom till. Även om AArch64 inte är en ISA, är det så de flesta använder termen, på gott och ont.