Gei 431 Architecture des ordinateurs II – Frédéric Mailhot Étude de cas Maintenant qu’on a vu les pipelines, le superscalaire, le VLIW, la gestion des branchements… Nous verrons comment le tout est intégré dans quelques processeurs connus: 1. La famille Pentium, Pentium Pro, Pentium II, Pentium MMX, Pentium III, (Pentium 4) 2. Le processeur Itanium de Intel / HP 3. Le processeur Crusoë de Transmeta

© 2001 Frédéric MailhotUniversité de Sherbrooke Étude de cas Note de départ Nous parlerons ici de processeurs pour lesquels tous les détails techniques ne sont pas disponibles. Ce qui suit est donc incomplet, et peut contenir des erreurs.

© 2001 Frédéric MailhotUniversité de Sherbrooke Étude de cas Cas 1: Famille Pentium L’ensemble d’instructions (ISA – Instruction Set Architecture) x86 débute avec le processeur CISC 8086, suivi par la suite des processeurs scalaires 8088, 80286, Intel386, Intel486, suivi des processeurs superscalaires des familles P5 et P6 Le premier Pentium fait partie de la famille P5  C’est une machine superscalaire qui peut émettre 2 instructions par coup d’horloge La famille P6 apparaît en 1995, avec le Pentium Pro, suivi du Pentium MMX (P5) et du Pentium II (P6) en 1997 En 1999, on introduit les instructions « Internet Streaming SIMD extension » (ISSE), avec le Pentium III Fin 2000, apparaît le Pentium 4, avec ISSE 2, et le « hyper pipelining » (pipeline de 20 étages)

© 2001 Frédéric MailhotUniversité de Sherbrooke Étude de cas Cas 1: Famille Pentium AnnéeTypeTransistors (x 1000) mm MHzÉmission (  Ops) 1993Pentium3 1000, Pentium3 3000, Pentium MMX4 5000, PentiumPro5 5000, Celeron7 500 – , Pentium II7 5000,25233 – Pentium II Xeon7 5000,25400 – Pentium III9 5000,25450 – Pentium III Xeon9 5000, Pentium 4?0,181,3 – 2 GHz3 (?)

© 2001 Frédéric MailhotUniversité de Sherbrooke Étude de cas Cas 1: Famille Pentium Pentium II:  Exécution d’instructions dans le désordre, utilisation du « register renaming »  Utilisation de la méthode de Tomasulo  Mémoire cache séparée pour les instructions et les données  ISA: IA-32, instructions x86 transformées en instructions pseudo-RISC (  ops) envoyées dans une station de réservation centralisée (appelée « instruction window »)  Les  ops peuvent être exécutées dans le désordre, mais avant (et après) leur exécution elles sont envoyées à un tampon qui écrit les résultats dans le bon ordre (« reorder buffer »)

© 2001 Frédéric MailhotUniversité de Sherbrooke Étude de cas Cas 1: Microprocesseur Pentium II L2 Cache Bus Interface Unit Microcode Instruction Sequencer Instruction Fetch Unit (I-cache) Branch Target Buffer Register Alias Table Instruction Decode Unit External Bus Memory Reorder Buffer D-Cache Unit Reservation Station Unit Memory Interface Unit Functional Units Reorder Buffer and Retirement Register File

© 2001 Frédéric MailhotUniversité de Sherbrooke Étude de cas L2 Cache Bus Interface Unit Microcode Instruction Sequencer Instruction Fetch Unit (I-cache) Branch Target Buffer Register Alias Table Instruction Decode Unit External Bus Memory Reorder Buffer D-Cache Unit Reservation Station Unit Memory Interface Unit Functional Units Reorder Buffer and Retirement Register File Cas 1: Microprocesseur Pentium II (Décodage) Microcode Instruction Sequencer Instruction Fetch Unit (I-cache) Branch Target Buffer Register Alias Table Instruction Decode Unit I-Cache Next IP

© 2001 Frédéric MailhotUniversité de Sherbrooke Étude de cas Cas 1: Microprocesseur Pentium II (Décodage) Microcode Instruction Sequencer Instruction Fetch Unit (I-cache) Branch Target Buffer Register Alias Table Instruction Decode Unit I-Cache Next IP L’unité « Next IP » génère l’adresse pour le I-Cache  Basé sur l’information provenant du BTB, qui utilise un prédicteur adaptif 2 niveaux (type Yeh et Patt)  Le BTB a 512 entrées  Les branches mal prédites causent un délai moyen de 15 cycles (minimum: 11 cycles)

