Le processeur Cisc : une puce complexe

L’accroissement des performances d’une machine est mesuré par la diminution du temps nécessaire pour faire tourner un programme. Ce temps est égal au nombre d’instructions par programme multiplié par le nombre d’instructions par cycle, que multiplie le nombre de cycles par seconde. Sur les machines dites Cisc, les ingénieurs se sont dit qu’il s’agissait en fait de réduire le nombre d’instructions par programme (en augmentant le nombre de fonctions complexes précâblées dans la puce) pour réduire le temps de réalisation de la tâche.

Cisc : des instructions toujours plus nombreuses

Par conséquent, les premiers programmes fonctionnant sur Cisc étaient optimisés pour profiter de ces caractéristiques. Le nombre de lignes à exécuter étant plus faible, on libère de la mémoire, mais on accélère aussi le calcul. Pour ce faire, on utilise à l’intérieur du processeur un module microprogrammé. Le module indique au processeur ce qu’il doit faire et comment. Celui-ci effectue ses traitements en mémoire, c’est-à-dire qu’il réalise de très nombreux accès en mémoire pour aller y chercher les données à traiter. Avec le temps, ce module s’est complexifié. Le nombre d’instructions a augmenté et, dans des proportions équivalentes, le nombre de bogues.

Reste qu’à la fin des années 70, les technologies ayant évolué, la crise logicielle prévue dans les années 50-60 ne s’est jamais produite. Mais l’ère de la VLSI (l’intégration à très grande échelle dans les processeurs) bat son plein : on est en train de passer à une finesse dans la gravure des processeurs qui promet des niveaux d’intégration très importants. Le monde de l’infiniment petit est en train de s’ouvrir aux ingénieurs. En revanche, l’implémentation de l’architecture des puces nécessite une répartition sur plusieurs unités de traitement. Normal, le nombre de transistors disponibles sur une puce est limité pour le moment.

Risc : moins d’instructions mais plus optimisées

Emerge alors l’idée qu’il faut optimiser le processeur. On entrevoit en effet que l’intégration va permettre de disposer de plus de puissance. Mais pourquoi ne pas chercher à en optimiser les effets ? On ne veut plus en effet qu’un seul processeur, qu’on chercherait à accélérer. Il faut lui laisser faire uniquement ce qu’il sait faire le mieux, pour qu’il aille le plus vite possible. Cette « philosophie » devient vite un leitmotiv : rendre le cas le plus commun le plus rapide. Les calculs les plus simples effectués par le processeur doivent l’être le plus rapidement possible.

Cette approche est radicalement différente de l’approche précédente qui était de « transférer au processeur la complexité ». Ici, il s’agit d’ôter du processeur la complexité pour en faire une bête de course et de renvoyer les fonctions complexes vers le logiciel. Cette approche de la fabrication des processeurs est devenue possible pour trois raisons : la mémoire coûte beaucoup moins cher, les compilateurs sont beaucoup plus élaborés et les universitaires de Berkeley et de Stanford, ainsi que les ingénieurs d’IBM, se sont aperçus que les programmeurs n’utilisaient pas, ou très peu, les fonctions complexes. Pourquoi donc garder ces fonctions et complexifier encore et encore les jeux d’instructions ? Il vaut bien mieux réduire ces jeux, les simplifier, les utiliser par groupes et profiter de la vitesse acquise ainsi pour faire résoudre au logiciel les fonctions complexes. C’est l’idée qui préside à la naissance de l’architecture Risc, pour calculateur à jeu d’instructions réduit.

Demain, nous définirons l’architecture Risc et plongerons dans les différences de conception.

Pour en savoir plus :

Le site de ressources sur l’architecture x86 (en anglais)