Au théâtre ce soir...

C'est vrai que le processeur i4 que nous allons disséquer ici ne ressemble à rien de connu. Tout juste pourrait-on le cousiner à un Z80, processeur antédiluvien apparenté au vieil Intel 8080.
De toute façon, ce vague pedigree n'a que peu d'importance, l'essentiel étant que notre processeur i4 rassemble à peu près tous les composants fondamentaux dont dispose la plupart des puces informatiques.
Bref ! Un bien beau sujet d'étude in vivo...

i4: A star is born

Avant tout premier pas, rappelons une fois encore ceci: tout programme informatique, quelle que soit sa complexité, est constitué d'une longue séquence d'instructions-machine élémentaires attendant paisiblement en mémoire le moment d'être appelées dans le processeur afin d'y être exécutées.
 

De nos jours, grâce à des technologies hautement avancées, les processeurs les plus récents parviennent à exécuter simultanément plusieurs de ces instructions, démultipliant d'un coup une puissance de calcul déjà formidable.
Les puces plus "primitives", à l'image de notre bonne vieille i4, obéissaient à des méthodes de travail un peu plus... "artisanales". Enfin... moins... "industrielles"...
 

Même si les processeurs de type SISD font désormais sourire les plus jeunes, notre puce i4 n'en est pas pour autant un "sous-processeur". Et même si sa cadence de travail n'est pas des plus fulgurantes, cette relative indolence va nous permettre de bien comprendre l'ensemble des événements se déroulant au coeur d'un processeur, microseconde après microseconde, au cours de son travail répétitif.

Présentation de l'oeuvre

Comme nous l'avons déjà dit, tout processeur se contente d'exécuter une séquence d'instructions dont l'ensemble constitue le logiciel en cours d'utilisation. Ces micro-instructions, avant d'être ainsi froidement exécutées, patientent sagement dans la mémoire de l'ordinateur, codées au format binaire.

Ainsi, dans le cas qui nous intéresse, notre processeur i4 est sur le point d'exécuter la séquence suivante placée en mémoire:
 

C'est sûr que vu comme ça, on distingue mal l'intérêt de ce bout de programme...
En tout cas, nous en savons assez pour passer un bon moment devant notre écran.
Vous êtes bien assis ? Vous avez fait pipi ? Bon !
Attention... les trois coups du brigadier. Silence... Rideau !
La scène s'ouvre sur une puce.

"What's New Puce i4 ?" (huis-clos en 2 actes)

ACTE I. LDA

Scène I. Prise d'ordre (M1)

i4 débute l'exécution de notre séquence sibylline...
Afin de connaître l'adresse en mémoire de la prochaine instruction à exécuter, elle s'adresse au compteur ordinal qui, en guise de réponse, délivre son contenu (F100) sur le tampon d'adresse.
Une fois dans le tampon d'adresse, la valeur parvient jusqu'au bus d'adresse, organe de communication du processeur, qui la véhicule jusqu'à la mémoire centrale de l'ordinateur. 
 

Le compteur ordinal délivre ici des valeurs hexadécimales, mais dans l'unique but de davantage de clarté. Electroniquement parlant, ces valeurs sont bel et bien des valeurs binaires, valeurs codées sur 16 bits dans le cas de i4.
Au fait, vous avez bien sûr compris que le bus d'adresses de i4 avait une largeur de 16 bits, taille évidemment identique à la taille du compteur ordinal.
 

La mémoire centrale reçoit l'adresse demandée et, docile, procède immédiatement à la recherche de la case mémoire correspondante. Une fois trouvée, le contenu de celle-ci (3A) est prestement renvoyé au processeur par l'intermédiaire du bus de donnée.
 

Comme vous l'aurez constaté, les données abritées dans la mémoire sont des octets. Le bus de donnée de i4 est donc un bus de huit bits, capable de véhiculer des valeurs binaires comprises entre 00000000 et 11111111, soit, en hexadécimal, entre 00 et FF.

Parvenue sur le bus, la donnée retourne benoîtement au processeur jusque dans le tampon de donnée.
Dans le même temps, le compteur ordinal est incrémenté d'une unité afin de pointer sur l'adresse suivante en mémoire (F101).
 

Le tampon de donnée convoie la valeur reçue jusque dans le registre d'instruction du décodeur. Celui-ci procède alors au décodage de l'instruction et, conformément au jeu d'instructions de i4, détermine que la valeur "3A" correspond à l'instruction machine "LDA"

C'est sûr que pour vous et moi, comme ça, a priori, "LDA" ne constitue pas une instruction monstrueusement explicite. Mais pour i4, le message est très clair; c'est l'ordre de charger l'accumulateur avec une valeur située à l'adresse précisée par les deux prochains octets lus en mémoire.
 