© 2001 Frédéric MailhotUniversité de Sherbrooke Étude de cas Cas 1: Microprocesseur Pentium II (Décodeur) Microcode Instruction Sequencer Instruction Fetch Unit (I-cache) Branch Target Buffer Register Alias Table Instruction Decode Unit I-Cache Next IP Alignement Instruction IA-32 Geneal DecoderSimple Decoder  op1  op2  op3

© 2001 Frédéric MailhotUniversité de Sherbrooke Étude de cas Cas 1: Microprocesseur Pentium II (Décodeur) Le Décodeur lit 16 octets, et aligne les octets des instructions (jusqu’à 7 octets / instruction), qui sont de taille variable Il y a 3 unités de décodage:  Le décodeur général (traite les instructions complexes, et génère de 1 à 4  ops)  2 décodeurs simples (traitent les instructions de LOAD et registre-à- registre, générant 1  op)  Le décodeur peut générer jusqu’à 6  ops par cycle  La station de réservation peut accepter jusqu’à 3  ops par cycle Alignement Instruction IA-32 Geneal DecoderSimple Decoder  op1  op2  op3

© 2001 Frédéric MailhotUniversité de Sherbrooke Étude de cas Cas 1: Microprocesseur Pentium II (Décodeur)  Les  ops sont des instructions pseudo-RISC, de taille fixe, qui contiennent un code d’opération, deux opérandes pour les sources, et un opérande pour la destination  Les instructions x86 les plus complexes (celles qui requièrent plus de 4  ops) sont décodées à l’aide du « Microcode Instruction Sequencer »  Instructions registres-à-registres: 1  op  Instructions Load: 1  op  Instructions Store, Read / Modify: 2  ops  Instructions registres-mémoire: 2- 3  ops  Instructions Read / Modify / Write: 4  ops  RAT: Conversion de registres en étiquettes liées au matériel  Ensuite, les  ops sont envoyées au ROB et au RSU Microcode Instruction Sequencer Instruction Fetch Unit (I-cache) Branch Target Buffer Register Alias Table (RAT) Instruction Decode Unit I-Cache Next IP

© 2001 Frédéric MailhotUniversité de Sherbrooke Étude de cas L2 Cache Bus Interface Unit Microcode Instruction Sequencer Instruction Fetch Unit (I-cache) Branch Target Buffer Register Alias Table (RAT) Instruction Decode Unit External Bus Memory Reorder Buffer D-Cache Unit Reservation Station Unit (RSU) Memory Interface Unit Functional Units Reorder Buffer (ROB) and Retirement Register File Cas 1: Microprocesseur Pentium II (ROB et RSU)

© 2001 Frédéric MailhotUniversité de Sherbrooke Étude de cas Cas 1: Microprocesseur Pentium II (ROB et RSU) Le ROB garde en mémoire l’ordre des  ops, pour qu’à la fin de leur exécution elles puissent être « retirées » (retired) dans le bon ordre (écriture dans les registres ou en mémoire) Le RSU contient une fenêtre de 20  ops, qui peuvent être exécutées dans le désordre Memory Reorder Buffer D-Cache Unit Reservation Station Unit (RSU) Memory Interface Unit Functional Units Reorder Buffer (ROB) and Retirement Register File

© 2001 Frédéric MailhotUniversité de Sherbrooke Étude de cas Cas 1: Microprocesseur Pentium II (Reorder Buffer - ROB) Le ROB est utilisé à deux reprises dans le processeur: 1.Entre le décodage des instructions et l’exécution des  ops : On indique alors l’ordre relatif des  ops dans une instruction et des  ops appartenant à des instructions distinctes 2.Après l’exécution, pour les retirer dans le bon ordre: Retirer une instruction, c’est écrire de façon permanente (commit) les changements de valeurs de registres et de la mémoire, dans une mémoire tampon temporaire, le Retirement Register File (RRF) Le processeur peut retirer 3  ops par coup d’horloge Une  op peut être retirée si:  Son exécution est terminée  Toutes les autres  ops de la même instruction sont terminées (?)  Toutes les autres instructions qui précèdent sont terminées (et leurs  ops respectives)  Il n’y a pas eu d’interruption, d’exception ou d’erreur de prédiction de branchement

