05

Quelques détails sur la nouvelle architecture Aarch64!

déc

ARM vient juste de rendre public une première documentation concernant l’architecture Aarch64 – la version 64 bit de l’ARM.
Depuis plus de 20 ans, l’architecture 32bit à évolué en conservant une compatibilité ascendante avec les toutes premières version de l’ARM.
ARM a profité de cette nouvelle architecture, pour repartir à “zero” (enfin c’est un bien grand mot) en nous proposant un nouveau jeu d’instructions. Et comme c’est souvent le cas avec les petits génies d’ARM, c’est plutôt bien pensé !

Les registres

L’architectures Aarch64 propose 32 registres généraux qui sont accessibles en version 32 ou 64bits.
Les registres 32bits sont nommés Wn (avec n vallant de 0 à 31)
Les registres 64bits sont nommés Xn (avec n vallant de 0 à 31)
L’utilisation de w31/x31 est interdite (je vais y revenir)

L’utilisation de ces registres à grandement changé.

PC (program counter, r15 dans l’architecture Aarch32) ne fait plus partie des registres généraux. Il n’est donc plus possible de le modifier aussi facilement qu’auparavant. Ce n’est pas bien grave en fait car il reste possible de faire un MOV vers le PC ce qui est largement suffisant. De plus on dispose du coup d’un registre général supplémentaire.

SP (stack pointer, r13 dans l’architecture Aarch32) est représenté par x31. Pour autant ce registre est un peu particulier, car selon les instructions qui l’utilise, sa valeur peut changer.

LR (link return, r14 dans l’architecture Aarch32), lui par contre existe toujours et devient x30.

x31 est soit SP soit 0 !

w31/x31 a une utilisation un peu particulière.
Ce registre peut, selon les cas, représenter SP ou bien valoir 0.

Dans certain cas x31 est considéré comme le registre de pile :

  • Lors d’un accès mémoire utilisant x31 comme adresse, alors x31 est équivalent à SP.
  • Dans le cas d’une instruction n’allumant pas les flags, x31 sera aussi équivalent à SP.
  • Dans le cas d’une instruction allumant les flags, x31 ne sera considéré comme équivalent à SP que s’il est utilisé comme premier registre source de l’opération.

Dans tous les cas ou x31 n’est pas considéré comme équivalent à SP, sa valeur est 0.

  • Il pourra par exemple être utilisé si vous voulez allumer les bits de flags sans vous intéresser au résultat de l’opération. Vous utiliserez dans ce cas ce registre comme registre de destination. Il ne sera pas modifié de tout façon.
  • Il peut aussi être utiliser comme source d’une opération si vous avez besoin d’un registre dont le valeur est 0. Dans ce cas vous devrez l’utiliser comme deuxième registre source.

Comme il est assez complexe (au moins au debut) de savoir dans quel contexte x31 est vu comme SP ou comme 0, l’assembleur n’autorisera pas l’utilisation du registre w31/x31.
Vous devrez utiliser wSP/SP ou bien wZR/xZR.
L’assembleur se chargera pour vous de contrôler que vous utilisez bien w31/x31 dans le bon contexte.

Modification du PC

La modification du PC (program counter) ne peut à présent se faire qu’au travers d’instruction de branchement

  • B label @ Saut vers l’adresse relative
  • BL label @ Saut vers l’adresse relative avec enregistrement du PC dans x30
  • BR Xn: Saut vers l’adresse contenu dans le registre Xn
  • BLR: Saut vers l’adresse contenu dans le registre Xn avec enregistrement du PC dans x30
  • RET: Retour de procédure équivalent à l’ancien MOV pc, lr
  • RET Xn: Retour de procédure vers l’adresse Xn. Pour le moment j’ai pas bien compris la différence entre RET Xn et BR Xn !!!!

Les instructions de l’architecture Aarch64

Les instructions de l’architecture 64bit de l’ARM sont toujours encodée sur 32bits, par contre, leur encodage n’est plus du tout compatible avec les instructions 32 bits de l’ancienne architecture.
Le passage à 32 registres a nécessité libération de place dans les instructions (un registre étant à présent représenté sur 5 bits contre 4 précédemment).

Les instructions conditionnelles

Fini les instructions conditionnelles.
ARM considère à juste titre que les progrès dans la prédiction de branchement rendent les instructions conditionnelles obsolètes. Elles sont donc retirées.

Pour autant, le bit S indiquant qu’on souhaite ou non allumer les flags reste présent. (la plupart des processeurs n’ont pas cette possibilité. Sur les processeur Intel par exemple, toutes les instructions allument les flags).
Les branchements peuvent toujours être conditionnels (ca vaut mieux ;) )

Par contre ARM n’en a pas profité pour gérer des registres de flags comme c’est le cas sur certains autres processeurs. C’est dommage, c’eut été bien utile.

ARM a aussi ajouté de nouvelles instructions qui, à défaut d’être conditionnelles vont pouvoir exécuter des opérations différentes en fonction des flags.
On retrouve là l’héritage de l’architecture ARM, et autant le dire, ces nouvelles instructions sont extrêmement bien pensées (même si les compilateurs auront un peu de mal à les exploiter).

L’idée est de réaliser l’équivalent de

if (cond)
	action 1;
else
	action 2;

en une seule instruction.

Par exemple

	csel			w10, w11, w12, eq

est équivalent au code Aarch32

	moveq			r10, r11
	movne			r10, r12

Il existe un dizaine d’instructions de ce type.
On voit tout de suite les intérêts d’une telle instructions:

  • Pas de branchement
  • L’instruction peut sans problème s’exécuter en parallèle d’une autre instructions.

Dans la foulée, l’architecture Aarch64 introduit une instruction de comparaison conditionnelles permettant de simplifier le calcul de conditions complexes (mais qui ne sera pas aussi puissant que la gestion de multiple registres de flags).
Il est dommage par contre qu’il n’existe pas une instruction qui décrémente un registre et effectue dans la foulée un branchement conditionnel !

Les valeurs immédiates

Pour rappel, sur l’architecture Aarch32, une valeur immédiate était codée sur 12 bits lesquels représentaient une valeur 8 bits décalée d’une valeur codée sur 4 bits doublée!
Genre :
140288 (0×00022400) = 137 (0×89) << 10

Sur l’architecture Aarch64, une valeur immédiate est codé sur 13 bits lesquels représente une valeur 12bits éventuellement décalée de 12 bits.
Il n’est donc plus possible de faire un

	add			w0, w1, 0X01000000

puisque la valeur ne peut être représenté ni par une valeur 12 bits, ni par une valeur 12 bits décalée de 12 bits.
Il faudra donc se tourner vers les instructions MOVW et MOVT qui accepte toujours une valeur 16 bits comme valeur immédiate et charger un registre avant de pouvoir réaliser le ADD.
Bon! Dont acte. Il est trop tôt pour savoir si c’est un choix judicieux ou non.

Décalage de bits du deuxième registre source

Ouf! J’ai un moment cru que cette particularité bien utile des processeurs ARM avait disparue mais non !

Rem: Enfin bien utile, tant que ce type d’instruction ne prend pas trop de temps CPU ! Pour info sur un Cortex A9, les instructions usant de ce procédé prennent un cycle de plus que sur le Cortex A8 !!!

Les décalages de bits du deuxième registre source sont toujours d’actualité en fonctionnent à peu de chose prêt comme actuellement. J’ai juste l’impression que les décalages de type RRX (que je n’ai d’ailleurs jamais eu à utiliser ont disparus).

Les accès mémoires

Bon j’ai pas encore tout lus et tout compris, mais déjà on peut dire que les lectures multiple et écritures multiple ont disparues.
Plus de LDM et STM donc!
Ces instructions étaient de toute façon devenu de moins en moins efficaces. Plus exactement, elles étaient guère plus rapide qu’une série de LDR ou STR.

Tous les modes d’adressage sont (au minimum) identiques à ceux de l’architecture Aarch32.

  • ldr x0, [x1, #imm]
  • ldr x0, [x1, #imm]!
  • ldr x0, [x1], #imm
  • ldr x0, [x1, x2]
  • ldr x0, [x1, x2, lsl#4]
  • ldr x0, [x1, w2, uxtw#4]

On notera la possibilité nouvelle d’utiliser un registre 32bits en tant qu’offset.
Dans ce cas le registre est étendu sur 64 bit puis éventuellement décalé (cette interprétation de uxtw#4 reste à confirmer).

Les instructions

Sans entrer dans le détails, la plupart des instructions existant dans l’architecture Aarch32 sont encore présente dans l’architecture Aarch64.
Les instructions de calculs parallèles (genre SHADD8 ou QADD16) ont disparues, ou plus précisément elle ont été transférées vers NEON, ce qui est assez logique vu que NEON est totalement fait pour réaliser ce genre d’instructions.
De nouvelles instructions sont par contre arrivées:

  • Les nouvelles instructions “conditionnelles” dont j’ai parlé précédemment.
  • La division 32 (et 64) bits
  • Les instructions STP et LDP qui écrivent et lisent 2 registres (32 ou 64 bits) permettant de palier en partie à la disparition des instructions STM et LDM

En gros, un développeur Aarch32 devrait pouvoir passer sur Aarch64 sans trop être perdu !!!

NEON

Bon pour NEON, j’avoue que c’est plus compliqué.
L’architecture Aarch64 introduit une nouvelle notation aussi bien des instructions que des registres.

On peut déjà dire que:

  • Le nombre de registre 128 bit (Qn) double passant à 32 au lieu de 16 !
  • Les registres 64 bits (Dn) sont eux toujours au nombre de 32. Ils ne sont plus agencée (mappés) de la même façon. A présent les registres 64bits représentent la partie basse des registres 128 bits. Sur l’ancienne architecture, un registre Qn regroupait deux registre Dn consécutif.

Pour le reste, je vais avoir besoin d’un peu de temps pour y voir un peu plus clair car leur nouvelle syntaxe n’est pas limpide!

conclusion

Bon voilà ce que en gros on peut dire pour le moment de la nouvelle architecture 64 bits de ARM.
Ca m’a l’air assez bien pensé dans les évolutions qu’elle apporte (plus de registres, retrait des fonctionnalités devenues inutiles).
Bon évidement ce post a juste pour but de débroussailler un peu le terrain. Tout reste à découvrir et tester. Je ne suis même pas trop sur de ne pas mettre trompé sur ce que j’ai cru comprendre.

Nouvelle Architecture ne veut pas dire abandon de la précédente d’ailleurs.
A mon avis l’architecture Aarch32 a encore quelques années devant elle, même si évidement, Aarch64 annonce sa fin prochaine.

Pour en savoir plus, vous pouvez télécharger le documentation officielle ARMv8 Instruction Set Overview, pour peu bien sur que vous ayez un accès au site ARM.

Reste plus qu’à se trouver une carte de développement avec un proc 64bit ARM pluggé dessus. A mon avis c’est pas pour tout de suite !!!

3 Responses to “Quelques détails sur la nouvelle architecture Aarch64!”

  1. [...] architecture (qui reste quand même dans la continuité de l’existant) en présentant l’Aarch64 qui pourrait d’ici quelques années (enfin une bonne dizaine quand même) prendre [...]

  2. 0xFF dit :

    Pas mal, les instructions if-else sont super importantes pour mes effets audio !!

  3. Eric dit :

    Le jeu d’instruction armv8, ne semble pas transcendant. Ca se rapproche en fait du powerpc qu’on trouve dans la xbox360 et la wiiU (en mieux quand meme!). Les registres 64 bits sont tout meme assez inutilisé en regle générale, j’espère qu’arm en a profité pour racourcir la longueur du pipeline!

Répondre

Human control : 9 + 2 =