Ce este AArch64? Ce trebuie să știți despre această arhitectură CPU

Sunt multe procesoare arhitecturi acolo, cu cei mai mari fiind x86 și BRAŢ. Acestea fiind spuse, probabil că AArch64 a trecut sub radarul tău. Chiar și pasionatul de tehnologie destul de bine citit s-ar putea să nu fi auzit niciodată de ea, în ciuda faptului că este prezent în milioane de dispozitive. Ei bine, treaba este că AArch64 nu este atât de misterios, ci este un termen tehnic foarte confuz. Iată ce trebuie să știți despre AArch64.

AArch64 este ARM64, un fel

Pe scurt, AArch64 este numele oficial pentru arhitectura setului de instrucțiuni (ISA) pe 64 de biți a Arm, care a fost introdusă odată cu actualizarea Armv8-A. Aproape întotdeauna se referă la AArch64. Nu este clar de ce ARM64 este adesea folosit în locul lui AArch64, dar o parte din confuzie pare să provină din două locuri. O parte din aceasta se datorează faptului că extensia pe 64 de biți a x86 este x86-64, așa că, firește, extensia pe 64 de biți a ARM ar trebui să fie ARM64. Apple a părut cu siguranță să gândească așa și s-a referit la AArch64 ca ARM64 până în 2014. Pentru majoritatea oamenilor, „AArch64 este ARM64” este o explicație foarte satisfăcătoare.

Dacă vrei să devii cu adevărat tehnic, AArch64 nu este ISA, ci mai degrabă stare de execuție care permite procesoarelor ARM să utilizeze (și să utilizeze numai) setul de instrucțiuni A64 al ARMv8 ISA, care a fost introdus pentru prima dată cu arhitectura Armv8-A. Dacă acest lucru sună confuz, asta este pentru că este. Chiar dacă sunteți familiarizat cu arhitectura computerului, acest lucru poate fi dificil de înțeles, așa că voi explica acest lucru pas cu pas.

Deci, din punct de vedere tehnic, AArch64 este un stat, nu un ISA, dar nimănui nu-i pasă, nici măcar Arm în sine.

ARM este o familie de ISA-uri înrudite și, deși diferite ISA-uri implică de obicei incompatibilitate, acest lucru nu este strict adevărat. Diferite versiuni ale ARM ISA sunt numite ARMv1, ARMv2 și așa mai departe, dar aceste ISA-uri conțin ceea ce sunt în esență sub-ISA-uri: A-profile, M-profile și R-profile. Diferența de bază dintre aceste sub-ISA este cantitatea minimă de instrucțiuni pe care fiecare le folosește, profilul A utilizând cel mai mult și profilul M folosind cel mai puțin. Deci, ARM ISA este împărțit în versiuni individuale, cum ar fi ARMv8, iar apoi acele versiuni sunt împărțite în diferite implementări ale ISA.

Armv8-A este implementarea inițială a profilului A a ARMv8 ISA, care a adăugat două lucruri noi: AArch32 și AArch64. Acestea sunt denumite stări sau moduri și permit procesoarelor ARM să acceseze diferite seturi de instrucțiuni, cu AArch32 care conține instrucțiunile A32 și T32 pe 32 de biți și AArch64 care conține A64 pe 64 de biți instrucțiuni. De exemplu, dacă un procesor este în prezent în starea AArch64 și dorește să folosească instrucțiunile A32, trebuie să-și schimbe starea în AArch32. În plus, în modul AArch64, atât registrele de 32 de biți, cât și cele de 64 de biți sunt accesibile, în timp ce în modul AArch32 sunt utilizabile doar registrele de 32 de biți. Partea cea mai confuză din toate acestea este că toate aceste lucruri sunt denumite în mod variabil ISA-uri și chiar și Arm (compania care dezvoltă ARM ISA) este vinovată de acest lucru.

Dar dacă suntem super tehnici, așa este de fapt: a opta versiune a ARM ISA, ARMv8, a fost implementată pentru prima dată cu Armv8-A, care conține două stări numite AArch32 și AArch64. Când un procesor este în starea AArch64, poate executa instrucțiuni A64 pe 64 de biți. Deci, din punct de vedere tehnic, AArch64 este un stat, nu un ISA, dar nimănui nu-i pasă, nici măcar Arm în sine.

De ce contează atât 32 de biți, cât și 64 de biți pentru ARM

Deci, AArch64 este de fapt destul de complicat, iar nevoia de a schimba stările doar pentru a folosi instrucțiuni pe 32 de biți și 64 de biți pare greoaie. Chestia este că suportul atât pentru 32 de biți, cât și pentru 64 de biți a fost prea important pentru a trece, așa că trebuie să fie așa. S-a rezumat într-adevăr la două probleme majore: necesitatea de a susține software-ul vechi pe 32 de biți și urmărirea unui calcul modern, de înaltă performanță.

Dacă Arm nu ar fi inclus suport nativ pentru software-ul pe 32 de biți în primul său ISA pe 64 de biți, ar fi putut fi un dezastru pentru că, simplu, nimeni nu vrea să rescrie codul. Dacă ARMv8 ar fi cerut tuturor să scrie software nou de la zero, ar fi putut pune ISA într-o spirală a morții, în care nimeni nu produce sau cumpără. Dispozitivele ARMv8 din cauza lipsei de software, iar apoi dezvoltatorii nu fac aplicații din cauza lipsei de utilizatori, la infinit până când Arm trebuie să-l numească renunță. Deci, suportul pe 32 de biți nu era negociabil.

Pe de altă parte, nici neimplementarea calculului pe 64 de biți nu era o opțiune. Intel și AMD, companiile din spatele x86, au folosit arhitecturi pe 64 de biți de la începutul anilor 2000 pentru procesoare uimitoare, deși la acea vreme nu exista niciun apel pentru cipuri ARM pe 64 de biți, deoarece telefoanele nu aveau nevoie de ele. Dar inventarea smartphone-ului a schimbat totul și toată lumea dorea ca telefoanele lor să facă mai multe lucruri. Nu numai că suportul pe 64 de biți ar ajuta smartphone-urile să devină mai puternice, dar a deschis și ușa companiilor să producă cipuri ARM pentru piețele în care x86 domina în mod tradițional, cum ar fi laptopurile și servere.

Practic, toată această confuzie de denumire a apărut din cauza nevoii Armului să-și modernizeze tehnologia ca răspuns la prioritățile în schimbare. Poate că Arm nu a trebuit să implementeze suportul pe 64 de biți în acest mod, dar a făcut-o și așa a apărut AArch64. Deși AArch64 nu este un ISA, așa folosesc cei mai mulți oameni termenul, în bine și în rău.