© 2001 Frédéric MailhotUniversité de Sherbrooke Étude de cas L2 Cache Bus Interface Unit Microcode Instruction Sequencer Instruction Fetch Unit (I-cache) Branch Target Buffer Register Alias Table (RAT) Instruction Decode Unit External Bus Memory Reorder Buffer D-Cache Unit Reservation Station Unit (RSU) Memory Interface Unit Functional Units Reorder Buffer (ROB) and Retirement Register File Cas 1: Microprocesseur Pentium II (Exécution)

© 2001 Frédéric MailhotUniversité de Sherbrooke Étude de cas L2 Cache Bus Interface Unit Microcode Instruction Sequencer Instruction Fetch Unit (I-cache) Branch Target Buffer Register Alias Table (RAT) Instruction Decode Unit External Bus Memory Reorder Buffer D-Cache Unit Reservation Station Unit (RSU) Memory Interface Unit Functional Units Reorder Buffer (ROB) and Retirement Register File Cas 1: Microprocesseur Pentium II (Exécution) Reservation Station Unit (RSU) Port0 Port1 Port2 Port3 Port4 Store Functional Unit Load Functional Unit MMX FU Jump FU Integer Functional Unit MMX FU Floating Pt FU Integer Functional Unit

© 2001 Frédéric MailhotUniversité de Sherbrooke Étude de cas Cas 1: Microprocesseur Pentium II (Exécution) Reservation Station Unit (RSU) Port0 Port1 Port2 Port3 Port4 Store Functional Unit Load Functional Unit MMX FU Jump FU Integer Functional Unit MMX FU Floating Pt FU Integer Functional Unit Si une  op a les valeurs de ses opérandes d’entrées, et que le FU requis est libre, le RSU peut faire l’émission Le RSU peut émettre jusqu’à 5  ops par cycle (une par port), mais en moyenne c’est 3  ops

© 2001 Frédéric MailhotUniversité de Sherbrooke Étude de cas Cas 1: Microprocesseur Pentium II (Exécution) Port du RSUFU LatenceIntervalle d’émission 0 Integer Arithmetic / logical / Shift 11 Integer multiplication 41 Floating Point Add 31 Floating Point Multiplication 52 Floating Point Division Long MMX Arithmetic / logical / Shift 11 MMX Multiplication 31 1 Integer Arithmetic / logical / Shift 11 MMX Arithmetic / logical / Shift 11 2 Load 31 3 Store Address 31 4 Store Data 11

© 2001 Frédéric MailhotUniversité de Sherbrooke Étude de cas Cas 1: Microprocesseur Pentium II (Pipeline) BTB0 BTB1 IFU0 IFU1 IFU2 IDU0 IDU1 RAT ROB read Accès BTB Accès I-cache Decode Fetch et pre-decode Register renaming Reorder Buffer read Port 0 Port 1 Port 2 Port 3 Port 4 ROB read RSU Exécution Émission Reorder Buffer read Reservation Station ROB write RRF Retraite Reorder Buffer Write Retirement Opérations dans l’ordreOpérations dans le désordreOpérations dans l’ordre

© 2001 Frédéric MailhotUniversité de Sherbrooke Étude de cas Cas 1: Microprocesseur Pentium 4 (Diagramme)

© 2001 Frédéric MailhotUniversité de Sherbrooke Étude de cas Cas 1: Microprocesseur Pentium 4 (Pipeline) Le pipeline du Pentium 4 a 20 étages ( environ 2 fois plus que le Pentium III): Avantage: il est plus facile d’augmenter la fréquence de l’horloge Inconvénient: remplir / vider le pipeline prend du temps…

© 2001 Frédéric MailhotUniversité de Sherbrooke Étude de cas Cas 2: Itanium Développé conjointement par HP et Intel:  ISA mis au point chez HP  Design matériel principalement chez Intel But: mettre au point la prochaine génération de processeurs haute performance 64 bits Principes de base: éliminer les goulots d’étranglements connus des systèmes superscalaires existants

© 2001 Frédéric MailhotUniversité de Sherbrooke Étude de cas Cas 2: Itanium (2) Ce qui limite la performance dans les systèmes superscalaires « standard »:  Les branchements Les mauvaises prédictions limitent la performance Les petites branches (peu de code) ont peu de code à exécuter, ce qui limite le parallélisme  L’accès à la mémoire Utilise plus d’un coup d’horloge Souvent, on doit faire un load juste après un branchement  L’extraction du parallélisme des instructions Le compilateur « sérialise » le code, dont le parallélisme intrinsèque doit être redécouvert dynamiquement par le processeur

