Parce que chaque instruction a besoin d'un circuit pour l'implémenter.Plus vous ajoutez d'instructions, plus le processeur grossit.Étant donné que la plupart de ces opérations ne seront jamais utilisées, il s'agit simplement d'un gaspillage de complexité.

Toute la complexité peut même ralentir le processeur.Les processeurs RISC, tels que l'ARM, étaient basés sur l'idée de jeter un grand nombre d'opérations et de rendre le plus petit cœur de processeur résultant aussi rapidement que possible.

Même les processeurs X86 modernes, avec un énorme jeu d'instructions, ont fini par avoir un processeur plus rapide caché à l'intérieur, émulant un processeur très compliqué.

Pour compléter la réponse de Simon B, les GPU, par contre, effectuent de nombreux calculs complexes.Mais ils peuvent se résumer à des instructions multi-ajouts, A = B * C + D. Donc, ils essaient au moins d'avoir des instructions multi-ajouts complexes car ce sont des instructions communes.

Pour récapituler.Si vous ajoutez plus d'instructions, le processeur deviendra:

1. plus complexe, c'est-à-dire plus gros processeur et plus difficile à utiliser efficacement
2. plus lent.La vitesse à laquelle vous pouvez l'exécuter dépend de l'unité la plus lente
3. plus cher.Est-ce ce que veut votre client?

Lisez également à propos des "architectures risc vs cisc"

La plupart des ordinateurs ne contiennent que quelques milliers d'instructions, mais la largeur en bits (généralement 64 bits) permet techniquement aux ordinateurs d'avoir accès à des millions, voire des milliards d'instructions.

Tout d'abord, soyons clairs: être 64 bits ne signifie rien pour les instructions. La plupart des systèmes 64 bits utilisent des instructions de 32 bits, à l'exception de x86 où les instructions peuvent être de moins de 32 bits à plusieurs centaines de bits.

Quant à savoir pourquoi le nombre d'instructions est limité, pour un système utilisant des instructions 32 bits (ce qui est un nombre très efficace à utiliser), le nombre d'instructions possibles pouvant être encodées est quelque peu limité puisque vous souhaitez idéalement avoir à au moins 3 registres pour au moins quelques opcodes. Cependant, même x86 où les instructions peuvent avoir une longueur arbitraire a de l'ordre de quelques milliers d'instructions uniques (qui ne sont pas nécessairement toujours utilisées) car il n'y a pas beaucoup de choses utiles qu'une instruction peut faire. L'encodage de nombreuses instructions inutiles (comme le fait x86) ne vous fait pas nécessairement de mal, mais cela n'aide pas non plus.

Pourquoi n'ont-ils pas encore ajouté d'instructions supplémentaires aux microprocesseurs?

Intel et ARM ajoutent régulièrement de nouvelles instructions. En se concentrant sur l'intel, il y a eu les nouvelles instructions Haswell, les nouvelles instructions Broadwell, les nouvelles instructions Skylake, les nouvelles instructions Palm Cove (Cannonlake) et les nouvelles instructions Sunny Cove (Icelandake) de l'année dernière.

La plupart des instructions utiles ont été ajoutées il y a longtemps, donc elles ont généralement un effet marginal en moyenne, mais il existe des applications spécifiques où elles peuvent faire une grande différence.

La plupart des ordinateurs ne contiennent que quelques milliers d'instructions,

Cela dépend de la façon dont vous les comptez. Toutes les instructions ayant une fonction similaire doivent-elles être regroupées ou les différentes variantes doivent-elles être comptées séparément? Ou devraient-ils être regroupés en fonction des opérations que la CPU doit effectuer pour les implémenter (et dans quelle mesure ces opérations doivent-elles être différentes pour rendre les instructions «différentes»)?

Combien d'instructions x86-64 y a-t-il de toute façon?

La réponse? N'importe où de 981 à 3683 selon les critères que vous utilisez.

