Въпреки че вероятно сте използвали устройство с процесор AArch64 вътре, може да не знаете какво означава това. Ето какво трябва да знаете.
Има много CPU архитектури там, като най-големите са x86 и ARM. Като каза това, AArch64 вероятно е прелетял под радара ви. Дори доста начетният технологичен ентусиаст може никога да не е чувал за него, въпреки факта, че присъства в милиони устройства. Е, работата е там, че AArch64 не е толкова мистериозен, колкото е много объркващ технически термин. Ето какво трябва да знаете за AArch64.
AArch64 е ARM64, нещо като
Източник: Арм
Накратко, AArch64 е официалното име за 64-битовата архитектура на набор от инструкции (ISA) на Arm, която беше въведена с актуализацията Armv8-A. Почти винаги се отнася до AArch64. Не е ясно точно защо ARM64 често се използва вместо AArch64, но част от объркването изглежда произтича от две места. Част от това е, защото 64-битовото разширение на x86 е x86-64, така че естествено 64-битовото разширение на ARM трябва да бъде ARM64. Apple определено смяташе така и наричаше AArch64 ARM64 до 2014 г. За повечето хора "AArch64 е ARM64" е много задоволително обяснение.
Ако искате да станете наистина технически, AArch64 не е ISA, а по-скоро състояние на изпълнение което позволява на процесорите на ARM да използват (и да използват само) набора от инструкции A64 на ARMv8 ISA, който беше въведен за първи път с архитектурата Armv8-A. Ако това звучи объркващо, това е, защото е така. Дори и да сте запознати с компютърната архитектура, това може да е трудно за разбиране, така че ще обясня това стъпка по стъпка.
Така че технически, AArch64 е състояние, а не ISA, но никой не го интересува, дори самото Arm.
ARM е семейство от свързани ISA и въпреки че различните ISA обикновено предполагат несъвместимост, това не е абсолютно вярно. Различните версии на ARM ISA се наричат ARMv1, ARMv2 и т.н., но тези ISA съдържат това, което по същество са под-ISA: A-профил, M-профил и R-профил. Основната разлика между тези под-ISA е минималното количество инструкции, които всеки използва, като A-профилът използва най-много, а M-профилът използва най-малко. И така, ARM ISA е разделен на отделни версии като ARMv8, а след това тези версии са допълнително разделени на различни реализации на ISA.
Armv8-A е първоначалната реализация на A-профил на ARMv8 ISA, която добави две нови неща: AArch32 и AArch64. Те се наричат състояния или режими и позволяват на ARM процесорите да имат достъп до различни набори от инструкции, с AArch32, съдържащ 32-битовите A32 и T32 инструкции, и AArch64, съдържащ 64-битовите A64 инструкции. Например, ако процесор в момента е в състояние AArch64 и иска да използва инструкции A32, той трябва да промени състоянието си на AArch32. Освен това в режим AArch64 са достъпни както 32-битовите, така и 64-битовите регистри, докато в режим AArch32 могат да се използват само 32-битовите регистри. Най-объркващата част от всичко това е, че всички тези неща се наричат променливо ISA и дори Arm (компанията, която разработва ARM ISA) е виновна за това.
Но ако сме супер технически, ето как всъщност е: осмата версия на ARM ISA, ARMv8, беше внедрена за първи път с Armv8-A, който съдържа две състояния, наречени AArch32 и AArch64. Когато процесорът е в състояние AArch64, той може да изпълнява 64-битови A64 инструкции. Така че технически, AArch64 е състояние, а не ISA, но никой не го интересува, дори самото Arm.
Защо и 32-битовите, и 64-битовите са от значение за ARM
Така че AArch64 всъщност е доста сложен и необходимостта от превключване на състоянията само за използване на 32-битови и 64-битови инструкции изглежда тромаво. Работата е там, че поддръжката както за 32-битови, така и за 64-битови е твърде важна, за да се пропусне, така че просто трябва да бъде по този начин. Наистина се свеждаше до два основни проблема: необходимост от поддръжка на стар 32-битов софтуер и преследване на модерни, високопроизводителни изчисления.
Ако Arm не включи естествена поддръжка за 32-битов софтуер в първата си 64-битова ISA, това можеше да е катастрофа, защото, казано просто, никой не иска да пренаписва кода. Ако ARMv8 изискваше всеки да пише нов софтуер от нулата, това можеше да постави ISA в спирала на смъртта, където никой не прави или купува ARMv8 устройства поради липса на софтуер и след това разработчиците не правят приложения поради липса на потребители, ad infinitum, докато Arm не трябва да го извика напуска. Така че 32-битовата поддръжка не подлежи на обсъждане.
От друга страна, неприлагането на 64-битови изчисления също не беше опция. Intel и AMD, компаниите зад x86, използват 64-битови архитектури от началото на 2000 г. за своите невероятни процесори, въпреки че по това време нямаше призив за 64-битови ARM чипове, тъй като телефоните не се нуждаеха от тях. Но изобретяването на смартфона промени всичко и всички искаха телефоните им да правят повече неща. Не само че 64-битовата поддръжка ще помогне на смартфоните да станат по-мощни, но също така отвори вратата за компаниите да правят ARM чипове за пазари, където x86 традиционно доминира, като лаптопи и сървъри.
По принцип цялото това объркване при именуване възникна от нуждата на Arm да модернизира технологията си в отговор на променящите се приоритети. Може би Arm не е трябвало да прилага 64-битова поддръжка по този начин, но го направи и така се появи AArch64. Въпреки че AArch64 не е ISA, това е начина, по който повечето хора използват термина, за добро или за лошо.