Le nombre de versions ISA (ARM Instruction Set Architectures) distinctes a lentement augmenté, Arm ajoutant une nouvelle version toutes les quelques années. La version ISA la plus ancienne couramment utilisée aujourd’hui est ARMv6, avec l’ARMv6 ISA (ARM11) trouvé dans le Raspberry Pi SBC et le Raspberry Pi Zero (BCM2835) d’origine. L’ARMv6 ISA a été introduit en 2002, suivi par ARMv7 en 2005 (début de la série Cortex-A) et ARMv8 en 2011. Ce dernier était remarquable pour l’ajout du support 64 bits.

Avec ARMv7 étant le premier des cœurs Cortex et ARMv8 ajoutant la prise en charge 64 bits sous la forme d’AArch64, quelles fonctionnalités notables ARMv9 apporte-t-il à la table? Comme annoncé plus tôt cette année, l’objectif d’ARMv9 semble être d’ajouter toute une série de fonctionnalités qui devraient améliorer le traitement vectoriel (extensions vectorielles, ou SVE) ainsi que le traitement du signal numérique (DSP) et la sécurité, avec son architecture de calcul confidentiel (CCA). .

En plus de cela, ARMv9 inclut également toutes les fonctionnalités qui ont été ajoutées avec ARMv8.1, v8.2, v8.3 et ainsi de suite. En substance, cela rend un processeur basé sur ARMv9 théoriquement capable de rivaliser avec le meilleur d’Intel et d’AMD.

Bienvenue dans le haut de gamme

Il devrait être évident que ARMv9 n’est pas un ISA que nous verrons bientôt dans les ordinateurs monocarte (SBC) à petit budget comme le Raspberry Pi et ses parents. Le SoC BCM2711 du Raspberry Pi 4, par exemple, utilise des cœurs Cortex-A72, qui implémentent la spécification ARMv8-A. Depuis lors, la mise à jour ARMv8.1-A a ajouté:

  • Instructions supplémentaires pour la lecture / écriture atomique et plus encore.
  • Prise en charge améliorée de la virtualisation (par exemple, extensions d’hôte de virtualisation).
  • Extensions SIMD (vectorielles).

En 2016, ARMv8.2-A a ajouté:

  • Instructions supplémentaires pour une variété de tâches telles que le traitement de données en virgule flottante demi-précision.
  • Extensions vectorielles évolutives (SVE): traitement SIMD.

Suivi plus tard cette année par ARMv8.3-A:

  • Virtualisation imbriquée.
  • Prise en charge avancée des nombres complexes SIMD.

Les trois mises à jour suivantes ont ajouté et affiné plus de fonctionnalités, créant une liste impressionnante de mises à jour obligatoires et facultatives de la spécification ARMv-8 de base. Sans surprise, ce grand nombre de spécifications ISA est un peu compliqué, et l’une des choses qu’ARMv9 accomplit est de rassembler toutes ces versions dans une seule spécification.

Une autre chose qu’ARMv9 ajoute par rapport à ARMv8 est la version deux de l’extension vectorielle évolutive (SVE2), le successeur de SVE, et essentiellement le remplacement des instructions NEON SIMD. Comme le note Arm, les instructions NEON sont toujours dans ARMv9, mais uniquement pour une compatibilité ascendante. Comme le suggère la partie «  évolutive  » de SVE, l’un des principaux avantages de SVE par rapport à NEON est qu’il s’adapte au matériel sous-jacent, permettant à des plates-formes encore plus petites et moins puissantes de gérer le même code basé sur SVE2 qu’une puce haut de gamme.

Il est révélateur que SVE a ses racines dans le HPC (calcul haute performance), le supercalculateur japonais Fukagu ​​étant l’un des premiers systèmes à l’utiliser lors de son introduction l’année dernière. Cela signifie que le SVE2 d’ARMv9 sera très important pour les applications qui traitent des données qui bénéficient d’algorithmes basés sur SIMD.

Royaumes et mémoire balisée

La nouveauté d’ARMv9 est le concept de «royaumes», qui peut être considéré comme une sorte de conteneur sécurisé dans lequel le code peut s’exécuter sans affecter le reste du système. Cela fonctionne avec par exemple un hyperviseur, ce dernier confiant une grande partie des opérations liées à la sécurité à un nouveau Realm Manager. Les détails exacts ne sont pas connus à ce stade, au-delà des informations communiquées par Arm lors de sa récente annonce.

Exemple de base de la façon dont les royaumes CCA peuvent être utilisés. (Crédit: Arm)

Pas nouveau dans la v9, mais disponible depuis la v8.5 est l’extension de balisage de mémoire (MTE). Le marquage de la mémoire est un mécanisme permettant de suivre les opérations de mémoire illégales au niveau matériel. Ceci est similaire à ce que fait l’outil Memcheck de Valgrind lorsqu’il garde la trace des accès à la mémoire afin de détecter les débordements de tampon et les écritures et lectures hors limites, sauf avec MTE, cela est pris en charge au niveau matériel.

