Selvom du sandsynligvis har brugt en enhed med en AArch64-processor indeni, ved du måske ikke, hvad det betyder. Her er hvad du behøver at vide.
Der er mange CPU'er arkitekturer derude, hvor de største er x86 og ARM. Når det er sagt, så har AArch64 sandsynligvis fløjet under din radar. Selv den ret vellæste teknologientusiast har måske aldrig hørt om det, på trods af at det findes i millioner af enheder. Tja, sagen er, at AArch64 ikke er så mystisk, som det er et meget forvirrende teknisk udtryk. Her er hvad du behøver at vide om AArch64.
AArch64 er ARM64, sådan set
Kilde: Arm
Kort sagt er AArch64 det officielle navn for Arms 64-bit instruktionssætarkitektur (ISA), der blev introduceret med Armv8-A-opdateringen. Det refererer næsten altid til AArch64. Det er ikke klart, præcis hvorfor ARM64 ofte bruges i stedet for AArch64, men en del af forvirringen ser ud til at stamme fra to steder. En del af det er, fordi 64-bit udvidelsen af x86 er x86-64, så naturligvis bør ARMs 64-bit udvidelse være ARM64. Apple syntes bestemt at mene det og henviste til AArch64 som ARM64 indtil 2014. For de fleste mennesker er "AArch64 er ARM64" en meget tilfredsstillende forklaring.
Hvis du vil blive rigtig teknisk, er AArch64 ikke ISA, men snarere henrettelsestilstand der tillader ARM CPU'er at bruge (og kun bruge) A64-instruktionssættet fra ARMv8 ISA, som først blev introduceret med Armv8-A-arkitekturen. Hvis det lyder forvirrende, er det fordi det er det. Selvom du er fortrolig med computerarkitektur, kan dette være svært at forstå, så jeg vil forklare dette trin for trin.
Så teknisk set er AArch64 en stat, ikke en ISA, men ingen er ligeglad, ikke engang Arm selv.
ARM er en familie af relaterede ISA'er, og selvom forskellige ISA'er normalt indebærer inkompatibilitet, er det strengt taget ikke sandt. Forskellige versioner af ARM ISA kaldes ARMv1, ARMv2 og så videre, men disse ISA'er indeholder, hvad der i det væsentlige er underISA'er: A-profil, M-profil og R-profil. Den grundlæggende forskel mellem disse under-ISA'er er den mindste mængde instruktioner, hver enkelt bruger, hvor A-profilen bruger flest og M-profilen bruger mindst. Så ARM ISA er opdelt i individuelle versioner såsom ARMv8, og derefter er disse versioner yderligere opdelt i forskellige implementeringer af ISA.
Armv8-A er den indledende A-profilimplementering af ARMv8 ISA, som tilføjede to nye ting: AArch32 og AArch64. Disse omtales som tilstande eller tilstande, og de giver ARM CPU'er adgang til forskellige instruktionssæt, med AArch32 indeholdende 32-bit A32 og T32 instruktionerne, og AArch64 indeholdende 64-bit A64 instruktioner. For eksempel, hvis en processor i øjeblikket er i AArch64-tilstanden og ønsker at bruge A32-instruktioner, skal den ændre sin tilstand til AArch32. Derudover er både 32-bit og 64-bit registre tilgængelige i AArch64-tilstand, mens det i AArch32-tilstand kun er 32-bit-registre, der kan bruges. Den mest forvirrende del af alt dette er, at alle disse ting variabelt omtales som ISA'er, og selv Arm (firmaet, der udvikler ARM ISA) er skyldig i dette.
Men hvis vi er super tekniske, er det sådan her det faktisk er: den ottende version af ARM ISA, ARMv8, blev først implementeret med Armv8-A, som indeholder to tilstande kaldet AArch32 og AArch64. Når en CPU er i AArch64-tilstand, kan den udføre 64-bit A64-instruktioner. Så teknisk set er AArch64 en stat, ikke en ISA, men ingen er ligeglad, ikke engang Arm selv.
Hvorfor både 32-bit og 64-bit betyder noget for ARM
Så AArch64 er faktisk ret kompliceret, og det virker besværligt at skulle skifte tilstand bare for at bruge 32-bit og 64-bit instruktioner. Sagen er, at understøttelse af både 32-bit og 64-bit var for vigtig til at gå glip af, så det skal bare være sådan. Det kom virkelig ned til to store problemer: at skulle understøtte gammel 32-bit software og at forfølge moderne, højtydende databehandling.
Hvis Arm ikke inkluderede indbygget understøttelse af 32-bit software i sin første 64-bit ISA, kunne det have været en katastrofe, for kort sagt, ingen ønsker at omskrive kode. Hvis ARMv8 krævede, at alle skulle skrive ny software fra bunden, kunne det have sat ISA i en dødsspiral, hvor ingen laver eller køber ARMv8-enheder på grund af mangel på software, og så laver udviklere ikke apps på grund af mangel på brugere, i det uendelige, indtil Arm skal kalde det holder op. Så 32-bit support var ikke til forhandling.
På den anden side, ikke at implementere 64-bit computing var heller ikke en mulighed. Intel og AMD, firmaerne bag x86, havde brugt 64-bit arkitekturer siden begyndelsen af 2000'erne til deres fantastiske CPU'er, selvom der på det tidspunkt ikke var opfordring til 64-bit ARM-chips, da telefoner ikke havde brug for dem. Men opfindelsen af smartphonen ændrede alt, og alle ville have deres telefoner til at gøre flere ting. Ikke alene ville 64-bit support hjælpe smartphones med at blive mere kraftfulde, men det åbnede også døren for virksomheder at lave ARM-chips til markeder, hvor x86 traditionelt dominerede, som bærbare computere og servere.
Grundlæggende opstod hele denne navneforvirring, fordi Arm havde behov for at modernisere sin teknologi som svar på skiftende prioriteter. Måske behøvede Arm ikke at implementere 64-bit support på denne måde, men det gjorde den, og det var sådan AArch64 opstod. Selvom AArch64 ikke er en ISA, er det sådan, de fleste mennesker bruger udtrykket, på godt og ondt.