Architecture ARM

Un ARMv7 était utilisé pour alimenter les anciennes versions des populaires ordinateurs monocartes Raspberry Pi, comme ce Raspberry Pi 2 de 2015.

Un ARMv7 est également utilisé pour alimenter la famille d’ordinateurs monocartes CuBox.

Voir aussi : Comparaison des cœurs ARMv7-A

L’architecture ARM 32 bits, telle que l’ARMv7-A (implémentant AArch32 ; voir la section sur l’ARMv8-A pour en savoir plus), était l’architecture la plus utilisée dans les appareils mobiles en 2011.

Depuis 1995, le manuel de référence de l’architecture ARM a été la principale source de documentation sur l’architecture et le jeu d’instructions du processeur ARM, distinguant les interfaces que tous les processeurs ARM doivent prendre en charge (telles que la sémantique des instructions) des détails de mise en œuvre qui peuvent varier. L’architecture a évolué au fil du temps, et la version sept de l’architecture, ARMv7, définit trois « profils » d’architecture :

  • Profil A, le profil « Application », mis en œuvre par les cœurs 32 bits de la série Cortex-A et par certains cœurs non-ARM
  • Profil R, le profil « Temps réel », mis en œuvre par les cœurs de la série Cortex-R
  • Profil M, le profil « Microcontrôleur », mis en œuvre par la plupart des cœurs de la série Cortex-M

Bien que les profils d’architecture aient d’abord été définis pour ARMv7, ARM a ensuite défini l’architecture ARMv6-M (utilisée par le Cortex M0/M0+/M1) comme un sous-ensemble du profil ARMv7-M avec moins d’instructions.

Modes CPUEdit

Sauf dans le profil M, l’architecture ARM 32 bits spécifie plusieurs modes CPU, en fonction des caractéristiques de l’architecture implémentée. À tout moment, le CPU ne peut être que dans un seul mode, mais il peut changer de mode en raison d’événements externes (interruptions) ou par programmation.

  • Mode utilisateur : Le seul mode non privilégié.
  • Mode FIQ : Un mode privilégié qui est entré chaque fois que le processeur accepte une demande d’interruption rapide.
  • Mode IRQ : Un mode privilégié qui est entré chaque fois que le processeur accepte une interruption.
  • Mode superviseur (svc) : Un mode privilégié entré chaque fois que le processeur est réinitialisé ou lorsqu’une instruction SVC est exécutée.
  • Mode abandon : Un mode privilégié qui est entré chaque fois qu’une exception d’abandon de pré-extraction ou d’abandon de données se produit.
  • Mode indéfini : Un mode privilégié qui est entré chaque fois qu’une exception d’instruction non définie se produit.
  • Mode système (ARMv4 et plus) : Le seul mode privilégié qui n’est pas entré par une exception. On ne peut y accéder qu’en exécutant une instruction qui écrit explicitement dans les bits de mode du registre d’état du programme en cours (CPSR) à partir d’un autre mode privilégié (pas à partir du mode utilisateur).
  • Mode moniteur (ARMv6 et ARMv7 Security Extensions, ARMv8 EL3) : Un mode moniteur est introduit pour supporter l’extension TrustZone dans les cœurs ARM.
  • Mode Hyp (ARMv7 Virtualization Extensions, ARMv8 EL2) : Un mode hyperviseur qui prend en charge les exigences de virtualisation Popek et Goldberg pour le fonctionnement non sécurisé du processeur.
  • Mode Thread (ARMv6-M, ARMv7-M, ARMv8-M) : Un mode qui peut être spécifié comme privilégié ou non privilégié. L’utilisation du pointeur de pile principal (MSP) ou du pointeur de pile de processus (PSP) peut également être spécifiée dans le registre CONTROL avec accès privilégié. Ce mode est conçu pour les tâches de l’utilisateur dans un environnement RTOS, mais il est généralement utilisé en bare-metal pour la super-boucle.
  • Mode Handler (ARMv6-M, ARMv7-M, ARMv8-M) : Un mode dédié à la gestion des exceptions (sauf les RESET qui sont gérés en mode Thread). Le mode Handler utilise toujours MSP et fonctionne en niveau privilégié.

Édition du jeu d’instructions

L’implémentation ARM originale (et ultérieure) était câblée sans microcode, comme le processeur 8 bits 6502 beaucoup plus simple utilisé dans les micro-ordinateurs Acorn antérieurs.