La présence de ces fonctionnalités dans la spécification ARMv9 signifie que les futurs processeurs ARM et SoC offriront probablement des options de virtualisation et de sécurité qui les rendent intéressants pour les centres de données et d’autres applications où la virtualisation et la sécurité sont essentielles.

Restez à l’écoute

Il y a quelques jours à peine, Arm a révélé les deux premiers cœurs de processeur basés sur la spécification ARMv9. Ces noyaux Neoverse V1 («Zeus») et N2 («Perseus»). Les deux ciblent les centres de données et les applications HPC, avec Amazon AWS, Tencent, Oracle et d’autres fournisseurs de cloud susceptibles de les utiliser.

Le fait est qu’à court terme, ARMv9 est quelque chose avec lequel le consommateur moyen n’aura que peu ou rien à voir, car il n’y a pas beaucoup d’incitation pour de nombreuses plates-formes à changer, même de la référence ARMv8-A à ARMv6-A. La nécessité d’obtenir une licence pour de nouveaux cœurs et une nouvelle adresse IP est bien sûr un autre facteur ici. Tout cela signifie que pour les années à venir, il est peu probable que le silicium ARMv9 apparaisse dans les appareils mobiles ou les nouveaux ordinateurs monocarte. (Cela ressemble à un défi pour les lecteurs de Hackaday, n’est-ce pas?)

Cela ne veut pas dire que ce n’est pas un développement intéressant, surtout une fois que ARMv9 avec SVE2 et CCA apparaîtra finalement sur ces plates-formes. Avec des performances SIMD considérablement améliorées, par exemple, de nombreuses tâches de traitement et d’encodage de données deviendront soudainement beaucoup plus rapides, ce qui pourrait être une aubaine pour quiconque souhaite piloter quotidiennement un système ARM.

L’écosystème ARM aujourd’hui

Comme évoqué au début de cet article, l’écosystème ARM est relativement fragmenté à ce stade, en particulier si l’on considère les cartes Raspberry Pi très populaires et leur utilisation simultanée et continue d’ARMv6, ARMv7 et ARMv8, avec un support médiocre pour AArch64 sur le dernier. Bien qu’il ait ses avantages à pouvoir utiliser la compatibilité ascendante dans ARMv8 et v7 pour exécuter des binaires ARMv6 (‘armhf’), il supprime également une grande partie des avantages du passage à ces nouveaux ISA.

Avec la prise en charge 32 bits dans le monde d’Intel et d’AMD déjà fermement une chose du passé, il semble plutôt étrange de s’accrocher aux ISA ARM 32 bits uniquement, en particulier lors de la proclamation simultanée des capacités de ces systèmes comme un quotidien potentiel. conducteur. Même la mémoire système de 4 Go et les limitations de mémoire par processus qui accompagnent une architecture 32 bits sont suffisantes pour gâcher beaucoup de plaisir potentiel là-bas.

Combien de temps faudra-t-il avant qu’ARMv6 et ARMv7 rejoignent ARMv5 pour prendre leur retraite? Ce n’est pas une question facile à répondre à ce stade, même si la réponse jouera probablement un rôle majeur dans la réponse à la question de savoir combien de temps il faudra probablement à ARMv9 pour commencer à jouer un rôle pertinent en dehors des centres de données.

Une note sur les microcontrôleurs

Au milieu de toutes ces discussions sur les puces de serveur et les SoC, il est parfois facile d’oublier que les microcontrôleurs ARM utilisent également des ISA liés aux ISA de profil d’application. Ces spécifications post-fixes -M (microcontrôleur) ont également été mises à jour au fil des ans, le Cortex-M55 utilisant le jeu d’instructions ARMv8.1-M. Cet ISA ajoute les extensions de traitement vectoriel Helium, ajoutant des capacités SIMD significatives aux microcontrôleurs.

Bien que le profil d’application d’ARMv9 ne se traduise pas directement dans les profils de microcontrôleur de manière fonctionnalité pour fonctionnalité, toutes les fonctionnalités qui ont du sens pour une plate-forme MCU sont très susceptibles d’être traduites dans cette dernière d’une manière ou d’une autre. Les fonctionnalités de virtualisation n’ont guère de sens, mais le marquage de la mémoire comme dans MTE et d’autres fonctionnalités de débogage et de surveillance pourraient être souhaitables.

Lorsque les premiers microcontrôleurs basés sur le Cortex-M55 apparaîtront dans les années à venir, cela devrait nous donner un aperçu de ce que ARMv9 peut également apporter dans ce domaine. La question de savoir si nous allons programmer ces MCU à partir de systèmes de bureau basés sur ARM d’ici là est cependant toujours en suspens.