Serait-il utile de concevoir un processeur capable de gérer l’IL directement?

Question

Si je comprends bien ceci:

Les entreprises de développement de processeurs actuelles, telles qu'AMD et Intel, ont leurs propres codes API (le langage d'assemblage), ce qu'ils considèrent comme le langage 2G en plus du code machine (langage 1G)

Serait-il possible ou souhaitable (performances ou autre) d’avoir un processeur capable de gérer la gestion de l’IL en son cœur, au lieu des appels d’API actuels?

Answer 1

Il existe une technologie similaire pour Java: ARM utilise une gamme de processeurs capables de le faire, ils l’appellent "Jazelle". technologie.

Cependant, les opérations représentées par les codes d'opération .net IL ne sont bien définies qu'en combinaison avec les informations de type conservées dans la pile, et non par elles-mêmes. Il s’agit d’une différence majeure par rapport au bytecode Java et rendrait beaucoup plus difficile la création de matériel sensible pour l’exécution de l’IL.

De plus, IL est destiné à être compilé dans une cible finale. La plupart des back-ends qui crachent IL ne font que très peu d'optimisation, mais visent plutôt à conserver le contenu sémantique pour vérification et optimisation lors de la dernière étape de compilation. Même si les problèmes matériels pouvaient être résolus, le résultat serait presque certainement toujours plus lent qu'un JIT d'optimisation décent.

Donc, pour résumer: bien que ce ne soit pas impossible, cela serait beaucoup trop difficile par rapport aux autres architectures et permettrait de réaliser peu de choses.

Answer 2

Vous semblez un peu confus quant au fonctionnement du processeur. L'assemblage n'est pas une langue distincte du code machine. C’est simplement une représentation différente (textuelle) de celle-ci.

Le code d'assemblage est simplement une liste séquentielle d'instructions à exécuter. Et le code machine est exactement la même chose. Chaque instruction prise en charge par la CPU a un certain motif binaire qui la fait exécuter, ainsi qu’un nom textuel que vous pouvez utiliser dans le code assembleur.

Si j'écris ajoutez 10 $, 9 $, 8 $ et l'exécute via un assembleur, j'obtiens le code machine de l'instruction add, en prenant les valeurs des registres 9 et 8, en les ajoutant et en les stockant résultat dans le registre 10.

Il existe une correspondance 1 pour 1 entre l'assembleur et le code machine.

Il n'y a pas non plus d '"appels d'API". La CPU lit simplement l'adresse X et fait correspondre les bits suivants à toutes les instructions qu'elle comprend. Une fois qu'il trouve une instruction correspondant à ce modèle de bits, il l'exécute et lit le suivant.

Ce que vous demandez est dans un sens impossible ou contradictoire. IL représente le langage intermédiaire, c'est-à-dire une sorte de pseudocode émis par le compilateur, mais qui n'a pas encore été traduit en code machine. Mais si le CPU pouvait exécuter cela directement, alors ce ne serait plus intermédiaire, ce serait ce serait le code machine.

La question devient donc "votre code IL est-il une représentation meilleure et plus efficace d'un programme que le code machine que la CPU prend en charge maintenant?"