Bon...Petit effort supplémentaire de traduction: en décodant "LDA", notre puce comprend que les deux prochaines données qui seront lues en mémoire ne seront ni une nouvelle instruction ni des données "immédiatement utiles" mais constitueront en fait deux demi-adresses (8+8 = 16 bits) dont il faudra charger le contenu dans l'accumulateur.

Nous tenons d'ores-et-déjà à rassurer le lecteur vertiginé par l'aridité et la rébarbativité de ce flot de texte très aride; un joli schéma, tout en couleurs, tentera d'illustrer l'ensemble de ce chapitre très "mécanique" plus bas sur cette page.

Scène II. Repérage de la cible (M2)

Ainsi donc, le processeur a besoin du contenu des deux prochaines cellules mémoire afin de former une adresse. Qu'à cela ne tienne, le processus d'accès en mémoire se répète une première fois.

L'instruction décodée, c'est au séquenceur de prendre les choses en main en pilotant l'ensemble des événements à venir.
Ainsi, le séquenceur fait appel au compteur ordinal afin que celui-ci délivre sur le bus processeur, via le tampon d'adresse, l'adresse (F101) de la prochaine donnée à lire.
L'adresse est convoyée jusqu'à la mémoire centrale qui, toujours aussi docile, renvoie sur le bus processeur la donnée trouvée (7C) à l'adresse indiquée.
N'oublions pas notre compteur ordinal, qui, simultanément, s'incrémente d'une unité.
 

Contrairement à la scène précédente, la donnée stockée à cet instant dans le tampon n'est pas une instruction à décoder, mais une demi-adresse en cours de formation. Par conséquent, le séquenceur n'oriente pas ce "7C" vers le décodeur, mais le stocke au chaud dans un registre de travail.

Scène III. Le retour du Repérage de la cible (M3)

Notre première moitié d'adresse désormais à l'abri, le processus se répète à l'identique pour la seconde:

• Compteur ordinal sollicité (F102)
• Tampon d'adresse en transit
• Bus d'adresse aller
• Mémoire centrale en effervescence
• Bus de donnée retour (F3)
• Tampon de donnée en transit
• Deuxième registre de travail mis à contribution

Et pendant ce temps là, devinez quoi, notre compteur ordinal progresse d'une unité.

Scène IV. Exécution ! (M4)

Bien ! Maintenant que i4 dispose des deux demi-adresses dans ses petits registres, il est enfin possible de mettre en oeuvre notre instruction LDA.

Le séquenceur accède aux registres de travail (7C et F3) et réunit leur contenu sur le tampon d'adresse (F37C). Celui-ci délivre sa valeur vers le bus processeur, qui transmet la requête à la mémoire centrale.
 

Les esprits curieux auront noté que notre puce a formé l'adresse en commençant par l'octet de poids faible (7C puis F3 pour former F37C)
i4 doit manger ses oeufs à la coque par le petit bout...

En guise de réponse, le tampon de donnée réceptionne la valeur souhaitée (50) avant que, conformément à l'instruction "LDA", le séquenceur place celle-ci dans le registre accumulateur.
 

Petite respiration dans cet infernal ballet électronique...
Comme vous l'avez remarqué, notre instruction "LDA" ne s'est pas présentée seule à notre processeur. Elle était en effet accompagnée de deux données ("7C" puis "F3") qui précisaient l'adresse cible de l'instruction proprement dite.

En pratique, il est très fréquent qu'une instruction-machine soit ainsi suivie de un ou plusieurs paramètre(s) permettant son exécution. De fait, plutôt que de paramètres, on parle alors des opérandes de l'instruction.
 

Ceux qui ont d'ores-et-déjà compris sont priés de sauter l'effrayante métaphore qui va suivre...
Ayé ? C'est fait ?
Dernière sommation...
Si nous voulions illustrer le principe du couple {instruction-opérande} et si nous n'avions vraiment aucune peur du ridicule, nous pourrions faire le parallèle suivant:

Acte II. ADD

Ouf ! Et d'une !
Et maintenant ?
Maintenant, i4 est prête à exécuter une nouvelle instruction, c'est-à-dire embrayer sur un nouveau cycle M1. Après tout, Il y a fort à parier que l'accumulateur n'ait pas été chargé pour des nèfles !

Scène I. Une instruction (M1)

