Comment les langues ont-elles influencé la conception du processeur? [fermé]

On nous dit souvent que le matériel ne tient pas compte de la langue dans laquelle un programme est écrit, car il ne voit que le code binaire compilé, mais ce n'est pas toute la vérité. Par exemple, considérons l'humble Z80; ses extensions du jeu d'instructions 8080 incluent des instructions telles que CPIR, ce qui est utile pour balayer des chaînes de style C (terminées par NULL), par exemple pour les effectuer strlen(). Les concepteurs doivent avoir identifié le fait que l'exécution de programmes en C (par opposition à Pascal, où la longueur d'une chaîne de caractères est dans l'en-tête) était susceptible de servir à leur conception. Un autre exemple classique est la machine Lisp .

Quels autres exemples y a-t-il? Par exemple, les instructions, le nombre et le type de registres , les modes d'adressage, qui permettent à un processeur particulier de préférer les conventions d'un langage particulier? Je suis particulièrement intéressé par les révisions de la même famille.

Les réponses existantes se concentrent sur les modifications d' ISA . Il y a aussi d'autres modifications matérielles. Par exemple, C ++ utilise couramment vtables pour les appels virtuels. À partir du Pentium M , Intel intègre un composant "prédicteur de branche indirecte" qui accélère les appels de fonctions virtuelles.

Le jeu d’instructions Intel 8086 inclut une variante de "ret" qui ajoute une valeur au pointeur de pile après l’ ajout de l’adresse de retour. Ceci est utile pour de nombreuses implémentations Pascal où l'appelant d'une fonction va placer des arguments sur la pile avant de faire un appel de fonction et les extraire ensuite. Si une routine accepte, par exemple, une valeur de quatre octets de paramètres, elle pourrait se terminer par "RET 0004" pour nettoyer la pile. En l'absence d'une telle instruction, une telle convention d'appel aurait probablement obligé le code à afficher l'adresse de retour dans un registre, à mettre à jour le pointeur de pile, puis à accéder à ce registre.

Il est intéressant de noter que la plupart des codes (y compris les routines de système d'exploitation) du Macintosh d'origine ont utilisé la convention d'appel Pascal malgré l'absence d'instruction de facilitation dans le 68000. L'utilisation de cette convention d'appel a permis d'économiser 2 à 4 octets de code sur un site 4-6 octets de code sur le site de retour de chaque fonction prenant des paramètres.

Un exemple est MIPS, qui a les deux addet addupour piéger et ignorer les débordements, respectivement. (Aussi subet subu.) Il avait besoin du premier type d’instruction pour les langues comme Ada (je pense que je n’ai jamais utilisé Ada), qui traitent explicitement des débordements et du second type pour les langues comme C qui les ignorent.

Si je me souviens bien, le processeur réel dispose de circuits supplémentaires dans l'ALU pour suivre les débordements. Si le seul langage qui importait était le C, il n'aurait pas besoin de ça.

La série Burroughs 5000 a été conçue pour prendre en charge efficacement ALGOL et le processeur Intel iAPX-432 a été conçu pour exécuter efficacement Ada. Le transputeur Inmos avait son propre langage, Occam. Je pense que le processeur "Propeller" de Parallax a été conçu pour être programmé à l'aide de sa propre variante de BASIC.

Ce n'est pas un langage, mais le jeu d'instructions VAX-11 contient une seule instruction pour charger un contexte de processus, qui a été conçu à la suite d'une demande de l'équipe de conception de VMS. Je ne me souviens pas des détails, mais ISTR nécessitait tellement d'instructions à mettre en œuvre que cela limitait sérieusement le nombre de processus pouvant être planifiés.

Une chose que personne ne semble avoir mentionnée jusqu’à présent est que les progrès en matière d’optimisation du compilateur (où le langage de base est en grande partie hors de propos) ont entraîné le passage des jeux d’instructions CISC (qui étaient en grande partie conçus pour être codés par des humains) aux jeux d’instructions RISC (qui étaient largement conçu pour être codé par les compilateurs.)

La famille Motorola 68000 a introduit un mode d’ adresse automatique qui rend la copie de données via le processeur très efficace et compacte.

[Exemple mis à jour]

c'était un code c ++ qui a influencé l'assembleur 68000

while(someCondition)
    destination[destinationOffset++] = source[sourceOffset++]

implémenté en assembleur classique (pseudocode, j'ai oublié les commandes de l'assembleur 68000)

adressRegister1 = source
adressRegister2 = destination
while(someCondition) {
    move akku,(adressRegister1)
    move (adressRegister2), akku
    increment(adressRegister1, 1)
    increment(adressRegister2, 1)
}

avec la nouvelle adresse, il est devenu quelque chose de similaire à

adressRegister1 = source
adressRegister2 = destination
while(someCondition) {
    move akku,(adressRegister1++)
    move (adressRegister2++), akku
}

seulement deux instructions par boucle au lieu de 4.

Le mainframe de la série Z d’IBM est le descendant de l’IBM 360 des années 1960.

Plusieurs instructions ont été mises en place pour accélérer les programmes COBOL et Fortran. L'exemple classique étant le BXLE- "Branch on Index Low Or Equal", qui est la plupart du temps une forboucle Fortran ou un COBOL PERFORM VARYING x from 1 by 1 until x > nencapsulé dans une seule instruction.

Il existe également toute une famille d'instructions décimales condensées destinées à prendre en charge l'arithmétique décimale à virgule fixe commune aux programmes COBOL.

Les premiers processeurs Intel présentaient les fonctionnalités suivantes, dont beaucoup sont désormais obsolètes en mode 64 bits:

• Instructions ENTER, LEAVE et RET nn [les premiers manuels expliquaient explicitement ceux qui ont été introduits pour les langages structurés en blocs, par exemple Pascal, qui prend en charge les procédures imbriquées]
• des instructions pour accélérer l’arithmétique des BCD (AAA, AAM, etc.); également support BCD en x87
• Instructions JCXZ et LOOP pour la mise en oeuvre de boucles comptées
• INTO, pour générer un piège sur un dépassement arithmétique (par exemple, dans Ada)
• XLAT pour les recherches de table
• BOUND pour vérifier les limites du tableau

L’indicateur de signature, situé dans le registre d’état de nombreuses CPU, permet de réaliser facilement des opérations arithmétiques signées ET non signées.

Le jeu d'instructions SSE 4.1 introduit des instructions pour le traitement des chaînes, comptées et terminées à zéro (PCMPESTR, etc.)

De plus, j'imagine qu'un certain nombre de fonctionnalités au niveau du système ont été conçues pour assurer la sécurité du code compilé (vérification de la limite de segment, portes d'appel avec copie de paramètres, etc.).

Certains processeurs ARM, principalement ceux des périphériques mobiles, incluent (d) l’extension Jazelle, qui est un interpréteur JVM matériel; il interprète directement le bytecode Java. La JVM compatible Jazelle peut utiliser le matériel pour accélérer l'exécution et éliminer une grande partie de la JIT, mais le repli sur la VM logicielle est toujours garanti si le bytecode ne peut pas être interprété sur une puce.

Les processeurs avec cette unité incluent l'instruction BXJ, qui place le processeur en mode "Jazelle" spécial, ou si l'activation de l'unité a échoué, elle est simplement interprétée comme une instruction de branche normale. L'unité réutilise les registres ARM pour maintenir l'état de la JVM.

ThumbEE est le successeur de la technologie Jazelle

Autant que je sache, c'était plus courant dans le passé.

Lors d’ une séance de questions au cours de laquelle James Gosling a déclaré qu’il existait des personnes qui essayaient de créer du matériel pouvant mieux gérer le bytecode de la machine virtuelle Java, mais qu’elles trouveraient alors un moyen de le faire avec des informations "génériques" communes x86 (peut-être en compilant le fichier). bytecode de manière intelligente).

Il a mentionné qu’il était avantageux d’utiliser la puce populaire générique (telle que celle d’Intel), car une grande société consacre d’énormes sommes d’argent au produit.

La vidéo vaut le détour. Il en parle à la minute 19 ou 20.

J'ai fait une recherche rapide de page et il semble que personne n'ait mentionné les processeurs développés spécifiquement pour exécuter Forth . Le langage de programmation Forth est basé sur une pile, compact et utilisé dans les systèmes de contrôle.

Le processeur Intel iAPX a été spécialement conçu pour les langues OO. N'a pas tout à fait travaillé, cependant.

L' iAPX 432 ( architecture Intel Advanced Processor ) était le premier microprocesseur 32 bits d'Intel, introduit en 1981 en tant que jeu de trois circuits intégrés. Il s’agissait de la conception majeure d’Intel pour les années 1980, mettant en œuvre de nombreuses fonctionnalités avancées de gestion multitâche et de gestion de la mémoire. La conception a donc été qualifiée de Micromainframe ...

L'iAPX 432 a été "conçu pour être entièrement programmé dans des langages de haut niveau" , Ada étant le principal logiciel, il prend en charge la programmation orientée objet et la récupération de place directement dans le matériel et le microcode . La prise en charge directe de diverses structures de données visait également à permettre aux systèmes d’exploitation modernes de l’iAPX 432 d’être implémentés avec beaucoup moins de code de programme que pour les processeurs ordinaires. Ces propriétés et caractéristiques ont permis de concevoir un matériel et un microcode beaucoup plus complexes que la plupart des processeurs de l'époque, notamment les microprocesseurs.

En utilisant la technologie des semi-conducteurs de son époque, les ingénieurs d’Intel n’ont pas été en mesure de traduire cette conception en une première mise en œuvre très efficace. Parallèlement au manque d'optimisation d'un compilateur Ada précoce, cela a contribué à la lenteur, mais au coût, des systèmes informatiques performants, réalisant des performances typiques à environ 1/4 de la vitesse de la nouvelle puce 80286 à la même fréquence d'horloge (au début de 1982).

Cet écart de performances initial par rapport à la ligne 8086 plutôt profilée et à bas prix était probablement la principale raison pour laquelle le plan d’Intel visant à remplacer cette dernière (plus tard connu sous le nom de x86) par l’iAPX 432 a échoué. Bien que les ingénieurs aient trouvé des moyens d'améliorer la conception de la prochaine génération, l' architecture iAPX 432 Capability commençait désormais à être considérée davantage comme une surcharge de mise en œuvre que comme un support de simplification à laquelle elle était destinée.

Le projet iAPX 432 était un échec commercial pour Intel ...

MOVEM du 68000 était ce qui convenait le mieux pour placer plusieurs registres sur la pile en une seule instruction, ce à quoi de nombreuses langues s'attendaient.

Si vous avez vu MOVEM (MOVE Multiple) précéder JSR (Jump SubRoutine) tout au long du code, vous saviez généralement que vous utilisiez du code C conforme.

MOVEM autorisait l'incrémentation automatique du registre de destination, permettant à chaque utilisateur de continuer l'empilement sur la destination ou la suppression de la pile en cas de décrémentation automatique.

http://68k.hax.com/MOVEM

L'architecture AVR d'Atmel est entièrement conçue dès le départ pour être adaptée à la programmation en langage C. Par exemple, cette note d'application développe davantage.

OMI ceci est étroitement lié à l’excellente réponse de rockets4kids , avec les premiers PIC16-s en cours de développement pour la programmation directe par assembleur (40 instructions au total), les familles ultérieures ciblant C.

Lors de la conception du coprocesseur numérique 8087, il était assez courant que les langages effectuent toutes les calculs en virgule flottante en utilisant le type de précision le plus élevé, et arrondissaient le résultat à une précision inférieure lors de l'affectation à une variable de moindre précision. Dans la norme C d'origine, par exemple, la séquence:

float a = 16777216, b = 0.125, c = -16777216;
float d = a+b+c;

favoriserait aet bà double, les ajouter, promouvoir cà double, ajouter, puis stocker le résultat arrondi à float. Même s’il aurait souvent été plus rapide pour un compilateur de générer du code permettant d’exécuter des opérations directement sur le type float, il était plus simple de disposer d’un ensemble de routines à virgule flottante qui ne fonctionneraient que sur le type double, ainsi que de routines à convertir en /. à partir de float, que d'avoir des ensembles distincts de routines pour gérer les opérations sur floatet double. Le 8087 a été conçu autour de cette approche de l'arithmétique, effectuant toutes les opérations arithmétiques en utilisant un type à virgule flottante de 80 bits [80 bits a probablement été choisi pour les raisons suivantes:

1. Sur de nombreux processeurs 16 et 32 ​​bits, il est plus rapide de travailler avec une mantisse 64 bits et un exposant séparé que de travailler avec une valeur qui divise un octet entre la mantisse et l'exposant.

2. Il est très difficile d'effectuer des calculs qui soient précis à la précision des types numériques utilisés. si vous essayez par exemple de calculer quelque chose comme log10 (x), il est plus facile et plus rapide de calculer un résultat précis à moins de 100 ul d'un type 80 bits que de calculer un résultat précis à moins de 1ulp d'un 64 bits Si vous arrondissez le premier résultat à une précision de 64 bits, vous obtiendrez une valeur de 64 bits plus précise que la dernière.

Malheureusement, les versions futures du langage ont changé la sémantique du fonctionnement des types à virgule flottante; alors que la sémantique 8087 aurait été très utile si les langages les avaient toujours pris en charge, si les fonctions f1 (), f2 (), etc. renvoyaient le type float, de nombreux auteurs de compilateurs se chargeraient de créer long doubleun alias pour le type double 64 bits plutôt que le type 80 bits du compilateur (et ne fournissent aucun autre moyen de créer des variables 80 bits), et d'évaluer arbitrairement quelque chose comme:

double f = f1()*f2() - f3()*f4();

de l'une des manières suivantes:

double f = (float)(f1()*f2()) - (extended_double)f3()*f4();
double f = (extended_double)f1()*f2() - (float)(f3()*f4());
double f = (float)(f1()*f2()) - (float)(f3()*f4());
double f = (extended_double)f1()*f2() - (extended_double)f3()*f4();

Notez que si f3 et f4 renvoient respectivement les mêmes valeurs que f1 et f2, l'expression d'origine doit clairement renvoyer zéro, mais nombre de ces dernières expressions ne le peuvent pas. Cela a conduit des personnes à condamner la "précision supplémentaire" du 8087 alors même que la dernière formulation serait généralement supérieure à la troisième et que, avec un code utilisant le double type étendu de manière appropriée, il serait rarement inférieur.

Dans les années qui ont suivi, Intel a réagi à la tendance du langage (à mon humble avis) à forcer les résultats intermédiaires à être arrondis à la précision des opérandes en concevant leurs processeurs ultérieurs de manière à favoriser ce comportement, au détriment du code précision sur les calculs intermédiaires.