L’architecture ARM 32 bits (et l’architecture 64 bits pour la plupart) comprend les caractéristiques RISC suivantes :

  • Architecture load/store.
  • Aucune prise en charge des accès mémoire non alignés dans la version originale de l’architecture. ARMv6 et les versions ultérieures, à l’exception de certaines versions de microcontrôleurs, prennent en charge les accès non alignés pour les instructions de chargement/stockage de demi-mot et de mot unique avec certaines limitations, comme l’absence d’atomicité garantie.
  • Fichier de registres uniforme de 16 × 32 bits (y compris le compteur de programme, le pointeur de pile et le registre de liaison).
  • La largeur d’instruction fixe de 32 bits pour faciliter le décodage et le pipelining, au prix d’une diminution de la densité du code. Plus tard, le jeu d’instructions Thumb a ajouté des instructions de 16 bits et a augmenté la densité du code.
  • Exécution le plus souvent à un seul cycle d’horloge.

Pour compenser la conception plus simple, par rapport à des processeurs comme l’Intel 80286 et le Motorola 68020, certaines caractéristiques de conception supplémentaires ont été utilisées :

  • L’exécution conditionnelle de la plupart des instructions réduit le surdébit de branchement et compense l’absence de prédicteur de branchement dans les premières puces.
  • Les instructions arithmétiques modifient les codes de condition uniquement lorsque cela est souhaité.
  • Le shifter à barillet 32 bits peut être utilisé sans pénalité de performance avec la plupart des instructions arithmétiques et des calculs d’adresse.
  • Possède de puissants modes d’adressage indexés.
  • Un registre de liaison prend en charge les appels de fonctions feuilles rapides.
  • Un sous-système d’interruption simple, mais rapide, à 2 niveaux de priorité, possède des banques de registres commutées.

Instructions arithmétiquesModification

L’ARM comprend des opérations arithmétiques entières pour l’addition, la soustraction et la multiplication ; certaines versions de l’architecture prennent également en charge les opérations de division.

L’ARM prend en charge les multiplications 32 bits × 32 bits avec un résultat 32 bits ou 64 bits, bien que les cœurs Cortex-M0 / M0+ / M1 ne prennent pas en charge les résultats 64 bits. Certains cœurs ARM prennent également en charge les multiplications 16 bits × 16 bits et 32 bits × 16 bits.

Les instructions de division sont uniquement incluses dans les architectures ARM suivantes :

  • Les architectures ARMv7-M et ARMv7E-M incluent toujours des instructions de division.
  • L’architecture ARMv7-R inclut toujours les instructions de division dans le jeu d’instructions Thumb, mais en option dans son jeu d’instructions 32 bits.
  • L’architectureARMv7-A inclut facultativement les instructions de division. Les instructions pourraient ne pas être implémentées, ou implémentées uniquement dans le jeu d’instructions Thumb, ou implémentées à la fois dans les jeux d’instructions Thumb et ARM, ou implémentées si les extensions de virtualisation sont incluses.

RegistresEdit

.

Registres à travers les modes du CPU
usr sys svc abt und irq fiq
R0
R1
R2
R3
R4
R5
R6
R7
R8 R8_fiq
R9 R9_fiq
R10 R10_fiq
R11 R11_fiq
R12 R12_fiq
R13 R13_svc R13_abt R13_und R13_irq R13_fiq
R14 R14_svc R14_und R14_irq R14_fiq R14_fiq
R15
CPSR
SPSR_svc SPSR_abt SPSR_und SPSR_irq SPSR_fiq

Les registres R0 à R7 sont les mêmes dans tous les modes d’unité centrale ; ils ne sont jamais mis en banque.

Les registres R8 à R12 sont les mêmes dans tous les modes d’unité centrale, à l’exception du mode FIQ. Le mode FIQ possède ses propres registres distincts R8 à R12.

R13 et R14 sont mis en banque dans tous les modes privilégiés de l’UC, à l’exception du mode système. C’est-à-dire que chaque mode qui peut être entré à cause d’une exception possède ses propres R13 et R14. Ces registres contiennent généralement le pointeur de pile et l’adresse de retour des appels de fonction, respectivement.

Alias:

  • R13 est également appelé SP, le pointeur de pile.
  • R14 est également appelé LR, le registre de liaison.
  • R15 est également appelé PC, le compteur de programme.

Le registre d’état du programme en cours (CPSR) comporte les 32 bits suivants.

  • M (bits 0-4) est le bit de mode du processeur.
  • T (bit 5) est le bit d’état du pouce.
  • F (bit 6) est le bit de désactivation FIQ.
  • I (bit 7) est le bit de désactivation IRQ.
  • A (bit 8) est le bit de désactivation d’abandon de données imprécises.
  • E (bit 9) est le bit d’endiannessede données.
  • IT (bits 10-15 et 25-26) est le bit d’état if-then.
  • GE (bits 16-19) est le bit plus grand que ou égal à.
  • DNM (bits 20-23) est le bit de ne pas modifier.
  • J (bit 24) est le bit d’état Java.
  • Q (bit 27) est le bit de débordement collant.
  • V (bit 28) est le bit de débordement.
  • C (bit 29) est le bit de report/emprunt/extension.
  • Z (bit 30) est le bit de zéro.
  • N (bit 31) est le bit négatif/moins que.