© 2001 Frédéric MailhotUniversité de Sherbrooke Étude de cas Cas 2: Itanium – Les limites de la performance: Branchements Erreurs de prédiction limitent la performance Les petits blocs de destination limitent le parallélisme  Mauvaise utilisation des machines ayant beaucoup d’unités d’exécution Ld R1 Use R1 St R2 Ld R4 Use R4 IF THEN ELSE Tranches d’exécution inutilisées

© 2001 Frédéric MailhotUniversité de Sherbrooke Étude de cas Cas 2: Itanium – Les limites de la performance (2): Latence de la mémoire Temps d’accès à la mémoire augmente continuellement par rapport à la vitesse des processeurs Délais de chargement exacerbés par les machines qui exécutent plus d’une instruction par coup d’horloge branchement load utilisation Le branchement est une barrière branchement load utilisation Machine scalaireMachine 4 X superscalaire

© 2001 Frédéric MailhotUniversité de Sherbrooke Étude de cas Cas 2: Itanium – Les limites de la performance (3): Extraction du parallélisme Modèle d’exécution séquentiel Le compilateur a une vue limitée, indirecte du matériel Code source original Code parallèle Compilateur Code machine séquentiel Code parallèle … Unités d’exécution multiples Matériel

© 2001 Frédéric MailhotUniversité de Sherbrooke Étude de cas Compilateur « Expose » Cas 2: Itanium – Meilleure stratégie: parallélisme explicite Le compilateur expose, améliore et exploite le parallélisme du programme source et le rend explicite dans le code machine Code source original « Améliore » Code machine parallèle « Exploite »

© 2001 Frédéric MailhotUniversité de Sherbrooke Étude de cas Cas 2: Itanium – Format des instructions Les instructions sont regroupées en paquets de 128 bits  Chaque instruction fait 40 bits Il y a un gabarit (template) de 8 bits qui indique quelles instructions peuvent s’exécuter en parallèle  Permet au compilateur d’extraire plus de parallélisme  Simplifie le matériel en éliminant les mécanismes de détection dynamiques  Augmentation modeste de la taille du code Instructions EPIC: Explicitely Parallel Instruction Computing (parallélisme explicite grâce aux gabarits) Instruction 1Instruction 0GabaritInstruction 2 Groupe de 128 bits 127 0

© 2001 Frédéric MailhotUniversité de Sherbrooke Étude de cas Cas 2: Itanium – Branchements traditionnels Architecture traditionnelle: 4 blocs de base Les conditions introduisent des branchements Instr 1 Instr 2. p1, p2 <- cmp(a == b) Jump p2 Instr 3 Instr 4. Jump Instr 5 Instr 6. Instr 7 Instr 8. if then else

© 2001 Frédéric MailhotUniversité de Sherbrooke Étude de cas Cas 2: Itanium – Utilisation de « prédicats » Instr 1 Instr 2. p1, p2 <- cmp(a == b) Jump p2 Instr 3 Instr 4. Jump Instr 5 Instr 6. Instr 7 Instr 8. if then else (p1) (p2)

© 2001 Frédéric MailhotUniversité de Sherbrooke Étude de cas Cas 2: Itanium – Utilisation de « prédicats » Instr 1 Instr 2. p1, p2 <- cmp(a == b) Jump p2 Instr 3 Instr 4. Jump Instr 5 Instr 6. Instr 7 Instr 8. if then else Architecture traditionnelle: 4 blocs Instr 1 Instr 2. p1, p2 <- cmp(a == b) Instr 7 Instr 8. if then else Instr 3 Instr 4. (p1) Instr 5 Instr 6. (p2) Architecture EPIC: 1 seul bloc Les prédicats permettent une meilleure utilisation du matériel parallèle

© 2001 Frédéric MailhotUniversité de Sherbrooke Étude de cas Cas 2: Itanium – Utilisation de « prédicats » Le compilateur a une plus grande marge de manœuvre pour faire le « scheduling » des instructions  La plupart des instructions peuvent inclure des prédicats  L’état de la machine (les registres et la mémoire) ne sont mis à jour que si le prédicat est vrai. Sinon, l’instruction devient effectivement un NOP  Le compilateur assigne des prédicats aux instructions, qui sont déterminés par les instructions de comparaison  EPIC définit 64 registres de prédicats à 1-bit L’utilisation de prédicats élimine les branchements  Convertit une dépendance de contrôle en dépendance de données  Réduit les pénalités pour les mauvaises prédictions Exécution parallèle de plus d’instructions  Utilisation plus efficace du matériel parallèle Sur les SPEC89, près de ½ des branchements sont éliminés