Mais pourquoi si peu (ou autant) alors qu'il pourrait y en avoir encore plus? Fondamentalement, la limite n'est pas technique, mais économique. Personne ne veut suffisamment de ces instructions supplémentaires pour justifier leur ajout.

Certains peuvent être extrêmement utiles, comme DIVIDE, EXPONENT ou conditionnel opérations.

Cela en représente une douzaine, dont la plupart des processeurs actuels ont déjà. Des millions ou des milliards d'instructions? Personne n'en veut.

Ce n'est pas parce que vous pensez qu'une instruction pourrait être «utile» que sa mise en œuvre en vaut la peine. Puisque presque tout le codage moderne est fait dans des langages de haut niveau, tant qu'il y a suffisamment d'instructions pour satisfaire les rédacteurs du compilateur, tout le monde est content. Toutes les autres opérations «utiles» souhaitées peuvent être implémentées dans un code de niveau supérieur.

Il y a bien sûr des exceptions à cela, c'est pourquoi les processeurs modernes ont tendance à contenir plus d'instructions. Mais il y a aussi eu des cas où des instructions ont été supprimées parce qu'elles n'étaient pas suffisamment utilisées pour justifier leur maintien. Cela peut être fait pour économiser du silicium, réduire la complexité, augmenter la vitesse ou simplement éviter d'avoir à prendre en charge des fonctionnalités dont personne ne veut.

J'ai du mal à trouver le document qui montre explicitement le format d'opcode pour ARM, mais de nombreux opcodes ont une grande partie de leur champ de bits réservée aux données immédiates ou aux décalages de branche.donc tous les 64 bits ou 32 bits ne sont pas là pour encoder différentes instructions, mais sont là pour encoder des données intégrées à l'instruction.

Je dirais que, sans doute, ils prennent en charge des millions d'instructions. Mais cela dépend vraiment de la façon dont vous définissez une "instruction".

En général, les instructions sont divisées en plusieurs champs - une partie indique en quoi consiste l'opération (ajouter, soustraire, diviser, créer une branche, sauter, lire, écrire, etc.), puis d'autres parties peuvent fournir des arguments - des valeurs immédiates ou enregistrer des indices. Ainsi, si vous regroupez toutes les valeurs immédiates possibles et toutes les indications de registre possibles ensemble, alors vous n'avez qu'un nombre relativement petit d'opérations. Comme chaque opération doit être évaluée sur du matériel dédié (enfin, plus ou moins ... des choses comme ajouter et soustraire peuvent être faites sur le même matériel avec une certaine configuration / prétraitement), le nombre d'opérations distinctes doit être limité par la zone et la complexité de la puce.

Cependant, différents arguments aboutissent à un code machine différent. Par exemple, prenez l'instruction RISC-V add, ADD rd, rs1, rs2 qui prend deux valeurs de registre, rs1 et rs2 , les ajoute ensemble, et place le résultat dans un troisième registre, rd . RISC-V a 32 registres, ce qui signifie qu'il y a 32 * 32 * 32 = 32 768 "instructions" différentes qui sont toutes mappées sur ADD, mais avec des arguments différents. De même, ADDI rd, rs1, imm prend une valeur immédiate de 12 bits, l'ajoute à rs1 et écrit le résultat dans rd . Ainsi, cela donne 32 * 32 * 4096 = 4 194 304 encodages distincts juste pour ADDI .

La division de "l'espace d'instructions" est une partie très importante de la conception d'un ISA.Quels bits vous utilisez pour les arguments de registre, quels bits vous utilisez pour des valeurs immédiates, quels bits vous utilisez pour déterminer l'opération, quels bits vous utilisez pour déterminer le format d'instruction, quels bits vous utilisez pour déterminer la taille d'instruction, etc.portant sur la flexibilité et l'expressivité du jeu d'instructions et la complexité du matériel de décodage requis dans la CPU.L'augmentation du nombre d'opérations disponibles se fait généralement au détriment de la flexibilité - taille immédiate, nombre d'arguments, nombre de registres adressables, etc.