« Fonctionnement d'un ordinateur/Les jeux d'instructions » : différence entre les versions

Les jeux d'instructions CISC sont les plus anciens et étaient à la mode jusqu'à la fin des années 1980. AÀ cette époque, on programmait rarement avec des langages de haut niveau et beaucoup de programmeurs codaient en assembleur. Avoir un jeu d'instruction complexe, avec des instructions de "haut niveau" qu'on ne devait pas refaire à partir d'instructions plus simples, facilitait la vie des programmeurs.

Cette complexité des jeux d'instructions n'a pas que des avantages "humains", mais a aussi quelques avantages techniques. Le premier est une meilleure densité de code : un programme codé sur CISC utilise moins d'instructions et prend moins de mémoire. AÀ l'époque des processeurs CISC, la mémoire était rare et chère, ce qui faisait que les ordinateurs n'avaient pas plusieurs gigaoctets de mémoire : économiser celle-ci était crucial. Cet avantage était donc crucial, ce qui contrebalançait les défauts de ces architectures. Ces défauts étaient essentiellement le fait que le grand nombre d'instructions entraîne une grande consommation de transistors et d'énergie. La difficulté de conception de ces processeur était aussi sans précédent.

Les processeurs dédiés ont eu leur heure de gloire au début de l'informatique, à une époque où les langages de haut niveau venaient d'être inventés. AÀ cette époque, les compilateurs n'étaient pas performants et ne savaient pas bien optimiser le code machine. Les programmes compilés faisaient un mauvais usage des instructions machines, ne savaient pas bien utiliser les modes d'adressages adéquats, manipulaient assez mal les registres, etc. Il était alors rationnel, pour l'époque, de rapprocher le code machine cible et le langage de programmation de haut niveau. De nombreuses architectures dédiés ont ainsi étés inventées, avant que les concepteurs se rendent compte des défauts de cette approche. AÀ l'heure actuelle, les algorithmes des compilateurs se sont améliorés et savent nettement mieux utiliser le matériel. Ils produisent du code machine efficace, ce qui rend les architecture dédiées bien moins intéressantes. Si on ajoute les défauts de ces architectures dédiées, par étonnant que les architectures dédiées aient presque disparues. Les défauts en question ne sont pas nombreux, mais assez simples à comprendre. Premièrement, elles sont très rapides pour un langage de programmation en particulier, mais sont assez mauvaises pour les autres, d'où un problème de "compatibilité". Ajoutons à cela que les langages de programmation peuvent évoluer, devenir de moins en moins populaires/utilisés, ce qui rend la création d'architectures généralistes plus pertinente. Enfin, les architectures dédiées sont évidemment des processeurs CISC, pour implémenter les nombreuses fonctionnalités des langages évolués. Et les défauts des CISC sont assez rédhibitoires à l'heure actuelle.

En regardant dans les langages de programmation un peu plus connus, on peut aussi citer des processeurs spécialisés pour Java. Certains processeurs ARM, qu'on trouve dans des système embarqués, sont de ce type. Mais ceux-ci sont un petit peu à part et ne sont pas vraiment des architectures dédiées. En réalité, ces processeurs sont une implémentation matérielle de la machine virtuelle Java. Rappelons que la machine virtuelle JAVA est un design de processeur comme un autre, avec un jeu d'instruction simple, une architecture à pile, etc. Le code machine associé à cette architecture est appelé le ''bytecode'' Java. En temps normal, le ''bytecode'' Java n'est pas exécuté directement par le processeur, qui utilise un langage machine différent. AÀ la place, le ''bytecode'' est traduit dans le langage machine adéquat, par un interpréteur/compilateur. c'est ce qui permet au ''bytecode'' Java d'être portable sur des architectures différentes. En fait, le ''bytecode'' Java est utilisé comme intermédiaire : on compile du code Java en ''bytecode'' Java, qui est traduit sur l'architecture cible quand on en a besoin. Les architectures Java permettent de se passer de l'étape de traduction ''bytecode'' -> langage machine, vu que eur langage machine est le ''bytecode'' Java lui-même.