© 2001 Frédéric MailhotUniversité de Sherbrooke Étude de cas Cas 2: Itanium – Délais d’accès à la mémoire avec les machines traditionnelles La lecture de la mémoire affecte la performance de façon majeure  Souvent le LOAD est la 1ère instruction d’une cahîne d’instructions dépendantes  Il peut y avoir une grande latence  Les LOAD peuvent causer des exceptions Instr 1 Instr 2. Jump p2 Load Utilisation. Barrière Architecture traditionnelle

© 2001 Frédéric MailhotUniversité de Sherbrooke Étude de cas Cas 2: Itanium – Spéculation On sépare la lecture du traitement des exceptions  L’instruction de lecture spéculative (ld.s) démarre un Load et détecte les exceptions  Les exceptions sont propagées (à l’aide d’un jeton attaché au registre de destination) de ls.s à chk.s  La vérification spéculative (chk.s) « rend publiques » les exceptions détectées par ld.s Détection des exceptions Livraison des exceptions Architecture EPIC ld.s Instr 1 Instr 2 …. Jump p2 chk.s Utilisation. Propagation des Exceptions

© 2001 Frédéric MailhotUniversité de Sherbrooke Étude de cas Cas 2: Itanium – Spéculation Donne plus de liberté au compilateur pour le scheduling  Permet aux instructions ld.s d’apparaître avant les branchements  Chk.s demeure à sa position initiale, et initie une correction si une exception est détectée Instr 1 Instr 2. Jump p2 Load Utilisation. Barrière Architecture traditionnelleArchitecture EPIC ld.s Instr 1 Instr 2 …. Jump p2 chk.s Utilisation. Propagation des Exceptions Détection des exceptions Livraison des exceptions

© 2001 Frédéric MailhotUniversité de Sherbrooke Étude de cas Cas 2: Itanium: Exemple - La boucle des 8 Reines if ((b[ j ] == true) && (a[ i + j ] == true) && (c[ i - j + 7 ] == true)) Vrai Mauvaise préd 38% 43% 72% 33% 47% 39% Code original R1 = &b[ j ] R3 = &a [i+j] R5 = &c [i-j+7] Ld R2 = [R1] P1, P2 <- cmp(R2 == true) br exit Ld R4 = [R3] P3, P4 <- cmp(R4 == true) br exit Ld R6 = [R5] P5, P6 <- cmp(R6 == true) br then else cycles, 3 mauvaises prédictions possibles

© 2001 Frédéric MailhotUniversité de Sherbrooke Étude de cas Cas 2: Itanium: Exemple - La boucle des 8 Reines if ((b[ j ] == true) && (a[ i + j ] == true) && (c[ i - j + 7 ] == true)) Code original R1 = &b[ j ] R3 = &a [i+j] R5 = &c [i-j+7] Ld R2 = [R1] P1, P2 <- cmp(R2 == true) br exit Ld R4 = [R3] P3, P4 <- cmp(R4 == true) br exit Ld R6 = [R5] P5, P6 <- cmp(R6 == true) br then else cycles, 3 mauvaises prédictions possibles 9 cycles, 3 mauvaises prédictions possibles Spéculation R1 = &b[ j ] R3 = &a [i+j] R5 = &c [i-j+7] Ld R2 = [R1] Ld.s R4 = [R3] Ld.s R6 = [R5] P1, P2 <- cmp(R2 == true) br exit 1 2 Chk.s R4 P3, P4 <- cmp(R4 == true) br exit 6 Chk.s R6 P5, P6 <- cmp(R6 == true) br then else 8 9

© 2001 Frédéric MailhotUniversité de Sherbrooke Étude de cas Cas 2: Itanium: Exemple - La boucle des 8 Reines if ((b[ j ] == true) && (a[ i + j ] == true) && (c[ i - j + 7 ] == true)) 9 cycles, 3 mauvaises prédictions possibles Spéculation R1 = &b[ j ] R3 = &a [i+j] R5 = &c [i-j+7] Ld R2 = [R1] Ld.s R4 = [R3] Ld.s R6 = [R5] P1, P2 <- cmp(R2 == true) br exit 1 2 Chk.s R4 P3, P4 <- cmp(R4 == true) br exit 6 Chk.s R6 P5, P6 <- cmp(R6 == true) br then else cycles, 1 mauvaise prédiction possible 2 Usage de prédicats R1 = &b[ j ] R3 = &a [i+j] R5 = &c [i-j+7] Ld R2 = [R1] Ld.s R4 = [R3] Ld.s R6 = [R5] P1, P2 <- cmp(R2 == true) br exit Chk.s R4 P3, P4 <- cmp(R4 == true) br exit Chk.s R6 P5, P6 <- cmp(R6 == true) br then else

