Chociaż prawdopodobnie korzystałeś z urządzenia z procesorem AArch64 w środku, możesz nie wiedzieć, co to znaczy. Oto, co musisz wiedzieć.
Jest wiele procesorów architektury tam, z największymi są x86 I RAMIĘ. Powiedziawszy to, AArch64 prawdopodobnie przeleciał pod twoim radarem. Nawet dość oczytany entuzjasta technologii mógł nigdy o nim nie słyszeć, mimo że jest obecny w milionach urządzeń. Cóż, chodzi o to, że AArch64 nie jest tak tajemniczy, jak bardzo mylący termin techniczny. Oto, co musisz wiedzieć o AArch64.
AArch64 to w pewnym sensie ARM64
źródło: ramię
Krótko mówiąc, AArch64 to oficjalna nazwa 64-bitowej architektury zestawu instrukcji Arm (ISA), która została wprowadzona wraz z aktualizacją Armv8-A. Prawie zawsze odnosi się do AArch64. Nie jest jasne, dlaczego ARM64 jest często używany zamiast AArch64, ale część zamieszania wydaje się wynikać z dwóch miejsc. Częściowo dlatego, że 64-bitowym rozszerzeniem x86 jest x86-64, więc naturalnie 64-bitowym rozszerzeniem ARM powinno być ARM64. Apple z pewnością tak myślał i do 2014 roku określał AArch64 jako ARM64. Dla większości ludzi „AArch64 to ARM64” jest bardzo zadowalającym wyjaśnieniem.
Jeśli chcesz uzyskać naprawdę techniczne informacje, AArch64 nie jest ISA, ale raczej stan wykonania który pozwala procesorom ARM używać (i tylko używać) zestawu instrukcji A64 ARMv8 ISA, który został po raz pierwszy wprowadzony w architekturze Armv8-A. Jeśli brzmi to myląco, to dlatego, że tak jest. Nawet jeśli znasz architekturę komputerów, może to być trudne do zrozumienia, więc wyjaśnię to krok po kroku.
Technicznie rzecz biorąc, AArch64 jest stanem, a nie ISA, ale nikogo to nie obchodzi, nawet samego Arm.
ARM to rodzina powiązanych ISA i chociaż różne ISA zwykle oznaczają niezgodność, nie jest to do końca prawdą. Różne wersje ARM ISA są nazywane ARMv1, ARMv2 i tak dalej, ale te ISA zawierają zasadniczo podrzędne ISA: profil A, profil M i profil R. Podstawową różnicą między tymi podprogramami ISA jest minimalna liczba instrukcji, z których każdy korzysta, przy czym profil A wykorzystuje najwięcej, a profil M najmniej. Tak więc ARM ISA jest podzielony na poszczególne wersje, takie jak ARMv8, a następnie te wersje są dalej dzielone na różne implementacje ISA.
Armv8-A to początkowa implementacja profilu A ARMv8 ISA, która dodała dwie nowe rzeczy: AArch32 i AArch64. Są one określane jako stany lub tryby i umożliwiają procesorom ARM dostęp do różnych zestawów instrukcji, z AArch32 zawierającym 32-bitowe instrukcje A32 i T32 oraz AArch64 zawierającym 64-bitowe instrukcje A64 instrukcje. Na przykład, jeśli procesor jest aktualnie w stanie AArch64 i chce korzystać z instrukcji A32, musi zmienić swój stan na AArch32. Dodatkowo w trybie AArch64 dostępne są zarówno rejestry 32-bitowe, jak i 64-bitowe, natomiast w trybie AArch32 dostępne są tylko rejestry 32-bitowe. Najbardziej mylącą częścią tego wszystkiego jest to, że wszystkie te rzeczy są różnie określane jako ISA, a nawet Arm (firma, która opracowuje ARM ISA) jest tego winna.
Ale jeśli jesteśmy supertechniczni, tak to faktycznie wygląda: ósma wersja ARM ISA, ARMv8, została po raz pierwszy zaimplementowana z Armv8-A, który zawiera dwa stany o nazwach AArch32 i AArch64. Gdy procesor jest w stanie AArch64, może wykonywać 64-bitowe instrukcje A64. Technicznie rzecz biorąc, AArch64 jest stanem, a nie ISA, ale nikogo to nie obchodzi, nawet samego Arm.
Dlaczego zarówno wersja 32-bitowa, jak i 64-bitowa mają znaczenie dla ARM
Tak więc AArch64 jest w rzeczywistości dość skomplikowany, a konieczność przełączania stanów tylko po to, by użyć instrukcji 32-bitowych i 64-bitowych, wydaje się kłopotliwa. Rzecz w tym, że obsługa zarówno wersji 32-bitowej, jak i 64-bitowej była zbyt ważna, aby ją pominąć, więc po prostu musi tak być. Tak naprawdę sprowadzało się to do dwóch głównych problemów: konieczności obsługi starego 32-bitowego oprogramowania i dążenia do nowoczesnego, wysokowydajnego przetwarzania.
Gdyby ARM nie zawierał natywnej obsługi oprogramowania 32-bitowego w swoim pierwszym 64-bitowym ISA, mogłoby dojść do katastrofy, ponieważ, mówiąc prościej, nikt nie chce przepisywać kodu. Gdyby ARMv8 wymagał od wszystkich pisania nowego oprogramowania od podstaw, mogłoby to doprowadzić ISA do spirali śmierci, w której nikt nie produkuje ani nie kupuje Urządzenia ARMv8 z powodu braku oprogramowania, a potem programiści nie tworzą aplikacji z powodu braku użytkowników, w nieskończoność, dopóki Arm nie będzie musiał tego nazwać skwitowany. Tak więc wsparcie 32-bitowe nie podlegało negocjacjom.
Z drugiej strony rezygnacja z przetwarzania 64-bitowego również nie wchodziła w grę. Intel i AMD, firmy stojące za architekturą x86, używały architektur 64-bitowych od wczesnych lat 2000. niesamowite procesory, chociaż w tamtym czasie nie było zapotrzebowania na 64-bitowe układy ARM, ponieważ telefony ich nie potrzebowały. Ale wynalezienie smartfona zmieniło wszystko i wszyscy chcieli, aby ich telefony robiły więcej rzeczy. Obsługa 64-bitów nie tylko pomogłaby smartfonom stać się potężniejszymi, ale także otworzyła drzwi dla firm produkujących układy ARM dla rynków, na których tradycyjnie dominował procesor x86, takich jak laptopy i serwery.
Zasadniczo całe to zamieszanie w nazewnictwie wynikało z tego, że ARM musiał zmodernizować swoją technologię w odpowiedzi na zmieniające się priorytety. Być może ARM nie musiał implementować obsługi 64-bitowej w ten sposób, ale tak się stało i tak powstał AArch64. Chociaż AArch64 nie jest ISA, tak większość ludzi używa tego terminu, na dobre i na złe.