Combien de cycles d'horloge une instruction RISC / CISC prend-elle pour s'exécuter?

Selon la conception numérique et l'architecture informatique de Harris et Harris, il existe plusieurs façons d'implémenter un processeur MIPS, notamment les suivantes:

La microarchitecture à cycle unique exécute une instruction entière en un cycle. (...)

La microarchitecture multicycle exécute les instructions dans une série de cycles plus courts. (...)

La microarchitecture en pipeline applique le pipeline à la microarchitecture à cycle unique.

Les architectures sont souvent classées RISC ou CISC. Du RISC au CISC :

Les processeurs RISC n'utilisent que des instructions simples qui peuvent être exécutées dans un cycle d'horloge.

Puisque MIPS est une architecture RISC, je suis un peu confus par les définitions ci-dessus et je me demande s'il n'y a pas de contradiction entre elles. Plus précisement:

1. Si une instruction RISC peut être divisée en cycles plus courts (Fetch, Decode, ...), comment peut-on dire qu'il ne faut qu'un cycle d'horloge pour exécuter toute l'instruction? Ne faut-il pas un cycle d'horloge pour exécuter chacune des étapes?
2. Faut-il vraiment un cycle d'horloge pour exécuter une instruction RISC? Que se passe-t-il, par exemple, si un échec de cache se produit et que le processeur doit attendre une DRAM lente? Cela ne devrait-il pas prolonger considérablement l'exécution de l'instruction?
3. Qu'est-ce qu'un cycle d'instruction exactement? Est-ce le temps qu'il faut pour qu'une instruction se termine (c.-à-d. Un / plusieurs cycles d'horloge)?
4. Combien de temps une instruction CISC prend-elle en cycles d'horloge / instruction?

Les définitions pratiques du RISC et du CISC sont si brouillées et floues qu'elles n'ont presque plus de sens. Maintenant, il vaut mieux les considérer comme plus de "philosophie", dans le sens où une architecture CISC a un jeu d'instructions plus riche avec des instructions individuelles plus puissantes (par exemple DIV et similaires) tandis qu'un jeu d'instructions RISC est simple et rapide, et laisse au compilateur le soin d'implémenter des opérations complexes. Même prétendument, les jeux d'instructions CISC (comme x86) sont traduits en instructions internes dans les puces Intel et AMD et implémentés davantage comme des processeurs RISC. Pour répondre à vos questions:

1. Les processeurs RISC académiques originaux (et je pense que peut-être les toutes premières versions commerciales) ont en effet exécuté une instruction par cycle, y compris l'extraction et le décodage. Cela était possible car les chemins de données étaient super propres car les opérations de chaque étape étaient simples et bien définies. (le compromis ici est que seules des instructions très simples peuvent être implémentées de cette façon). Une fois qu'il a frappé le monde réel, les choses se sont estompées. Des choses comme le pipelining et l'architecture superscalaire rendent impossible une dichotomie RISC / CISC simple.

2. Les puces RISC d'origine ont tenté d'exécuter une instruction par cycle et elles le pouvaient si les données étaient disponibles dans le fichier de registre. Bien sûr, si le processeur devait passer à la DRAM, cela prendrait (beaucoup) plus de temps. RISC consiste à "tenter" d'exécuter une instruction par cycle.

3. Un cycle d'instruction est le temps qu'il faut entre les récupérations.

4. Cela dépend énormément de l'instruction et de l'architecture du jeu d'instructions. Même dans une architecture CISC, certaines instructions peuvent s'exécuter très rapidement (comme un décalage vers la gauche ou la droite par exemple). Certains s'exécutent très lentement (10s de cycles ou plus). L'architecture VAX (probablement le summum de la philosophie du CISC) comportait des instructions vraiment complexes. Soit dit en passant, une architecture CISC est généralement plus facile à programmer en assembleur qu'une architecture RISC car elle ressemble presque à un langage de haut niveau!

La réponse courte

1. Les étapes de décodage et d'exécution de l'instruction sont exécutées en parallèle avec l'étape suivante de l'instruction précédente. Cette technique est connue sous le nom de pipelining. Voir Sur les processeurs RISC ci-dessous.

2. Une architecture RISC à problème unique sera généralement en moyenne légèrement inférieure à une instruction par cycle en raison des états d'attente et du temps nécessaire pour les opérations de chargement / stockage qui atteignent la mémoire plutôt que d'être simplement enregistré pour s'inscrire. Les créneaux de retard vous donnent un crochet architectural qui peut vous permettre de récupérer une partie de ce temps. Voir Sur les processeurs RISC ci-dessous.