Et la réponse est probablement non. MSIL (je suppose que c'est ce que vous entendez par IL, qui est un terme beaucoup plus général) est conçu pour être portable, simple et cohérent. Chaque langage .NET est compilé en MSIL et chaque programme MSIL doit pouvoir être traduit en code machine pour n’importe quel processeur. Cela signifie que MSIL doit être général et abstrait et ne pas émettre d'hypothèses sur la CPU. Pour cette raison, autant que je sache, il s'agit d'une architecture purement basée sur des piles. Au lieu de conserver les données dans des registres, chaque instruction traite les données situées en haut de la pile. C'est un bon système propre et générique, mais il n'est pas très efficace et ne correspond pas bien à la structure rigide d'un processeur. (Dans votre merveilleux petit monde de haut niveau, vous pouvez prétendre que la pile peut croître librement. Pour que le CPU puisse y accéder rapidement, elle doit être stockée dans une mémoire de petite taille, rapide et sur puce avec une taille finie. si votre programme envoie trop de données sur la pile?)

Oui, vous pouvez créer un processeur pour exécuter MSIL directement, mais que gagneriez-vous? Vous n'avez plus besoin de code JIT avant l'exécution. Ainsi, la première fois que vous lancez un programme, celui-ci sera lancé un peu plus rapidement. En dehors de cela, cependant? Une fois que votre programme MSIL a été compilé, il a été converti en code machine et fonctionne aussi efficacement que s’il avait été écrit en code machine. Le bytecode MSIL n’existe plus, il n’ya plus qu’une série d’instructions comprises par la CPU.

En fait, vous seriez de retour là où vous étiez avant .NET. Les langages non gérés sont compilés directement en code machine, comme ce serait le cas dans votre suggestion. La seule différence est que le code non géré cible le code machine conçu par les concepteurs de CPU pour qu'il puisse être exécuté sur un CPU, alors que dans votre cas, il cible un code machine conçu par les concepteurs de logiciels pour être facilement traduit en de.

Answer 3

Ce n'est pas une idée nouvelle - la même chose était prévue pour Java et les machines Lisp . ont même été effectivement mis en œuvre.

Mais l'expérience avec ces produits montre que ce n'est pas vraiment utile - en concevant des processeurs spéciaux, vous ne pouvez pas bénéficier des avancées du logiciel "traditionnel". Les processeurs, et vous ne pourrez probablement pas battre Intel à leur propre jeu. Une citation de l'article de Wikipédia l'illustre parfaitement:

  

ordinateurs de bureau moins chers ont bientôt été en mesure de   exécuter des programmes Lisp encore plus vite que   Lisp machines, sans l'utilisation de   matériel à usage spécial.

Traduire d'un type de code machine à un autre à la volée est un problème bien compris et si courant (les CPU CISC modernes font même quelque chose de ce genre en interne car ils sont vraiment RISC) que je pense que nous pouvons en déduire fait assez efficacement pour que cela ne produise pas d'avantages significatifs - pas lorsque cela signifie que vous devez vous dissocier de l'état de la technique des processeurs traditionnels.

Answer 4

Je dirais non.

Les instructions en langage machine qui doivent être exécutées sur un ordinateur sont de niveau inférieur à IL. IL, par exemple, ne décrit pas vraiment comment les appels de méthodes doivent être effectués, ni comment gérer les registres, ni comment accéder à la pile, ni aucun autre détail nécessaire au niveau du code machine.

Faire en sorte que la machine reconnaisse IL directement, par conséquent, déplacerait toute la logique de compilation JIT du logiciel au matériel.

Cela rendrait l'ensemble du processus très rigide et immuable.

En disposant le langage machine basé sur les capacités de la machine et un langage intermédiaire basé sur la capture des intentions du programmeur, vous obtenez un système bien meilleur. Les personnes qui définissent la machine peuvent se concentrer sur la définition d’une architecture informatique efficace, tandis que celles qui définissent le système IL peuvent se concentrer sur des aspects tels que l’expressivité et la sécurité.

Si les vendeurs d’outils et les vendeurs de matériel devaient utiliser exactement la même représentation pour tout, l’innovation dans l’espace matériel ou dans l’espace outil serait entravée. Alors, je dis qu'ils devraient être séparés les uns des autres.

Answer 5

Je ne l'aurais pas pensé pour deux raisons: -

1. Si vous avez eu un traitement matériel du matériel, ce dernier ne pourrait pas exécuter une version plus récente du logiciel. Avec JIT, vous avez juste besoin d’un nouveau JIT, alors le matériel existant peut exécuter le nouvel IL.
2. IL est simple et est conçu pour être indépendant du matériel. L'IL devrait devenir beaucoup plus complexe pour lui permettre de décrire les opérations de la manière la plus efficace afin de se rapprocher des performances du code machine existant. Mais cela signifierait que l’IL serait beaucoup plus difficile à exécuter sur du matériel non spécifique à l’IL.