Derechef, i4 fait appel au compteur ordinal afin de savoir où elle en est dans l'exécution de son programme. Obéissant, celui-ci délivre son contenu (F103) au tampon d'adresse, avec pour conséquence immédiate l'envoi d'une nouvelle requête en mémoire centrale. La mémoire recherche l'adresse indiquée et délivre le contenu de celle-ci (B1) vers le tampon de donnée, via le bus processeur.
 

L'exécution de la précédente instruction étant terminée, le séquenceur sait que la donnée entrante est une nouvelle instruction à décoder. Celle-ci est donc convoyée jusqu'au registre d'instruction, où le décodeur entre en jeu et reconnaît l'instruction-machine "ADD", ordre d'addition entre la valeur contenue dans l'accumulateur et un opérande à venir.

Scène II. Un opérande (M2)

Prochaine mission, donc: recherche de l'opérande en mémoire. Hop ! Compteur ordinal (F104), tampon d'adresse, bus d'adresse, mémoire. La donnée trouvée (B6) est ramenée à i4. Hop ! Hop ! Bus de donnée, tampon du même nom, registre de travail...
Et au pas de course !

Scène III. Scénario catastrophe (M3)

Bon ! Foin de va-et-vients électroniques ! Notre i4 serait-elle limitée à balader des électrons d'un coin à l'autre de la machine ? Non, M'sieurs Dames ! Il est tant désormais pour i4 de nous montrer qu'elle est un processeur, un vrai !
 

Cette fois-ci, c'est un calcul que l'on réclame à notre puce. Le séquenceur achemine donc le contenu de l'accumulateur (50) et la donnée nouvellement importée (B6) jusqu'à l'Unité Arithmétique et Logique (UAL) qui se charge du calcul mathématique proprement dit.
  

Le fait est que l'opération est ici assez sommaire puisqu'il s'agit d'une bête addition entre deux valeurs entières. Si le calcul avait été plus audacieux (un calcul de sinus, par exemple) ou s'il avait mis en jeu des nombres relatifs, l'UAL aurait délégué cette tâche à une unité dédiée spécialement aux manipulations de virgule: le coprocesseur arithmétique.
 

Le fait est qu'après chaque exécution d'une instruction, le séquenceur consulte ce registre d'état afin de voir si une "alerte" particulière s'est produite au cours du cycle d'instruction en cours.
Dans ce cas, une procédure adaptée est généralement prévue, que ce soit par le programme en cours d'exécution ou au niveau du système d'exploitation.

Et voilà, le rideau se referme sur ce coup de théâtre époustouflant et truculent !
Et maintenant, comme promis et à la demande quasi générale des six lecteurs de cette page... le zoli schéma tout en couleurs !

Critique de l'oeuvre

Et voilà ! C'était court mais suffisamment répétitif pour pouvoir dire que nous en savons désormais assez sur i4 et sur sa manière de lire et exécuter un programme informatique.
Place maintenant à la critique constructive....

Se secouer la puce...

Rythme de la pièce

Nous venons de voir i4 procéder à l'exécution de deux instructions successives: LDA puis ADD. L'expérience, intense, nous permet d'ores-et-déjà les quelques très pertientes remarques suivantes:
 

• L'activité de i4 se traduit par une succession d'événements électroniques élémentaires tous circonscrits dans un espace de temps de même durée (T1, T2, T3...) que nous appellerons cycle machine
   
• La scrupuleuse cadence de ces cycles machines n'est pas issue du Saint-Esprit mais correspond en fait à la fréquence d'horloge de l'ordinateur, chaque "top" de celle-ci marquant le début d'un nouveau cycle machine
   

• Notre brave i4 étant une puce assez nonchalante, plusieurs cycles machine lui sont nécessaires afin d'exécuter une seule instruction, l'ensemble de ces cycles constituant un cycle d'instruction
   
• Un cycle d'instruction nécessite un nombre variable de cycles machine selon la nature de l'instruction à exécuter

Malgré ce nombre variable de cycles machine nécessaire à l'exécution d'une instruction, nous avons remarqué que dans tous les cas, deux phases successives se répétaient pour chaque cycle d'instruction:

• un cycle de recherche au cours duquel l'instruction puis le ou les éventuelle(s) l'opérande(s) sont recherchés en mémoire puis importés dans le processeur
   
• un cycle d'exécution mettant en jeu les unités de traitement proprement dites, l'accumulateur ou l'UAL dans notre exemple 

Il existe en fait un troisième cycle dont nous n'avons pipé mot histoire de ne pas "surcharger le baudet"; il s'agit du cycle d'interruption. Ce cycle, qui termine tout cycle d'instruction, est une phase au cours de laquelle le processeur vérifie qu'aucune demande d'interruption n'a été émise pendant l'exécution de l'instruction en cours.
Pour le moment, contentons-nous de considérer ces interruptions comme le moyen pour la machine de suspendre un temps l'exécution normale de son programme afin de s'atteler temporairement à une tâche jugée prioritaire.
 