3. Un cycle d'instructions est la durée nécessaire à l'exécution d'une instruction. Cela variera selon l'architecture et (dans certains cas) les instructions. Par exemple, la plupart des instructions sur quelque chose comme un MIPS R2000 / 3000 prennent un cycle. Les instructions impliquant l'accès à la mémoire (chargement / stockage, branche) prennent plus d'un cycle, bien que les créneaux de retard signifient que vous pourrez peut-être exécuter autre chose (peut-être juste un NOP) dans le créneau de retard. Les architectures non pipelinées peuvent avoir des cycles d'instructions de plusieurs cycles d'horloge, variant souvent avec le mode d'adressage. Voir ci-dessous sur les processeurs RISC, les architectures traditionnelles CISC et les architectures câblées .

   Les conceptions à problèmes multiples peuvent brouiller quelque peu ce concept en exécutant plusieurs instructions en parallèle.

4. Les processeurs CISC peuvent avoir des instructions qui prennent des durées variables. Le nombre exact de cycles d'horloge dépend de l'architecture et des instructions. Le nombre variable de cycles d'horloge pris sur les ISC CISC est l'une des raisons pour lesquelles ils sont difficiles à intégrer dans des architectures fortement pipelinées. Voir les architectures traditionnelles du CISC ci-dessous.

La réponse plus longue

Pour un seul problème MIPS, SPARC ou autre CPU, toutes les instructions (pour une première approximation) sont émises en un seul cycle, bien qu'elles puissent avoir quelque chose connu sous le nom de «délai d'attente».

Sur les processeurs RISC

Dans ce contexte, un processeur à problème unique est un processeur où le processeur ne fait aucune analyse de dépendance à la volée ni émission parallèle d'instructions comme le font les processeurs modernes, c'est-à-dire qu'ils n'ont qu'une seule unité d'exécution qui exécute les instructions dans l'ordre de lecture des mémos. Plus d'informations à ce sujet plus tard.

La plupart des processeurs RISC plus anciens sont des conceptions à problème unique, et ces types sont encore largement utilisés dans les systèmes embarqués. Un cœur RISC entier 32 bits à émission unique peut être implémenté dans environ 25 000 à 30 000 portes, de sorte que les cœurs de processeur de ce type ont une très faible consommation d'énergie et de très petites empreintes. Cela les rend faciles et bon marché à intégrer dans les produits SOC (système sur puce).

Les conceptions de CPU RISC sont en pipeline - le traitement de l'instruction se fait en plusieurs étapes, chaque instruction étant transmise dans le pipeline à l'étape suivante à chaque cycle d'horloge. Dans la plupart des cas, un processeur en pipeline à un seul problème exécutera quelque chose près d'une instruction par cycle d'horloge.

Certaines architectures ont des instructions telles que la ramification ou le chargement / stockage à partir de la mémoire où le cycle supplémentaire pris par l'accès à la mémoire est visible pour le code.

Par exemple, dans une conception SPARC V7 / V8 , l'instruction suivante après qu'une branche est réellement exécutée avant que la branche elle-même ait lieu. En règle générale, vous mettriez un NOP dans l'emplacement après la branche, mais vous pourriez y mettre une autre instruction si vous pouviez trouver quelque chose d'utile à faire.

L' architecture MIPS R2000 / R3000 avait un intervalle de retard similaire dans les instructions de chargement / stockage. Si vous chargez une valeur de la mémoire, elle n'apparaîtra pas réellement dans le registre pour un autre cycle. Vous pouvez mettre un NOP dans l'emplacement ou faire autre chose si vous pouvez trouver quelque chose d'utile à faire qui ne dépend pas de l'opération de chargement que vous venez d'émettre.

Si la mémoire était plus lente que le CPU, ce qui était souvent le cas, vous pourriez obtenir des états d'attente supplémentaires sur les accès à la mémoire. Les états d'attente gèlent le processeur pendant un ou plusieurs cycles d'horloge jusqu'à ce que l'accès à la mémoire soit terminé. En pratique, ces états d'attente et le temps supplémentaire pour les accès à la mémoire signifient que les conceptions de processeur à problème unique font en moyenne un peu moins d'une instruction par cycle d'horloge. Les créneaux de délai vous offrent quelques possibilités d'optimiser le code en exécutant une autre instruction pendant qu'une opération de mémoire a lieu.