© 2001 Frédéric MailhotUniversité de Sherbrooke Étude de cas Cas 2: Itanium: Exemple - La boucle des 8 Reines if ((b[ j ] == true) && (a[ i + j ] == true) && (c[ i - j + 7 ] == true)) 7 cycles, 1 mauvaise prédiction possible 2 Usage de prédicats R1 = &b[ j ] R3 = &a [i+j] R5 = &c [i-j+7] Ld R2 = [R1] Ld.s R4 = [R3] Ld.s R6 = [R5] P1, P2 <- cmp(R2 == true) br exit Chk.s R4 P3, P4 <- cmp(R4 == true) br exit Chk.s R6 P5, P6 <- cmp(R6 == true) br then else Code original R1 = &b[ j ] R3 = &a [i+j] R5 = &c [i-j+7] Ld R2 = [R1] P1, P2 <- cmp(R2 == true) br exit Ld R4 = [R3] P3, P4 <- cmp(R4 == true) br exit Ld R6 = [R5] P5, P6 <- cmp(R6 == true) br then else cycles, 3 mauvaises prédictions possibles Résultat: réduction de près de la moitié du nombre de cycles 2/3 des erreurs possibles de prédictions sont éliminées

© 2001 Frédéric MailhotUniversité de Sherbrooke Étude de cas Cas 2: Itanium - Conclusion EPIC (Explicitely Parallel Instruction Computing)  Utilise du code assembleur où le parallélisme est indiqué explicitement avec des gabarits (templates)  Utilise la prédication pour éliminer les branchements (utilisation de 64 registres de statut qui permettent l’exécution conditionnelle d’instructions)  Utilise la spéculation pour diminuer l’impact des Loads (on sépare le chargement du traitement des exceptions) Architecture des instructions faite pour que les processeurs soient facilement améliorés par des ajouts de matériel parallèle supplémentaire

© 2001 Frédéric MailhotUniversité de Sherbrooke Étude de cas Cas 3: Crusoë de Transmeta Processeur destiné au marché des machines portables  Requiert très peu de puissance électrique comparé à d’autres processeurs ayant des performances semblables Attrait intéressant: utilise un noyau VLIW sur lequel un émulateur logiciel peut interpréter des instructions destinées à un autre processeur  Transmeta a démontré l’utilisation d’une application hybride Java / x86, où l’ensemble des instructions sont exécutées (interprétées et traduites) sur le VLIW sous- jacent

© 2001 Frédéric MailhotUniversité de Sherbrooke Étude de cas Cas 3: Crusoë de Transmeta Pour contrôler ses besoins de puissance électrique, Crusoe détecte si le système est peu utilisé, et à la fois réduit la fréquence de l’horloge (de 700 MHz à 200MHz) et le potentiel d’alimentation (de 1,65 V à 1,1 V) Puisque P = ½ f * C V^2,  La puissance est diminuée de (700 / 200) * (1,65 / 1,1)^2 et P’ = (1 / 7,88) * P( près de 8 fois moins de puissance )

© 2001 Frédéric MailhotUniversité de Sherbrooke Étude de cas Cas 3: Crusoë – CMS ( Code Morphing Software ) Le processeur Crusoe est un VLIW sur lequel s’exécute un logiciel d’interprétation d’instructions x86

© 2001 Frédéric MailhotUniversité de Sherbrooke Étude de cas Cas 3: Crusoë - CMS Le CMS (Code Morphing System) Interprétation des instructions x86 en instructions VLIW Mise en mémoire des séquences d’instructions fréquentes Réutilisation des instructions déjà traduites

© 2001 Frédéric MailhotUniversité de Sherbrooke Étude de cas Cas 3: Crusoë: Diagramme Diagramme du 5400:

© 2001 Frédéric MailhotUniversité de Sherbrooke Étude de cas Cas 3: Crusoë Le 5400: