Il y a plusieurs raisons pour lesquelles on choisirait de mettre en œuvre un CDIC. La principale raison est la compatibilité binaire avec un jeu d'instructions CISC existant. Bien que la technologie de traduction logicielle binaire ait été améliorée, la compatibilité matérielle présente certains avantages techniques (ainsi que l’inconvénient de réduire la mise en cache de la traduction) et l’avantage moins technique de paraître plus fiable.
La densité de code est peut-être la deuxième raison la plus importante pour choisir CISC. Renesas RX a été conçu comme un CDIC spécialement conçu pour la densité de code car il cible les microcontrôleurs dont la taille de la mémoire est un facteur de coût important. Les instructions de longueur variable, les instructions complexes (principalement plusieurs modes d'adressage), les opérandes implicites et le compte de registres inférieur sont tous denses en codes de densité.
Une raison historique (et à mon avis erronée) de choisir CISC était de réduire l'écart sémantique entre les programmeurs utilisant un langage de niveau supérieur et le processeur. Étant donné que les instructions complexes peuvent généralement être remplacées par une séquence d'instructions plus simples, la complexité d'un compilateur de langage de niveau supérieur pour un RISC n'a pas besoin d'être beaucoup plus complexe que pour un CISC correspondant à un langage. RISC évite les "conflits sémantiques" (où une instruction de processeur fonctionne plus ou moins bien qu'une déclaration de langage correspondante) et facilite l'optimisation de la réduction de la force et de la planification. (Voir "Quels sont les compromis entre les efforts de développement de compilateur liés à CISC par rapport à RISC?" Pour plus de détails.)
L'exécution d'une instruction peut entraîner des coûts fixes importants. Cela encourage l'utilisation d'instructions relativement complexes pour répartir ces frais généraux sur un travail plus réel; réduire le nombre d'instructions dynamiques peut améliorer les performances. Lorsque le coût de la logique et de la RAM était bien supérieur au coût de la ROM, l'incitation à utiliser des instructions complexes était importante, car une instruction était décodée par recherche de microcode.
Une raison d'utiliser l'historique de CISC, peut-être contredite par des preuves historiques, est que le microcode peut être optimisé pour chaque microarchitecture alors que les bibliothèques standard peuvent être lentes à exploiter les fonctionnalités d'une nouvelle implémentation. Le niveau d'optimisation des implémentations logicielles de memcopy par rapport à celui du microcode pour REP MOVSB implique que les bibliothèques peuvent attirer davantage l'attention que le microcode. Cela peut provenir en partie du fournisseur de processeurs ciblant un plus grand nombre d’utilisateurs. Il peut donc être plus difficile de justifier un effort comparé à un logiciel open source ou à un logiciel interne où les intérêts localisés des développeurs ou des utilisateurs peuvent biaiser les efforts de mise en œuvre.
Le fait d’expédier une bibliothèque standard optimisée avec le processeur présente des avantages considérables. Le stockage et l'exécution d'une bibliothèque standard de plate-forme peuvent être considérablement optimisés par le code-logiciel logiciel-matériel. La distinction entre une instruction complexe et un appel de la couche d'abstraction de la plate-forme peut être subtile (ou inexistante). Une conception RISC pourrait utiliser les mêmes techniques de mise en œuvre pour traiter les appels PAL que le CISC pour les instructions complexes, y compris les opérations non fournies dans le jeu d'instructions générales avec du matériel spécialisé, la mise en cache et le décodage intelligents, et la spécification d'opérandes de registre (bien qu'un CISC utilisent souvent des registres dédiés similaires à un ABI par fonction). Le modèle mental associé à l'ICCA peut encourager de telles optimisations. En outre, les utilisateurs peuvent être moins offensés par l'inclusion forcée d'un "
Le décodage d'instructions relativement complexes peut entraîner moins de temps système (et peut-être plus de précision dans l'intention de discernement) que la technique comparable de reconnaissance d'idiome RISC, dans laquelle une séquence d'instructions est reconnue comme une unité sémantique. Cette différence de coût serait particulièrement perceptible dans une implémentation réduite, mais le temps système nécessaire pour utiliser cette information réduit l’importance des économies de décodage.
Des informations contextuelles supplémentaires peuvent faciliter l'optimisation du matériel. Par exemple, lors de l’incrémentation d’une valeur en mémoire, le matériel peut reconnaître que l’adresse de la mémoire est utilisée deux fois (pour le chargement et le stockage), offrant ainsi une possibilité de mémorisation de la manière mise en cache et de mise en cache de la traduction. Des instructions complexes peuvent fournir explicitement ces informations. Dans une instruction complexe, les valeurs intermédiaires ont une durée de vie explicite (celle de l'instruction); avec un registre RISC traditionnel, les valeurs doivent être explicitement remplacées pour indiquer la fin de la vie. (Remarque: un RISC peut spécifier un registre qui est toujours mis à zéro après chaque utilisation, fournissant ainsi un moyen de spécifier une valeur temporaire à usage unique. De telles instructions seraient modérément plus complexes.)
Si les détails de la mise en œuvre ne sont pas cachés derrière une couche d'abstraction, il devient plus difficile d'utiliser différentes microarchitectures à optimiser pour différents compromis. Exposer des détails microarchitecturaux en tant que garanties architecturales verrouille la microarchitecture dans la garantie de compatibilité. Bien que le logiciel PAL puisse être optimisé de la même manière que des instructions complexes, il nécessite un code-code matériel-logiciel. La séparation et la diversité organisationnelles rendent la codification plus difficile.
Des instructions complexes peuvent fournir un accès protégé à l'état privilégié. Par exemple, les instructions complexes sont souvent atomiques par rapport aux interruptions. Alors qu'un jeu d'instructions RISC pourrait fournir un mécanisme au niveau utilisateur pour suspendre temporairement les interruptions, il pourrait même s'agir de quelque chose comme une charge liée, de sorte que le logiciel tente explicitement l'opération s'il est interrompu, à condition que cela ne soit pas typique pour les RISC.
De même, une instruction complexe pourrait fournir un accès contrôlé et / ou une utilisation d'informations privilégiées. Étant donné que l'opération exécutée a une sémantique contrôlée, la violation de privilège réelle peut être évitée. Les alternatives orientées RISC incluent le code PAL (qui a généralement une surcharge importante) et un accès masqué aux registres de configuration (ou aux clichés instantanés de registres) ayant un état privilégié. Fournir une solution générale (RISC) est plus difficile que de fournir une solution à un ou plusieurs cas spéciaux (CDIC), mais il est plus puissant et moins vulnérable à l'accumulation de cas particuliers. Si on pense que les cas spéciaux importants sont peu nombreux, le CDIC peut être plus attrayant.
Des instructions complexes peuvent également masquer l'état d'un logiciel. Un avantage important de ce type serait la sauvegarde et la restauration du contexte. Avec des instructions qui sauvegardent et restaurent l’état, l’architecture doit seulement communiquer la taille du contexte au système d’exploitation, et non les mécanismes spécifiques de transfert d’état en mémoire. Cela permet aux applications s'exécutant sur un système d'exploitation existant d'utiliser des extensions ISA qui ajoutent un état. (Encore une fois, le logiciel PAL pourrait fournir les mêmes fonctionnalités.)
Une grande partie de la complexité de x86 provient de la compatibilité de nombreuses extensions. Avec des instructions complexes et moins orthogonales (utiles pour la densité de code), supprimez certains travaux inutiles, évitez les chaînes de dépendances inutiles (par exemple, un seul bit de retenue, un seul registre de valeur de décalage dynamique), en ajoutant des travaux être utilisé couramment et peut être optimisé dans le cadre d’une instruction complexe - l’une d’entre elles nécessiterait l’ajout d’une nouvelle instruction et rendrait l’ISA moins esthétique.
Dans de nombreux cas, un RISC ne rencontrerait pas de tels problèmes car les instructions sont hautement orthogonales et primitives. Dans certains cas, un RISC peut avoir besoin d'ajouter de nouvelles primitives, mais celles-ci seraient généralement applicables à plusieurs utilisations.
En outre, une fois que l'infrastructure est en place pour prendre en charge les instructions complexes, les obstacles sont réduits pour les instructions complexes supplémentaires. C'est-à-dire qu'une grande partie du coût des instructions complexes est non récurrente. Les ISA RISC sont fortement gênées par l’introduction des fonctionnalités de CISCy.
La fréquence d’extension de x86 peut également être attribuée en partie à sa popularité pour l’informatique grand public et le modèle de processeur du commerçant (qui augmentent également l’importance de la compatibilité binaire). Les ISA RISC ont souvent été liées à des fournisseurs de système, ce qui encourage une focalisation plus étroite sur les applications et le manque de concurrence pour la mise en œuvre d'une ISA RISC spécifique décourage quelque peu l'utilisation d'extensions de jeux d'instructions pour le marketing. La popularité réduit également le coût de développement de nouvelles extensions (les dépenses non récurrentes sont moins importantes lorsque le volume est élevé).
La philosophie de compatibilité x86 est probablement aussi axée sur l’extension des mécanismes existants plutôt que sur une rupture plus nette, ce qui signifie que les nouvelles fonctionnalités sont davantage influencées par les fonctionnalités existantes. Une fréquence d'extension plus élevée encourage également des modifications plus progressives, ce qui encourage les mécanismes de réutilisation, tendant à réduire l'orthogonalité.
Comparaison d'une présentation académique de MIPS classique (qui est un sous-ensemble des versions modernes de MIPS et exclut diverses extensions ISA facultatives) et de x86 moderne (qui retrace la compatibilité binaire jusqu'au code 8086 16 bits et la quasi-compatibilité au niveau de l'assemblage encore plus loin) avec tous ses bagages historiques ne présente pas le meilleur cas pour CISC, ni un cas réaliste pour RISC.