De cette suite d'épatantes observations, nous pouvons maintenant dresser le scénario de nos deux cycles d'instruction étudiés:

Bien ! Maintenant que nous avons brossé le portrait type d'un cycle d'instruction, nous pouvons oser quelques pistes de recherche afin de dynamiser un peu cette pièce parfois un poil longuette.
Bref, comment se secouer un peu la puce...

Augmenter la cadence !

Malin (maligne) comme vous êtes, vous avez immédiatement percuté ! Si i4 calque si scrupuleusement son rythme de travail sur la fréquence d'horloge de l'ordinateur, ne suffirait-il pas d'augmenter la cadence de celle-ci pour doper d'autant les performances de notre chère puce ?
 

Et si, bien sûr ! Les dresseurs de puces (aussi appelés "fondeurs") parviennent à régulièrement augmenter les fréquences de fonctionnement de leurs créatures, mais cette méthode "brutale" est liée à des contraintes purement technologiques. En effet, il n'est pas tout d'accélérer la cadence de travail de la chaîne de production, encore faut-il que les ouvriers puissent suivre...

Ajouter un souffleur

Augmenter la seule fréquence de fonctionnement des processeurs ne constitue pas la solution miracle car nous nous doutons bien que certaines actions du processeur réclameront toujours un temps minimal et incompressible.
Il nous faut donc trouver d'autres moyens d'accroître la productivité de notre puce et, pour cela, s'intéresser à ses méthodes de travail, sa "mécanique interne", c'est-à-dire à son architecture.

Il y a un détail essentiel que ne montre pas notre schéma tout en couleurs, c'est que les cycles de recherche réclament à i4 énormément plus de temps que les cycles d'exécution.

Vous ne serez qu'à demi-surpris(e) à la lecture de cette phrase si vous avez déjà butiné les pages de ce site consacrées au bus processeur ou à la fréquence de fonctionnement des processeurs. Nous avions alors appris que le processeur travaillait "en interne" beaucoup plus vite que le reste de l'ordinateur grâce à un judicieux dispositif appelé multiplicateur d'horloge.
 

Ce hiatus de fréquence entre l'intérieur et l'extérieur de la puce implique qu'à chaque fois qu'il doit importer une donnée depuis la carte mère (mémoire ou périphérique), notre processeur, ultra-rapide, doit se résoudre à patienter avant d'être exaucé.

Ayant constaté combien fréquentes étaient les requêtes de i4 à destination de la mémoire centrale, nous devons donc nous résoudre à cette navrante conclusion: la principale tâche de i4 est bel et bien le coinçage de bulle en bonne et due forme !
 

Conscients d'avoir repéré à ce niveau un terrible "goulot d'étranglement" susceptible de considérablement ralentir l'activité de leurs créatures, les ingénieurs informaticiens cherchèrent pas tous les moyens à réduire au strict minimum les requêtes du processeur à la mémoire centrale.

Et sur ce point, ils se surpassèrent...

Veuillez patienter, le processeur va vous recevoir...

La méthode la plus primitive afin de réduire l'expectative du processeur lors des accès en mémoire porte un nom très parlant: la file d'attente.

A la base de cette trouvaille, la simple constatation que lors de la phase d'exécution de l'instruction en cours, il serait tout-à-fait possible de rechercher l'instruction suivante en mémoire afin que celle-ci soit déjà dans le processeur lorsqu'elle sera réclamée.
Cette solution, désarmante d'évidence, impliquait la mise en place d'une "salle d'attente" à l'extrémité du bus de donnée, salle d'attente susceptible d'accueillir quelques données ainsi préchargées par anticipation depuis la mémoire.
 

La file d'attente fut adoptée par Monsieur Intel dès l'avènement de son processeur 8086. Elle était alors dotée d'un espace de stockage de six octets, contre quatre octets pour sa version "light" baptisée 8088.

Mémoire ancienne, mémoire récente

La file d'attente était évidente et simple à mettre en place mais d'un intérêt relativement limité quand on sait qu'un programme informatique est généralement constitué de nombreux branchements et, plus fréquentes encore, de boucles d'exécutions itératives. Or, même dans ces situations très communes, l'accès à la mémoire, même anticipé, restait de mise et continuait de grever le pétulant potentiel de nos processeurs.
 

