Bien que vous ayez probablement utilisé un appareil avec un processeur AArch64 à l'intérieur, vous ne savez peut-être pas ce que cela signifie. Voici ce que vous devez savoir.
Il existe de nombreux processeurs architectures là-bas, les plus grands étant x86 et BRAS. Cela dit, AArch64 a probablement volé sous votre radar. Même les passionnés de technologie assez avertis n'en ont peut-être jamais entendu parler, malgré le fait qu'il soit présent dans des millions d'appareils. Eh bien, le fait est qu'AArch64 n'est pas tant mystérieux que c'est un terme technique très déroutant. Voici ce que vous devez savoir sur AArch64.
AArch64 est ARM64, sorte de
Source: Bras
En bref, AArch64 est le nom officiel de l'architecture de jeu d'instructions (ISA) 64 bits d'Arm qui a été introduite avec la mise à jour Armv8-A. Il fait presque toujours référence à AArch64. On ne sait pas exactement pourquoi ARM64 est souvent utilisé à la place de AArch64, mais une partie de la confusion semble provenir de deux endroits. Cela est dû en partie au fait que l'extension 64 bits de x86 est x86-64, donc naturellement l'extension 64 bits d'ARM devrait être ARM64. Apple a certainement semblé le penser et a appelé AArch64 ARM64 jusqu'en 2014. Pour la plupart des gens, "AArch64 est ARM64" est une explication très satisfaisante.
Si vous voulez être vraiment technique, AArch64 n'est pas l'ISA, mais plutôt le état d'exécution qui permet aux processeurs ARM d'utiliser (et d'utiliser uniquement) le jeu d'instructions A64 de l'ISA ARMv8, qui a été introduit pour la première fois avec l'architecture Armv8-A. Si cela semble déroutant, c'est parce que ça l'est. Même si vous êtes familier avec l'architecture informatique, cela peut être difficile à comprendre, alors je vais vous expliquer cela étape par étape.
Donc techniquement, AArch64 est un état, pas un ISA, mais personne ne s'en soucie, pas même Arm lui-même.
ARM est une famille d'ISA apparentés, et bien que différents ISA impliquent généralement une incompatibilité, ce n'est pas strictement vrai. Différentes versions de l'ISA ARM sont appelées ARMv1, ARMv2, etc., mais ces ISA contiennent essentiellement des sous-ISA: profil A, profil M et profil R. La différence fondamentale entre ces sous-ISA est la quantité minimale d'instructions que chacune utilise, le profil A utilisant le plus et le profil M utilisant le moins. Ainsi, l'ARM ISA est divisé en versions individuelles telles que ARMv8, puis ces versions sont ensuite divisées en différentes implémentations de l'ISA.
Armv8-A est l'implémentation initiale du profil A de l'ISA ARMv8, qui a ajouté deux nouvelles choses: AArch32 et AArch64. Ceux-ci sont appelés états ou modes, et ils permettent aux processeurs ARM d'accéder à différents jeux d'instructions, avec AArch32 contenant les instructions A32 et T32 32 bits, et AArch64 contenant les instructions A64 64 bits instructions. Par exemple, si un processeur est actuellement dans l'état AArch64 et veut utiliser les instructions A32, il doit changer son état en AArch32. De plus, en mode AArch64, les registres 32 bits et 64 bits sont accessibles, tandis qu'en mode AArch32, seuls les registres 32 bits sont utilisables. La partie la plus déroutante de tout cela est que toutes ces choses sont appelées de manière variable ISA et même Arm (la société qui développe l'ARM ISA) est coupable de cela.
Mais si nous sommes super techniques, c'est comme ça: la huitième version de l'ARM ISA, ARMv8, a d'abord été implémentée avec Armv8-A, qui contient deux états appelés AArch32 et AArch64. Lorsqu'un processeur est dans l'état AArch64, il peut exécuter des instructions A64 64 bits. Donc techniquement, AArch64 est un état, pas un ISA, mais personne ne s'en soucie, pas même Arm lui-même.
Pourquoi 32 bits et 64 bits sont importants pour ARM
Donc AArch64 est en fait assez compliqué, et devoir changer d'état juste pour utiliser des instructions 32 bits et 64 bits semble fastidieux. Le fait est que la prise en charge des versions 32 bits et 64 bits était trop importante pour être ignorée, il doit donc en être ainsi. Cela se résumait en fait à deux problèmes majeurs: la nécessité de prendre en charge les anciens logiciels 32 bits et la poursuite d'une informatique moderne et performante.
Si Arm n'avait pas inclus la prise en charge native des logiciels 32 bits dans son premier ISA 64 bits, cela aurait pu être un désastre car, en termes simples, personne ne veut réécrire le code. Si ARMv8 obligeait tout le monde à écrire de nouveaux logiciels à partir de zéro, cela aurait pu plonger l'ISA dans une spirale de la mort, où personne ne fabrique ou n'achète Les appareils ARMv8 en raison d'un manque de logiciel, puis les développeurs ne créent pas d'applications en raison d'un manque d'utilisateurs, à l'infini jusqu'à ce qu'Arm doive l'appeler quitte. Ainsi, le support 32 bits n'était pas négociable.
D'autre part, ne pas implémenter l'informatique 64 bits n'était pas non plus une option. Intel et AMD, les sociétés à l'origine du x86, utilisaient des architectures 64 bits depuis le début des années 2000 pour leurs processeurs incroyables, bien qu'à l'époque il n'y ait pas eu d'appel pour des puces ARM 64 bits car les téléphones n'en avaient pas besoin. Mais l'invention du smartphone a tout changé, et tout le monde voulait que son téléphone fasse plus de choses. Non seulement la prise en charge 64 bits aiderait les smartphones à devenir plus puissants, mais elle ouvrait également la porte pour les entreprises de fabriquer des puces ARM pour les marchés où x86 dominait traditionnellement, comme les ordinateurs portables et les serveurs.
Fondamentalement, toute cette confusion de dénomination est née du fait qu'Arm devait moderniser sa technologie en réponse à l'évolution des priorités. Peut-être qu'Arm n'avait pas besoin d'implémenter le support 64 bits de cette manière, mais il l'a fait, et c'est ainsi qu'AArch64 est né. Bien que AArch64 ne soit pas un ISA, c'est ainsi que la plupart des gens utilisent le terme, pour le meilleur ou pour le pire.