Processeurs CISC traditionnels

Les processeurs du CISC étaient des conceptions qui pouvaient avoir des instructions prenant des durées variables. Souvent, ils avaient des instructions plus complexes implémentées directement dans le matériel qui devaient être effectuées dans le logiciel sur un processeur RISC.

La plupart des architectures mainframe et à peu près toutes les conceptions de PC jusqu'au M68K et Intel 386 étaient des processeurs CISC microcodés traditionnels. Ces conceptions se sont avérées plus lentes par horloge et utilisaient plus de portes que les processeurs RISC.

Microcode

Un exemple d'une architecture microcodée (MOS 6502) peut être vu ici en émulation . Le microcode est visible en haut de l'image.

Le microcode contrôle les flux de données et les actions activées dans la CPU afin d'exécuter les instructions. En parcourant les étapes du microcode, vous pouvez activer les parties d'un processeur, déplacer des données via des ALU ou effectuer d'autres étapes. Les composants réutilisables de la CPU peuvent être coordonnés sur plusieurs cycles d'horloge pour exécuter une instruction. Dans le cas du 6502, certaines actions en pipeline peuvent également être exécutées par le microcode.

Les conceptions microcodées utilisent moins de silicium que les puces câblées au détriment de potentiellement prendre plusieurs cycles d'horloge pour terminer une instruction. Selon la conception, ces CPU prendraient des durées variables par instruction.

Architectures câblées

Les conceptions câblées (pas nécessairement mutuellement exclusives avec le microcode) exécutent une instruction de manière synchrone ou peuvent avoir leurs propres coordinateurs pour faire quelque chose sur plusieurs cycles d'horloge. Ils sont généralement plus rapides au détriment d'un matériel plus dédié et sont donc plus coûteux à mettre en œuvre qu'une conception microcodée de fonctionnalités équivalentes.

Un exemple célèbre de ceci était le CPU Amdahl 470/6 original , qui était un remplacement direct du CPU sur certains modèles IBM System / 370. Le processeur Amdahl était une conception câblée à une époque où les 370 processeurs IBM étaient fortement basés sur le microcode. Le CPU Amdahl était environ 3 fois plus rapide que les CPU IBM qu'ils ont remplacés.

Inutile de dire qu'IBM n'a pas été amusé, ce qui a entraîné une bataille judiciaire qui a fini par forcer IBM à ouvrir son architecture mainframe jusqu'à l'expiration du décret de consentement il y a quelques années.

En règle générale, une conception câblée de ce type n'était toujours pas aussi rapide d'horloge pour horloge qu'un processeur RISC, car les différents horaires et formats des instructions ne permettaient pas autant de possibilités de pipelining qu'une conception RISC.

Conceptions à problèmes multiples

La plupart des processeurs modernes sont des architectures à problèmes multiples qui peuvent traiter plusieurs instructions à la fois dans un seul thread. La puce peut effectuer une analyse de dépendance dynamique sur le flux d'instructions entrant et émettre des instructions en parallèle où il n'y a pas de dépendance sur le résultat d'un calcul précédent.

Le débit de ces puces dépend du degré de parallélisme pouvant être atteint dans le code, mais la plupart des processeurs modernes feront en moyenne plusieurs instructions par cycle sur la plupart du code.

Les processeurs Intel et autres processeurs ISA x86 / X64 modernes ont une couche qui interprète le jeu d'instructions CISC à l'ancienne en micro-instructions qui peuvent être alimentées via un noyau à problèmes multiples de style RISC en pipeline. Cela ajoute une surcharge qui n'est pas présente sur les processeurs avec des ISA qui sont conçus pour le pipeline (c'est-à-dire les architectures RISC telles que ARM ou PowerPC).

VLIW conçoit

Les conceptions VLIW, dont l' Intel Itanium est peut-être le plus connu, ne sont jamais devenues des architectures grand public, mais IIRC il existe un certain nombre d'architectures DSP qui utilisent ce type de conception. Une conception VLIW rend la publication multiple explicite avec un mot d'instruction contenant plus d'une instruction émise en parallèle.

Celles-ci dépendaient de bons compilateurs d'optimisation, qui identifiaient les dépendances et les opportunités de parallélisme, en déposant des instructions dans les multiples emplacements disponibles sur chaque mot d'instruction.