Exécution conditionnelleEdit

Presque toutes les instructions ARM ont une fonction d’exécution conditionnelle appelée prédication, qui est mise en œuvre avec un sélecteur de code de condition de 4 bits (le prédicat). Pour permettre une exécution inconditionnelle, l’un des codes à quatre bits fait que l’instruction est toujours exécutée. La plupart des autres architectures de CPU n’ont des codes de condition que sur les instructions de branchement.

Bien que le prédicat occupe quatre des 32 bits d’un code d’instruction, et réduise donc considérablement les bits d’encodage disponibles pour les déplacements dans les instructions d’accès à la mémoire, il évite les instructions de branchement lors de la génération du code pour les petites if déclarations. Outre l’élimination des instructions de branchement elles-mêmes, cela préserve le pipeline d’extraction/décodage/exécution au coût d’un seul cycle par instruction sautée.

Un algorithme qui fournit un bon exemple d’exécution conditionnelle est l’algorithme euclidien basé sur la soustraction pour le calcul du plus grand diviseur commun. Dans le langage de programmation C, l’algorithme peut être écrit comme:

int gcd(int a, int b) { while (a != b) // We enter the loop when a<b or a>b, but not when a==b if (a > b) // When a>b we do this a -= b; else // When a<b we do that (no if(a<b) needed since a!=b is checked in while condition) b -= a; return a;}

Le même algorithme peut être réécrit d’une manière plus proche des instructions ARM cibles comme :

loop: // Compare a and b GT = a > b; LT = a < b; NE = a != b; // Perform operations based on flag results if(GT) a -= b; // Subtract *only* if greater-than if(LT) b -= a; // Subtract *only* if less-than if(NE) goto loop; // Loop *only* if compared values were not equal return a;

et codé en langage assembleur comme :

; assign a to register r0, b to r1loop: CMP r0, r1 ; set condition "NE" if (a != b), ; "GT" if (a > b), ; or "LT" if (a < b) SUBGT r0, r0, r1 ; if "GT" (Greater Than), a = a-b; SUBLT r1, r1, r0 ; if "LT" (Less Than), b = b-a; BNE loop ; if "NE" (Not Equal), then loop B lr ; if the loop is not entered, we can safely return

ce qui évite les branchements autour des clauses then et else. Si r0 et r1 sont égales alors aucune des instructions SUB ne sera exécutée, éliminant le besoin d’une branche conditionnelle pour mettre en œuvre la vérification while en haut de la boucle, par exemple si SUBLE (inférieur ou égal) avait été utilisé.

L’une des façons dont le code Thumb fournit un codage plus dense est de supprimer le sélecteur à quatre bits des instructions non branchées.

Autres caractéristiquesModifier

Une autre caractéristique du jeu d’instructions est la possibilité de replier les shifts et les rotations dans les instructions de « traitement des données » (arithmétique, logique et déplacement registre-registre), de sorte que, par exemple, l’instruction C

a += (j << 2);

pourrait être rendue comme une instruction à un seul mot et à un seul cycle :

ADD Ra, Ra, Rj, LSL #2

Il en résulte que le programme ARM typique est plus dense que prévu avec moins d’accès à la mémoire ; le pipeline est donc utilisé plus efficacement.

Le processeur ARM possède également des caractéristiques rarement vues dans d’autres architectures RISC, comme l’adressage relatif au PC (en effet, sur l’ARM 32 bits, le PC est l’un de ses 16 registres) et les modes d’adressage pré- et post-incrément.

Le jeu d’instructions ARM a augmenté au fil du temps. Certains premiers processeurs ARM (avant l’ARM7TDMI), par exemple, n’ont pas d’instruction pour stocker une quantité de deux octets.

Pipeline et autres problèmes d’implémentationEdit

L’ARM7 et les implémentations antérieures ont un pipeline à trois étages ; les étages étant la récupération, le décodage et l’exécution. Les conceptions plus performantes, telles que l’ARM9, ont des pipelines plus profonds : Le Cortex-A8 possède treize étages. Les modifications supplémentaires apportées à l’implémentation pour une meilleure performance comprennent un additionneur plus rapide et une logique de prédiction de branchement plus étendue. La différence entre les cœurs ARM7DI et ARM7DMI, par exemple, était un multiplicateur amélioré ; d’où l’ajout du « M ».

CoprocesseursEdit

L’architecture ARM (pré-ARMv8) fournit un moyen non intrusif d’étendre le jeu d’instructions en utilisant des « coprocesseurs » qui peuvent être adressés à l’aide d’instructions MCR, MRC, MRRC, MCRR et similaires. L’espace coprocesseur est divisé logiquement en 16 coprocesseurs avec des numéros de 0 à 15, le coprocesseur 15 (cp15) étant réservé à certaines fonctions de contrôle typiques comme la gestion des caches et le fonctionnement de la MMU sur les processeurs qui en possèdent une.

Dans les machines basées sur ARM, les périphériques sont généralement attachés au processeur en mappant leurs registres physiques dans l’espace mémoire ARM, dans l’espace coprocesseur, ou en se connectant à un autre périphérique (un bus) qui s’attache à son tour au processeur. Les accès au coprocesseur ont une latence plus faible, de sorte que certains périphériques – par exemple, un contrôleur d’interruption XScale – sont accessibles des deux manières : par la mémoire et par les coprocesseurs.

Dans d’autres cas, les concepteurs de puces intègrent uniquement le matériel en utilisant le mécanisme du coprocesseur. Par exemple, un moteur de traitement d’images peut être un petit cœur ARM7TDMI combiné à un coprocesseur dont les opérations spécialisées permettent de prendre en charge un ensemble spécifique de primitives de transcodage HDTV.

DébogageEdit

Cette section nécessite des citations supplémentaires pour vérification. Veuillez aider à améliorer cet article en ajoutant des citations à des sources fiables. Le matériel non sourcé peut être contesté et supprimé. (Mars 2011) (Learn how and when to remove this template message)

Tous les processeurs ARM modernes comprennent des installations de débogage matériel, permettant aux débogueurs logiciels d’effectuer des opérations telles que l’arrêt, le stepping et le breakpointing du code à partir de la réinitialisation. Ces fonctions sont construites en utilisant le support JTAG, bien que certains cœurs plus récents supportent en option le protocole « SWD » à deux fils propre à ARM. Dans les cœurs ARM7TDMI, le « D » représente le support de débogage JTAG, et le « I » représente la présence d’un module de débogage « EmbeddedICE ». Pour les générations de cœurs ARM7 et ARM9, EmbeddedICE sur JTAG était une norme de débogage de facto, bien que non garantie sur le plan architectural.

L’architecture ARMv7 définit des facilités de débogage de base au niveau architectural. Celles-ci comprennent des points d’arrêt, des points de surveillance et l’exécution d’instructions dans un « mode de débogage » ; des facilités similaires étaient également disponibles avec EmbeddedICE. Le débogage en mode « halt » et « monitor » est supporté. Le mécanisme de transport réel utilisé pour accéder aux installations de débogage n’est pas spécifié architecturalement, mais les implémentations incluent généralement le support JTAG.

Il existe une architecture de débogage ARM « CoreSight » distincte, qui n’est pas requise architecturalement par les processeurs ARMv7.

Port d’accès au débogage

Le port d’accès au débogage (DAP) est une implémentation d’une interface de débogage ARM.

Il existe deux implémentations différentes prises en charge, le port de débogage JTAG à fil série (SWJ-DP) et le port de débogage à fil série (SW-DP).CMSIS-DAP est une interface standard qui décrit comment divers logiciels de débogage sur un PC hôte peuvent communiquer par USB à un micrologiciel fonctionnant sur un débogueur matériel, qui à son tour parle par SWD ou JTAG à un processeur ARM Cortex compatible avec CoreSight.

Instructions d’amélioration DSPEdit

Pour améliorer l’architecture ARM pour le traitement des signaux numériques et les applications multimédia, des instructions DSP ont été ajoutées au jeu. Celles-ci sont signifiées par un « E » dans le nom des architectures ARMv5TE et ARMv5TEJ. Les variantes E impliquent également T, D, M et I.

Les nouvelles instructions sont courantes dans les architectures de processeurs de signaux numériques (DSP). Elles comprennent des variations sur la multiplication-accumulation signée, l’addition et la soustraction saturées, et le comptage des zéros de tête.

Extensions SIMD pour le multimédiaEdit

Introduites dans l’architecture ARMv6, c’était un précurseur de l’Advanced SIMD, également connu sous le nom de Neon.

JazelleEdit

Article principal : Jazelle

Jazelle DBX (Direct Bytecode eXecution) est une technique qui permet d’exécuter le bytecode Java directement dans l’architecture ARM en tant que troisième état d’exécution (et jeu d’instructions) aux côtés des modes ARM et Thumb existants. La prise en charge de cet état est signifiée par le « J » dans l’architecture ARMv5TEJ et dans les noms des noyaux ARM9EJ-S et ARM7EJ-S. Le support de cet état est requis à partir de l’ARMv6 (sauf pour le profil ARMv7-M), bien que les cœurs plus récents n’incluent qu’une implémentation triviale qui ne fournit aucune accélération matérielle.

ThumbEdit

Pour améliorer la densité du code compilé, les processeurs depuis l’ARM7TDMI (sorti en 1994) disposent du jeu d’instructions Thumb, qui ont leur propre état. (Le « T » dans « TDMI » indique la caractéristique Thumb.) Lorsqu’il est dans cet état, le processeur exécute le jeu d’instructions Thumb, un codage 16 bits compact pour un sous-ensemble du jeu d’instructions ARM. La plupart des instructions Thumb sont directement mises en correspondance avec les instructions ARM normales. Le gain de place provient du fait que certains des opérandes des instructions sont implicites et que le nombre de possibilités est limité par rapport aux instructions ARM exécutées dans l’état du jeu d’instructions ARM.

Dans Thumb, les opcodes 16 bits ont moins de fonctionnalités. Par exemple, seules les branches peuvent être conditionnelles, et de nombreux opcodes sont limités à l’accès à la moitié seulement de tous les registres à usage général du processeur. Les opcodes plus courts améliorent la densité globale du code, même si certaines opérations nécessitent des instructions supplémentaires. Dans les situations où la largeur du port ou du bus mémoire est contrainte à moins de 32 bits, les opcodes Thumb plus courts permettent une augmentation des performances par rapport au code ARM 32 bits, car moins de code de programme peut avoir besoin d’être chargé dans le processeur sur la largeur de bande mémoire contrainte.

Contrairement aux architectures de processeur avec des instructions de longueur variable (16 ou 32 bits), comme le Cray-1 et le Hitachi SuperH, les jeux d’instructions ARM et Thumb existent indépendamment les uns des autres. Le matériel embarqué, tel que le Game Boy Advance, dispose généralement d’une petite quantité de RAM accessible avec un chemin de données complet de 32 bits ; la majorité est accessible via un chemin de données secondaire de 16 bits ou plus étroit. Dans cette situation, il est généralement judicieux de compiler le code Thumb et d’optimiser à la main quelques-unes des sections les plus gourmandes en CPU en utilisant des instructions ARM 32 bits complètes, en plaçant ces instructions plus larges dans la mémoire accessible par le bus 32 bits.

Le premier processeur doté d’un décodeur d’instructions Thumb était l’ARM7TDMI. Toutes les familles ARM9 et suivantes, y compris XScale, ont inclus un décodeur d’instructions Thumb. Il comprend des instructions adoptées à partir du SuperH d’Hitachi (1992), dont la licence a été accordée à ARM. Les plus petites familles de processeurs d’ARM (Cortex M0 et M1) n’implémentent que le jeu d’instructions Thumb 16 bits pour des performances maximales dans les applications les moins coûteuses.

Tumb-2Edit

La technologie Thumb-2 a été introduite dans le cœur ARM1156, annoncé en 2003. Thumb-2 étend le jeu d’instructions 16 bits limité de Thumb avec des instructions 32 bits supplémentaires pour donner plus d’ampleur au jeu d’instructions, produisant ainsi un jeu d’instructions de longueur variable. Un objectif déclaré pour Thumb-2 était d’atteindre une densité de code similaire à celle de Thumb avec des performances similaires à celles du jeu d’instructions ARM sur une mémoire 32 bits.

Thumb-2 étend le jeu d’instructions de Thumb avec la manipulation de champs de bits, les branches de table et l’exécution conditionnelle. Dans le même temps, le jeu d’instructions ARM a été étendu pour maintenir une fonctionnalité équivalente dans les deux jeux d’instructions. Un nouveau « langage d’assemblage unifié » (UAL) permet de générer des instructions Thumb ou ARM à partir du même code source ; les versions de Thumb vues sur les processeurs ARMv7 sont essentiellement aussi performantes que le code ARM (y compris la possibilité d’écrire des gestionnaires d’interruption). Cela nécessite un peu de précaution et l’utilisation d’une nouvelle instruction « IT » (if-then), qui permet d’exécuter jusqu’à quatre instructions successives en fonction d’une condition testée ou de son inverse. Lors de la compilation en code ARM, cette instruction est ignorée, mais lors de la compilation en Thumb, elle génère une instruction réelle. Par exemple :

; if (r0 == r1)CMP r0, r1ITE EQ ; ARM: no code ... Thumb: IT instruction; then r0 = r2;MOVEQ r0, r2 ; ARM: conditional; Thumb: condition via ITE 'T' (then); else r0 = r3;MOVNE r0, r3 ; ARM: conditional; Thumb: condition via ITE 'E' (else); recall that the Thumb MOV instruction has no bits to encode "EQ" or "NE".

Toutes les puces ARMv7 prennent en charge le jeu d’instructions Thumb. Toutes les puces de la série Cortex-A, de la série Cortex-R et de la série ARM11 prennent en charge à la fois  » l’état du jeu d’instructions ARM  » et  » l’état du jeu d’instructions Thumb « , tandis que les puces de la série Cortex-M ne prennent en charge que le jeu d’instructions Thumb.

Environnement d’exécution Thumb (ThumbEE)Edit

ThumbEE (appelé par erreur Thumb-2EE dans certaines documentations ARM), qui a été commercialisé sous le nom de Jazelle RCT (Runtime Compilation Target), a été annoncé en 2005, apparaissant pour la première fois dans le processeur Cortex-A8. ThumbEE est un quatrième état du jeu d’instructions, apportant de petites modifications au jeu d’instructions étendu Thumb-2. Ces modifications rendent le jeu d’instructions particulièrement adapté au code généré au moment de l’exécution (par exemple, par la compilation JIT) dans des environnements d’exécution gérés. ThumbEE est une cible pour des langages tels que Java, C#, Perl et Python, et permet aux compilateurs JIT de produire un code compilé plus petit sans impact sur les performances.

Les nouvelles fonctionnalités fournies par ThumbEE comprennent des vérifications automatiques des pointeurs nuls sur chaque instruction de chargement et de stockage, une instruction permettant d’effectuer une vérification des limites de tableau, et des instructions spéciales qui appellent un gestionnaire. En outre, parce qu’il utilise la technologie Thumb-2, ThumbEE permet d’accéder aux registres r8-r15 (où est conservé l’état de la VM Java de Jazelle/DBX). Les gestionnaires sont de petites sections de code fréquemment appelées, couramment utilisées pour mettre en œuvre des langages de haut niveau, comme l’allocation de mémoire pour un nouvel objet. Ces changements proviennent de la réaffectation d’une poignée d’opcodes, et du fait de savoir que le noyau est dans le nouvel état ThumbEE.

Le 23 novembre 2011, Arm Holdings a déprécié toute utilisation du jeu d’instructions ThumbEE, et ARMv8 supprime le support de ThumbEE.

Floating-point (VFP)Edit

La technologie VFP (Vector Floating Point) est une extension de coprocesseur d’unité à virgule flottante (FPU) à l’architecture ARM (implémentée différemment dans ARMv8 – les coprocesseurs n’y sont pas définis). Elle permet d’effectuer des calculs à virgule flottante de faible coût, en simple et double précision, entièrement conformes à la norme ANSI/IEEE Std 754-1985 relative à l’arithmétique à virgule flottante binaire. Le VFP fournit un calcul en virgule flottante adapté à un large éventail d’applications telles que les PDA, les smartphones, la compression et la décompression de la voix, les graphiques tridimensionnels et l’audio numérique, les imprimantes, les décodeurs et les applications automobiles. L’architecture VFP était destinée à prendre en charge l’exécution d’instructions courtes en « mode vectoriel », mais celles-ci opéraient sur chaque élément vectoriel de manière séquentielle et n’offraient donc pas les performances d’un véritable parallélisme vectoriel SIMD (single instruction, multiple data). Ce mode vectoriel a donc été supprimé peu de temps après son introduction, pour être remplacé par le SIMD avancé, beaucoup plus puissant, également connu sous le nom de Neon.

Certains dispositifs, comme l’ARM Cortex-A8, possèdent un module VFPLite réduit au lieu d’un module VFP complet, et nécessitent environ dix fois plus de cycles d’horloge par opération de flottaison. L’architecture pré-ARMv8 implémentait la virgule flottante/SIMD avec l’interface du coprocesseur. Les autres unités à virgule flottante et/ou SIMD que l’on trouve dans les processeurs basés sur ARM utilisant l’interface de coprocesseur comprennent FPA, FPE, iwMMXt, dont certaines ont été implémentées en logiciel par trapping mais auraient pu être implémentées en matériel. Ils fournissent certaines des mêmes fonctionnalités que VFP mais ne sont pas compatibles avec son opcode. FPA10 fournit également une précision étendue, mais implémente un arrondi correct (requis par IEEE 754) uniquement en simple précision.

VFPv1 Obsolète VFPv2 Une extension optionnelle du jeu d’instructions ARM dans les architectures ARMv5TE, ARMv5TEJ et ARMv6. VFPv2 possède 16 registres FPU de 64 bits. VFPv3 ou VFPv3-D32 Mis en œuvre sur la plupart des processeurs ARMv7 Cortex-A8 et A9. Il est rétrocompatible avec VFPv2, sauf qu’il ne peut pas piéger les exceptions à virgule flottante. La VFPv3 possède 32 registres FPU 64 bits en standard, ajoute des instructions VCVT pour convertir les scalaires, les flottants et les doubles, ajoute le mode immédiat à la VMOV de sorte que les constantes peuvent être chargées dans les registres FPU. VFPv3-D16 Comme ci-dessus, mais avec seulement 16 registres FPU de 64 bits. Mis en œuvre sur les processeurs Cortex-R4 et R5 et le Tegra 2 (Cortex-A9). VFPv3-F16 Peu courant ; il prend en charge la virgule flottante de demi-précision (16 bits) IEEE754-2008 comme format de stockage. VFPv4 ou VFPv4-D32 Mis en œuvre sur les processeurs ARMv7 Cortex-A12 et A15, Cortex-A7 dispose en option de VFPv4-D32 dans le cas d’un FPU avec Neon. La VFPv4 possède 32 registres FPU 64 bits en standard, ajoute le support de la demi-précision comme format de stockage et des instructions de multiplication-accumulation fusionnées aux caractéristiques de la VFPv3. VFPv4-D16 Comme ci-dessus, mais avec seulement 16 registres FPU de 64 bits. Mis en œuvre sur les processeurs Cortex-A5 et A7 dans le cas d’un FPU sans Neon. VFPv5-D16-M Implémenté sur Cortex-M7 lorsque l’option de noyau à virgule flottante à simple et double précision existe.

Dans Debian GNU/Linux, et ses dérivés comme Ubuntu et Linux Mint, armhf (ARM hard float) fait référence à l’architecture ARMv7 incluant l’extension matérielle supplémentaire à virgule flottante VFP3-D16 (et Thumb-2) ci-dessus. Les progiciels et les outils de compilation croisée utilisent les suffixes armhf vs arm/armel pour les différencier.

Edition Advanced SIMD (Neon)

L’extension Advanced SIMD (alias Neon ou « MPE » Media Processing Engine) est un jeu d’instructions SIMD combiné de 64 et 128 bits qui fournit une accélération standardisée pour les applications de traitement des médias et des signaux. Neon est inclus dans tous les dispositifs Cortex-A8, mais est optionnel dans les dispositifs Cortex-A9. Neon peut exécuter le décodage audio MP3 sur des processeurs fonctionnant à 10 MHz, et peut faire fonctionner le codec vocal AMR (adaptive multirate) GSM à 13 MHz. Il dispose d’un jeu d’instructions complet, de fichiers de registre séparés et d’un matériel d’exécution indépendant. Neon prend en charge les données en nombres entiers 8, 16, 32 et 64 bits et les données en virgule flottante simple précision (32 bits), ainsi que les opérations SIMD pour le traitement des données audio et vidéo, des graphiques et des jeux. Dans Neon, le SIMD prend en charge jusqu’à 16 opérations simultanées. Le matériel Neon partage les mêmes registres à virgule flottante que ceux utilisés dans VFP. Les dispositifs tels que les ARM Cortex-A8 et Cortex-A9 prennent en charge les vecteurs de 128 bits, mais s’exécutent avec 64 bits à la fois, tandis que les dispositifs Cortex-A15 plus récents peuvent exécuter 128 bits à la fois.

Une bizarrerie de Neon dans les périphériques ARMv7 est qu’il chasse tous les nombres subnormaux à zéro, et par conséquent le compilateur GCC ne l’utilisera pas à moins que -funsafe-math-optimizations, qui permet de perdre les dénormaux, ne soit activé. Le Neon « amélioré » défini depuis ARMv8 n’a pas cette bizarrerie, mais à partir de GCC 8.2, le même flag est toujours nécessaire pour activer les instructions Neon. En revanche, GCC considère que Neon est sûr sur AArch64 pour ARMv8.

Le projet Ne10 est le premier projet open-source d’ARM (dès sa création ; alors qu’ils ont acquis un projet plus ancien, maintenant connu sous le nom de Mbed TLS). La bibliothèque Ne10 est un ensemble de fonctions communes et utiles écrites à la fois en Neon et en C (pour la compatibilité). La bibliothèque a été créée pour permettre aux développeurs d’utiliser les optimisations Neon sans apprendre Neon, mais elle sert également d’ensemble d’exemples de code Neon intrinsèque et de code assembleur hautement optimisés pour les routines courantes de DSP, d’arithmétique et de traitement d’images. Le code source est disponible sur GitHub.

ArM Helium technologyEdit

Helium est l’extension vectorielle M-Profile (MVE). Elle ajoute plus de 150 instructions scalaires et vectorielles.

Extensions de sécuritéEdit

TrustZone (pour le profil Cortex-A)Edit

Les extensions de sécurité, commercialisées sous le nom de technologie TrustZone, se trouvent dans les architectures de profil d’application ARMv6KZ et ultérieures. Elle offre une alternative peu coûteuse à l’ajout d’un autre cœur de sécurité dédié à un SoC, en fournissant deux processeurs virtuels soutenus par un contrôle d’accès basé sur le matériel. Il permet au cœur de l’application de basculer entre deux états, appelés mondes (pour éviter toute confusion avec d’autres noms de domaines de capacités), afin d’empêcher la fuite d’informations du monde le plus fiable vers le monde le moins fiable. Ce changement de monde est généralement orthogonal à toutes les autres capacités du processeur, de sorte que chaque monde peut fonctionner indépendamment de l’autre tout en utilisant le même noyau. La mémoire et les périphériques sont alors mis au courant du monde d’exploitation du noyau et peuvent l’utiliser pour fournir un contrôle d’accès aux secrets et au code sur l’appareil.

Typiquement, un système d’exploitation riche est exécuté dans le monde moins fiable, avec un code plus petit spécialisé dans la sécurité dans le monde plus fiable, visant à réduire la surface d’attaque. Les applications typiques comprennent la fonctionnalité DRM pour contrôler l’utilisation des médias sur les appareils basés sur ARM, et empêcher toute utilisation non approuvée de l’appareil.

En pratique, étant donné que les détails spécifiques des implémentations propriétaires de TrustZone n’ont pas été divulgués publiquement pour examen, il n’est pas clair quel niveau d’assurance est fourni pour un modèle de menace donné, mais ils ne sont pas à l’abri d’une attaque.

Open Virtualization est une implémentation open source de l’architecture du monde de confiance pour TrustZone.

AMD a autorisé et incorporé la technologie TrustZone dans sa technologie de processeur sécurisé. Activés dans certains produits, mais pas tous, les APU d’AMD incluent un processeur Cortex-A5 pour gérer le traitement sécurisé. En fait, le cœur TrustZone Cortex-A5 avait été inclus dans des produits AMD antérieurs, mais n’a pas été activé en raison de contraintes de temps.

Samsung Knox utilise TrustZone à des fins telles que la détection des modifications du noyau.

TrustZone pour ARMv8-M (pour le profil Cortex-M)Edit

L’extension de sécurité, commercialisée sous le nom de TrustZone pour la technologie ARMv8-M, a été introduite dans l’architecture ARMv8-M. Bien qu’elle contienne des concepts similaires à TrustZone pour ARMv8-A, elle a une conception architecturale différente, car le changement de monde est effectué à l’aide d’instructions de branchement au lieu d’utiliser des exceptions. Il prend également en charge le traitement des interruptions entrelacées sécurisées à partir de l’un ou l’autre monde, quel que soit l’état de sécurité actuel. Ensemble, ces caractéristiques permettent des appels à faible latence vers le monde sécurisé et une gestion réactive des interruptions. ARM fournit une pile de référence de code de monde sécurisé sous la forme de Trusted Firmware pour M et PSA Certified.

Protection de page sans exécutionModification

A partir d’ARMv6, l’architecture ARM prend en charge la protection de page sans exécution, qui est appelée XN, pour eXecute Never.

La grande extension d’adresse physique (LPAE)

La grande extension d’adresse physique (LPAE), qui étend la taille de l’adresse physique de 32 bits à 40 bits, a été ajoutée à l’architecture ARMv7-A en 2011. La taille de l’adresse physique est plus grande, 44 bits, dans les Cortex-A75 et Cortex-A65AE.

ArMv8-R et ARMv8-MEdit

Les architectures ARMv8-R et ARMv8-M, annoncées après l’architecture ARMv8-A, partagent certaines fonctionnalités avec l’ARMv8-A, mais n’incluent aucune instruction AArch64 64 bits.

Armv8.1-MEdit

L’architecture ARMv8.1-M, annoncée en février 2019, est une amélioration de l’architecture ARMv8-M. Elle apporte de nouvelles fonctionnalités, notamment :

  • Une nouvelle extension du jeu d’instructions vectorielles. L’extension vectorielle M-Profile (MVE), ou Helium, est destinée aux applications de traitement du signal et d’apprentissage automatique.
  • Des améliorations supplémentaires du jeu d’instructions pour les boucles et les branches (Low Overhead Branch Extension).
  • Des instructions pour le support de la virgule flottante en demi-précision.
  • Une amélioration du jeu d’instructions pour la gestion de TrustZone pour l’unité à virgule flottante (FPU).
  • Nouvel attribut de mémoire dans l’unité de protection de la mémoire (MPU).
  • Améliorations du débogage, y compris l’unité de surveillance des performances (PMU), l’extension de débogage non privilégié, et un support de débogage supplémentaire axé sur les développements d’applications de traitement du signal.
  • Extension de la fiabilité, de la disponibilité et de la facilité de service (RAS).

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *