32 Vs 64 Bits : Explications

La réelle valeur ajoutée du K8 réside dans l'introduction de la technologie 64 bits, appelée x86-64 ou encore AMD64, et nous allons donc y consacrer le chapitre le plus important de cet article.

L'AMD64 propose de réitérer le pas franchi avec le 386 : changer l'architecture x86. Le défi est de taille, et il faut mesurer le temps qui a été nécessaire pour que le 32 bits se généralise, et ce plus de 10 ans après l'avénement du 386 !

Si les PC actuels sont cinquante à cent fois plus rapides que les 386, cela n'est du qu'à l'évolution de l'architecture des processeurs, car c'est bel et bien le même code 32 bits destiné aux 386 qui tourne encore aujourd'hui. Le K8 promet également une accélération du traitement des données par rapport à la génération précédente, non pas par la voie matérielle comme c'était le cas jusqu'ici, mais par la voie logicielle. Une alternative à la course technologique qui rend les architectures des processeurs de plus en plus complexe, mais une alternative plus risquée de la part du constructeur. La sauce ne peut prendre que si les logiciels suivent, à commencer par les systèmes d'exploitation. En bref, nous parlons ici d'un nouveau pas pour l'architecture x86, qui ne se traduit pour une fois pas par une inflation du nombre de transistors.

L'AMD64 soulève un certain nombre de questions, la principale étant : que peut apporter une technologie 64 bits, et en a-t-on réellement déjà besoin ? Après avoir présenté en quoi consiste l'AMD64, c'est la question à laquelle nous allons nous efforcer de répondre dans cette partie.

1) Le rôle des GPR

L'appartenance d'un processeur à une technologie 16, 32 ou 64 bits réside dans la taille de ses registres généraux, appelés également GPR pour General Purpose Registers. Les GPR sont les registres de travail du processeur : ils sont les opérandes du jeu d'instruction x86. Les GPR sont, en outre, les seuls registres qui permettent d'adresser la mémoire. Ceci a pour conséquence que la capacité de mémoire adressable dépend directement de la taille des GPR.

Premier représentant de la famille x86, le 8086 possèdait huit GPR de 16 bits : ax, bx, cx, dx, si, di, bp, sp. Or, des registre de 16 bits permettent de former des adresses mémoire comprises entre 0 et 65535, ce qui nous donne 64Ko de mémoire adressable. Ce qui est peu concevable, même pour un processeur aussi ancien que le 8086. L'astuce consiste donc à étendre l'espace d'adressage en gérant la mémoire sous forme de blocs, chacun possédant une taille de 64Ko. Ce système présente un manque de souplesse certain. Ceux qui ont programmé en mode réel MS-DOS se souviendront certainement de l'impossibilité de créer des tableaux d'une taille supérieure à cette barrière de 64Ko.

Le 386 a permis de s'affranchir de cette limitation. Il a étendu la taille des GPR à 32 bits,ce qui en fait le premier processeur IA32 (Intel Architecture 32 bits). Des GPR de 32 bits permettent d'adresser directement jusqu'à 4Go de mémoire.
Afin de ne pas rompre avec la sacro-sainte compatibilité x86, les GPR du 386 gardaient la possibilité d'être utilisés sous la forme de registres 16 bits. Cette trouvaille a permis au 386 de rester compatible avec les applications 16 bits actuelles.
Utilisé sous des systèmes d'exploitation 16 bits (en particulier MS-DOS), le 386 se comportait comme un super processeur 16 bits. Afin de pouvoir utiliser les registres 32 bits, le 386 devait être basculé dans un mode d'exploitation spécifique, appelé mode protégé. Ce mode permettait la libre utilisation des huit registres 32 bits : eax, ebx, ecx, edx, esi, edi, ebp, esp.

2) Les limitations de l'IA32

Les processeurs x86 actuels sont toujours conformes aux spécifications IA32, et cette technologie commence à montrer ses limites.

La première limite, que nous appelerons limite horizontale, concerne la taille des registres proprement dite, et plus précisément la taille de mémoire adressable avec des GPR de 32 bits. Comme nous l'avons vu, des GPR 32 bits permettent d'adresser 4Go, ce qui semble encore aujourd'hui largement suffisant pour une utilisation courante, mais risque de rapidement représenter une limite. 1Go de mémoire vive sont dès maintenant une capacité courante, et la limitation à 4Go risque d'être assez vite atteinte. Cette limite est d'ailleurs déjà atteinte sur les serveurs, où 4Go de mémoire représentent déjà une limitation.
Dans la pratique, cette limitation à 4Go a été repoussée en utilisant le même principe que sur le 8086, à savoir la gestion de la mémoire sous forme de blocs, cette fois-ci de 4Go. Avec des adresses mémoire encodées sur 36 bits au lieu de 32, les processeurs actuels peuvent ainsi adresser 64Go de mémoire vive. Mais cette gestion par blocs reste un système peu pratique, tant au niveau performance que souplesse d'utilisation.

La deuxième limite de l'IA32 concerne le nombre de GPR, et nous la nommerons limite verticale. S'il est une caractéristique qui n'a pas évolué depuis l'émergence du x86, c'est bien le nombre de GPR. En comparaison, les processeurs non x86 se voient lottis de plusieurs dizaines de GPR (128 sur un Itanium), à comparer aux huit que possède tout processeur x86.
Certes, depuis le 386, certaines améliorations ont été apportées, et à côté des GPR existent d'autres registres destinés à travailler sur des jeux d'instructions spécifiques : huit registres de 80 bits utilisés par les jeux d'instruction x87, MMX et 3DNow!, et huit registres 128 bits utilisés par les jeux d'instructions SSE, SSE2 et SSE3. Ces registres ne sont cependant pas des GPR mais uniquement des registres de calcul.

Le faible nombre de GPR a une incidence directe sur l'efficacité du code x86. En réalité, la limitation ne vient pas du processeur lui-même, mais des compilateurs. Les processeurs x86 possèdent, et depuis plusieurs générations déjà, beaucoup plus de huit GPR en interne. Cette technique s'appelle le "register renaming", et permet au processeur d'utiliser plusieurs exemplaires d'un même GPR. Cela dit, aussi efficace soit-il, un processeur n'exécute que le code qui lui est fournit par le compilateur, et ce dernier est par contre fortement limité par le faible nombre de registres. Il faut réaliser que si les processeurs ont évolué, il en a été de même des applications ; celles-ci sont toujours plus grosses, plus complexes, et n'ont pas grand chose à voir avec les premiers programmes qui tournaient sur le 8086. Les compilateurs ont ainsi vu leur tâche se complexifier, mais les outils dont ils disposaient sont restés les mêmes, à savoir huit registres de travail. La conséquence de cette complexification des programmes est que le compilateur doit opérer des trésors d'astuce pour utiliser 8 registres là où il lui en faudrait 128 ! Un grand nombre d'instructions sert donc à libérer les registres (en sauvant leur contenu sur la pile ou en mémoire) afin de pouvoir les utiliser pour les nouvelles instructions, ce qui bien entendu ralentit fortement le code.

Comment pallier à cela ? La voie la plus commune consiste à compenser cette perte d'efficacité du code par une amélioration dans l'architecture du processeur. Ainsi, le Pentium M par exemple possède une gestion optimisée des instructions opérant sur la pile, qui sont très utilisées pour libérer un GPR. Mais la vraie solution est beaucoup plus simple : plus de GPR ! Mais plus de GPR signifie rupture avec l'architecture IA32, et donc définition d'une nouvelle architecture, tout comme cela s'est passé avec le mode protégé 32 bits du 386.

Intel et AMD se sont bien entendu engoufrés dans cette brèche. Si la solution d'Intel reste à ce jour encore méconnue, celle d'AMD existe depuis plusieurs mois déjà : l'AMD64.

Suite ( Technologie AMD64 en détail )