Les architectures VLIW fonctionnent assez bien pour les applications numériques, car les opérations matricielles / matricielles offrent généralement des possibilités de parallélisme étendu. L'Itanium avait un marché de niche dans les applications de supercalculateur pendant un certain temps, et il y avait au moins une architecture de superordinateur - le Multiflow TRACE - a été produite en utilisant un ISA de ce type.

Mémoire et mise en cache

Les processeurs modernes sont beaucoup, beaucoup plus rapides que la mémoire, donc les lectures directes à partir de la mémoire peuvent générer des centaines d'états d'attente qui bloquent le processeur jusqu'à ce que l'accès à la mémoire se termine. La mise en cache, désormais effectuée en plusieurs couches, contient les emplacements mémoire les plus récemment utilisés dans le cache. Étant donné que les processeurs passent généralement la grande majorité du temps à exécuter du code en boucle, cela signifie que vous obtenez de bons taux de succès de réutilisation des emplacements de mémoire que vous avez utilisés récemment. Cette propriété est appelée «localité de référence».

Lorsque vous obtenez une localité de référence, le CPU peut fonctionner à une vitesse proche de la vitesse optimale. Le cache passe au niveau suivant et entraîne un certain nombre d'états d'attente; le cache qui manque à la mémoire principale peut entraîner des centaines.

Ainsi, le débit réel des puces CPU peut dépendre fortement de l'efficacité des modèles d'accès à la mémoire. Des livres entiers ont été écrits sur l'optimisation du code pour cela, et c'est un sujet complexe à part entière.

C'est une simplification pour les étudiants.

Chaque processeur non trivial est canalisé. Il y a une unité de prélecture pelletage d'instructions à une extrémité, un certain nombre d' unités d'exécution au milieu effectuant un travail réel, et une unité d'émission chargée de déclarer les instructions terminées après l'écriture dans le registre ou la mémoire. S'il existe plusieurs unités d'exécution (disons, une ALU entière, une ALU à virgule flottante et une unité vectorielle), il peut être possible d'émettre (parfois appelé "retirer") plusieurs instructions par cycle d'horloge. Comment un processeur peut-il fournir plus d'une instruction par cycle? va dans beaucoup plus de détails à ce sujet.

Comme vous le dites, que se passe-t-il en cas de retard de cache manquant? Intel Hyperthreading est une nouvelle solution: deux lots de registres d'état du processeur, un lot de logique de contrôle et des unités d'émission. Dès qu'un processeur virtuel se bloque, passez à l'état de l'autre. (c'est une simplification grossière en soi)

Le résultat de cela est que les manuels de CPU modernes donnent des temporisations d'instructions beaucoup plus vagues, et il est beaucoup plus difficile d'écrire un code de synchronisation à cycle précis, si par exemple vous essayez de produire de la vidéo en temps réel à partir de matériel qui ne devrait pas en être capable .

(La réponse spécifique à "Combien de temps une instruction CISC prend-elle dans les cycles d'horloge / d'instruction?" Est "regardez dans le manuel de référence du fabricant et elle aura des temps par instruction")

Les autres gars ont écrit beaucoup de bon matériel, donc je vais garder ma réponse courte: Autrefois, (les années 80 ici), les processeurs 8 bits de l'époque (6800, 6502, Z80, 6809 et autres) étaient considérés CISC. Certaines instructions pouvaient s'exécuter en 2 cycles d'horloge, mais il s'agissait de simples instructions telles que la définition / la suppression de bits d'indicateur dans un registre d'état du processeur. D'autres instructions peuvent prendre de 2 à 6 et même jusqu'à 9 cycles d'horloge pour s'exécuter. Ces processeurs avaient des instructions assez puissantes, le Z80 avait des instructions d'effacement des blocs de mémoire qui écriraient la même valeur dans une série d'octets en mémoire, effaçant efficacement un gros bloc dans une seule instruction, il suffit de configurer quelques registres et d'exécuter le Instruction LDIR (chargement, incrémentation et répétition).

Le processeur 6502 (de mémoire) avait 56 instructions mais 13 modes d'adressage créant un puissant jeu d'instructions.

RISC est venu longtemps et a adopté une approche différente, ont une poignée d'instructions qui s'exécutent toutes dans un seul cycle d'horloge. Les programmes ont tendance à être plus longs et à occuper plus de mémoire car les instructions sont simples dans les opérations qu'ils effectuent, vous en avez donc besoin de plus.

Si je me souviens bien, la première tentative d'architecture RISC a été le transputer ou le processeur Acorn Risc?