Bien sûr, il aurait été possible de munir les processeurs de mémoires beaucoup plus rapides, mais celles-ci, beaucoup plus chères, auraient définitivement placé les ordinateurs hors de portée du grand public.
En revanche, il s'avérait possible d'utiliser ces mémoires ultra-rapides, mais en quantité très limitée, afin de considérablement "fluidifier" le fonctionnement des processeurs. L'ingénieux dispositif fut baptisée mémoire cache.
 

A la base du procédé, une simple observation. De par la structure générale des programmes informatiques, il s'avère extrêmement fréquent qu'une donnée manipulée par le processeur (instruction ou opérande) soit réutilisée par celui-ci dans un avenir proche. Par ailleurs, si une donnée est réclamée quelque part en mémoire, il s'avère également très probable que les octets voisins soient à leur tour requis à très brève échéance.
On appelle localité temporelles et spatiale cette caractéristique structurelle de la mémoire de l'ordinateur, caractéristique fort intéressante...
 

En clair, lorsque le processeur réclame une donnée, celle-ci est très normalement importée depuis la mémoire centrale, comme d'habitude, mais accompagnée cette fois de ses quelques octets immédiatement voisins. La donnée ciblée est bien évidemment délivrée au processeur, mais le tout est simultanément copié dans la mémoire cache de la puce.
Dès lors, à chaque fois que le processeur réclame une donnée en mémoire, il commence par consulter la mémoire cache afin de voir si celle-ci s'y trouve déjà. Conformément au principe de localité que nous venons de voir, cette consultation a de grandes probabilités d'être fructueuse. Dans ce cas, le processeur se sert et évite donc un très pénalisant accès en mémoire centrale.
Si, comme cela peut néanmoins arriver, la donnée tant désirée ne se trouve pas dans le cache, un accès normal en mémoire centrale est effectué, et les données rapatriées bien évidemment copiées dans le cache.
Ingénieux, non ?

Des bits ! Plus de bits !

Souvenons-nous de notre instruction LDA qui, péniblement, dût rassembler deux demi-adresses afin de former l'adresse définitive où aller chercher l'information pertinente. Souvenons-nous aussi de notre dénouement catastrophe où tout a bloqué pour une addition un peu trop osée...
Ah, si le bus de données avait été deux fois plus large ! Si l'accumulateur avait été plus grand ! Que de temps gagné !
 

Les ingénieurs, eux aussi, ont souvent regretté ce manque chronique de bits. Il n'est donc pas étonnant de constater une augmentation croissante de la taille des bus et des registres au gré des générations successives de processeurs.

Ainsi, le vénérable 8088, déjà rencontré plus haut, disposait d'un bus de donnée de huit pauvres bits, alors que le dernier-né de chez Intel, l'effrayant Itanium, arbore un bus de données huit fois plus important.
 

On vous venir de loin, vous, là, l'air faussement niais... Pourquoi ne pas allonger indéfiniment la largeur de tous ces bus et registres afin de gagner en rapidité d'action nous dites-vous ?
Pour une raison bêtement technologique, car pour qu'un bus fonctionne parfaitement, il faut que toutes ses lignes soient très exactement synchronisées entre elles et avec leur environnement. Or, cette synchronisation devient de plus en plus complexe au fur et à mesure qu'augmentent la taille du bus et sa fréquence de fonctionnement.

Trop de bits tue le débit...

Et du pipeline, la lumière fût !

En réalité, la dernière très grande révolution dans le domaine de l'architecture matérielle des processeurs tient dans un mot à la fois sombre et creux: le pipeline d'exécution.
Le concept du pipeline est pourtant désarmant de simplicité puisqu'il vise simplement à adapter les principes du travail à la chaine au processus de fonctionnement de nos puces domestiques.

Juste pour faire saliver, avançons d'ores-et-déjà qu'à fréquence égale, les performances d'un processeur pipeliné" se trouvent démultipliées d'un coup par rapport à une puce "artisanale" telle i4.
La révolution industrielle, quoi !

Bon... Maintenant nous pouvons vous le dire... Tout ce que vous venez d'apprendre sur la manière de fonctionner d'un processeur est complètement dépassé. Mais alors, complètement !
Voilà, voilà...

Mais, mais, mais... Ne nous fâchons pas, Michalons ! Car la lecture de cette page, même effroyablement dépassée, fut une étape essentielle afin de mieux approcher les processeurs actuels, de mieux comprendre leurs foisonnantes innovations, de mieux appréhender les pistes de recherche pour les rendre demain encore plus forts et beaux.

Vous allez voir, vous nous remercierez un jour...
...si vous acceptez déjà de nous suivre dans le tunnel...

 Pipeline d'exécution