Bár valószínűleg használt olyan eszközt, amelyben AArch64 processzor van, lehet, hogy nem tudja, mit jelent. Íme, amit tudnod kell.
Sok CPU van architektúrák odakint, a legnagyobbakkal x86 és KAR. Ennek ellenére az AArch64 valószínűleg a radarod alatt repült. Még a meglehetősen olvasott tech-rajongó is talán soha nem hallott róla, annak ellenére, hogy több millió készülékben van jelen. Nos, az a helyzet, hogy az AArch64 nem annyira titokzatos, mint inkább egy nagyon zavaros szakkifejezés. Íme, amit az AArch64-ről tudnia kell.
Az AArch64 az ARM64, amolyan
Forrás: Arm
Röviden, az AArch64 az Arm 64 bites utasításkészlet-architektúrájának (ISA) hivatalos neve, amelyet az Armv8-A frissítéssel vezettek be. Szinte mindig az AArch64-re utal. Nem világos, hogy pontosan miért használják gyakran az ARM64-et az AArch64 helyett, de úgy tűnik, hogy a zavar egy része két helyről fakad. Ennek részben az az oka, hogy az x86 64 bites kiterjesztése x86-64, tehát az ARM 64 bites kiterjesztésének természetesen ARM64-nek kell lennie. Az Apple minden bizonnyal így gondolta, és 2014-ig az AArch64-et ARM64-nek nevezte. A legtöbb ember számára az "AArch64 is ARM64" nagyon kielégítő magyarázat.
Ha igazán technikássá akarsz válni, az AArch64 nem az ISA, hanem inkább az végrehajtási állapot amely lehetővé teszi az ARM CPU-k számára, hogy az ARMv8 ISA A64 utasításkészletét használják (és csak használják), amelyet először az Armv8-A architektúrával vezettek be. Ha ez zavaróan hangzik, az azért van, mert az. Még ha ismeri is a számítógépes architektúrát, ezt nehéz lehet megérteni, ezért lépésről lépésre elmagyarázom.
Tehát technikailag az AArch64 egy állam, nem egy ISA, de senkit nem érdekel, még magát az Armet sem.
Az ARM a kapcsolódó ISA-k családja, és bár a különböző ISA-k általában inkompatibilitást jeleznek, ez nem teljesen igaz. Az ARM ISA különböző verzióit ARMv1-nek, ARMv2-nek és így tovább hívják, de ezek az ISA-k lényegében al-ISA-kat tartalmaznak: A-profil, M-profil és R-profil. Az alapvető különbség ezen al-ISA-k között az egyes utasítások minimális mennyisége, ahol az A-profil használja a legtöbbet, az M-profil pedig a legkevesebbet. Tehát az ARM ISA különálló verziókra, például ARMv8-ra van felosztva, majd ezeket a verziókat tovább osztják az ISA különböző megvalósításaira.
Az Armv8-A az ARMv8 ISA kezdeti A-profil implementációja, amely két újdonsággal egészült ki: AArch32 és AArch64. Ezeket állapotoknak vagy módoknak nevezik, és lehetővé teszik az ARM CPU-k számára, hogy hozzáférjenek a különböző utasításkészletekhez, A 32 bites A32 és T32 utasításokat tartalmazó AArch32, valamint a 64 bites A64 utasításokat tartalmazó AArch64 utasítás. Például, ha egy processzor jelenleg AArch64 állapotban van, és A32 utasításokat akar használni, akkor az állapotát AArch32-re kell módosítania. Ezenkívül AArch64 módban a 32 bites és a 64 bites regiszterek is elérhetők, míg AArch32 módban csak a 32 bites regiszterek használhatók. A legzavaróbb az egészben az, hogy ezeket a dolgokat változóan ISA-nak nevezik, és még az Arm (az ARM ISA-t fejlesztő cég) is hibás ebben.
De ha szupertechnikák vagyunk, akkor ez valójában így van: az ARM ISA nyolcadik változatát, az ARMv8-at először az Armv8-A-val valósították meg, amely két AArch32 és AArch64 állapotot tartalmaz. Amikor egy CPU AArch64 állapotban van, 64 bites A64 utasításokat tud végrehajtani. Tehát technikailag az AArch64 egy állam, nem egy ISA, de senkit nem érdekel, még magát az Armet sem.
Miért fontos mind a 32 bites, mind a 64 bites az ARM számára?
Tehát az AArch64 valójában meglehetősen bonyolult, és az állapotváltás csak a 32 bites és 64 bites utasítások használatához nehézkesnek tűnik. A helyzet az, hogy a 32 bites és a 64 bites támogatása is túl fontos volt ahhoz, hogy figyelmen kívül hagyjuk, ezért ennek így kell lennie. Valójában két fő probléma merült fel: a régi 32 bites szoftverek támogatása, valamint a modern, nagy teljesítményű számítástechnika követése.
Ha az Arm nem tartalmazza a 32 bites szoftverek natív támogatását az első 64 bites ISA-jában, az katasztrófa lehetett, mert leegyszerűsítve senki sem akarja átírni a kódot. Ha az ARMv8 megköveteli mindenkitől, hogy a semmiből új szoftvereket írjon, akkor az ISA-t egy halálspirálba helyezhette volna, ahol senki sem gyárt és nem vásárol ARMv8 eszközök a szoftver hiánya miatt, majd a fejlesztők nem készítenek alkalmazásokat a felhasználók hiánya miatt, a végtelenségig, amíg Armnak nem kell hívnia kilép. Tehát a 32 bites támogatás nem volt alku tárgya.
Másrészt a 64 bites számítástechnika megvalósításának mellőzése sem volt opció. Az Intel és az AMD, az x86 mögött álló vállalatok a 2000-es évek eleje óta használnak 64 bites architektúrákat csodálatos CPU-k, bár akkoriban még nem kértek 64 bites ARM chipeket, mivel a telefonoknak nem volt szükségük rájuk. De az okostelefon feltalálása mindent megváltoztatott, és mindenki azt akarta, hogy a telefonja több dolgot csináljon. A 64 bites támogatás nemcsak az okostelefonok erősebbé válását segíti elő, hanem az ajtót is megnyitotta cégek számára, hogy ARM chipeket készítsenek olyan piacokra, ahol az x86 hagyományosan dominált, mint például a laptopok és szerverek.
Alapvetően ez az egész elnevezési zavar abból adódott, hogy az Arm-nak korszerűsítenie kellett technológiáját a változó prioritások miatt. Lehet, hogy Armnak nem kellett ilyen módon megvalósítania a 64 bites támogatást, de igen, és így jött létre az AArch64. Bár az AArch64 nem ISA, a legtöbb ember így használja ezt a kifejezést, jóban vagy rosszban.