Est-ce que le compilateur juste dans le temps et si oui note:
Wikipedia ne répertorie pas CIL comme une langue d'assemblage dans son Liste des langues de montage (JIT) est vraiment la carte de chacun des langues intermédiaires communes (CIL) instructions dans un programme de «code> opcodes de processeur sous-jacent ?
4 Réponses :
Le CIL est plus un bytecode qu'une langue d'assemblage. En particulier, il n'est pas une forme textuelle lisible par l'homme, contrairement aux langages d'assembleur (probablement CIL définit également le format des fichiers bytecode).
Le MSIL JIT est une implémentation d'un machine virtuelle pour ce bytecode. Comment les implémentations (de Microsoft ou de Microsoft ou de mono ) Traduire CIL en Code de la machine est un détail de mise en œuvre qui ne devrait pas vraiment compter Vous (et étant donné que Microsoft VM est probablement propriétaire, puis ne vous dira pas comment cela est fait). Je pense que la mise en œuvre du logiciel libre mono -a en utilisant LLVM de sorte que vous ne traduisez probablement pas chaque bytecode à la fois mais probablement des méthodes ou des fonctions entières.
Bytecode est une représentation physique ou une version "compilée" de CIL. CIL n'est pas un bytecode.
Cette question concerne toutes les définitions, alors définissez les termes correctement. Premièrement, Langue d'assemblage :
Langue d'assemblage est un langage de programmation de bas niveau pour les ordinateurs, les microprocesseurs, les microcontrôleurs et d'autres périphériques programmables dans lesquels chaque instruction correspond à une seule instruction linguistique. Un langage de montage est spécifique à une certaine architecture informatique, contrairement à la plupart des langages de programmation de haut niveau, qui sont généralement portables pour plusieurs systèmes.
Maintenant, CIL :
Le langage intermédiaire commun est le langage de programmation lisible par l'homme le plus bas défini par la spécification d'infrastructure de langue commune (CLI) et est utilisé par le .NET Framework et Mono. Langues qui ciblent un environnement d'exécution compatible CLI compatible avec CIL, qui est assemblé dans un code d'objet comportant un format de style byTecode.
D'accord, cette partie n'est techniquement pas correcte: par exemple C # compilateur compile directement au bytecode, il ne passe pas par CIL (la langue lisible par l'homme), mais théoriquement, nous pouvons imaginer que c'est ce qui se passe.
Avec ces deux définitions, CIL est un langage d'assemblage, car chaque instruction est compilée dans une seule instruction de bytecode. Le fait qu'il n'y ait aucun ordinateur physique qui peut exécuter que le bytecode ne compte pas directement.
La définition indique que chaque langage de montage est "spécifique à une architecture informatique donnée". Dans ce cas, l'architecture est la machine virtuelle CLR.
À propos de JIT: Le compilateur JIT ne peut pas être considéré comme un assembleur: il ne fait pas la traduction de 1: 1 à partir du formulaire lisible humain à Bytecode,
Ilasm Est-ce.Le compilateur JIT est un compilateur qui compile de Bytecode à un code de machine natif (pour tout ce qui est en cours d'exécution), tout en effectuant des optimisations.
Les machines virtuelles effectuent la compilation JIT sur des instructions de machine spécifiques (X86, X64, IA64, etc.).
Une partie de la question de l'OPS a posé une question sur le JIT.
@PeterRitchie Droite, merci, j'ai ajouté un court paragraphes sur JIT.
@svick Ilasm génère une exécutable portable (PE) contenant MSIL et les métadonnées requises ..Comment-ce que cela peut être un assembleur!
@Anirudha à proprement parler, le fichier généré ne contient pas de CIL, il contient CIL Bytecode . Ce qui est exactement ce que l'assembleur (le programme) est censé faire: Traduire un programme lisible par l'homme 1: 1 dans un code lisible par machine. L'assembleur n'a pas à compiler au code de la machine X86.
@Anirudha aussi, pourquoi pensez-vous que cela doit vouloir dire que ce n'est pas un assembleur? Quelle partie de la définition de la langue de montage que j'ai donnée ci-dessus est-elle en contredite? Ou êtes-vous en désaccord avec la définition?
@svick Comment pouvons-nous utiliser ILASM pour produire du code machine X86 et X64.Ouissons-nous d'utiliser des options lors de l'utilisation de Ilasm
@Anirudha qu'est-ce qui fait du code de machine X86 spécial? L'assembleur n'a pas à produire du code X86, par exemple, le bras ne fait pas non plus cela. Et par exemple, les compilateurs de certains C produisent du code de machine X86, mais ils ne sont pas des assembleurs. L'assembleur n'a rien à voir avec le code de la machine X86.
Très bonne réponse. +1 pour commencer par la terminologie et travailler à une conclusion logique à partir de là. Peut-être serait-il bon de dire qc. sur la manière dont la génération supplémentaire de métadonnées d'autres instructions affecte ilasm étant un assembleur (et donc cil un langage d'assemblage), selon les termes "Définitions" ...?
L'assemblage est composé de mnémoniques pour les instructions de code de machine d'un processeur particulier. Une représentation directe des 1s et 0S qui rend le code de l'exécution de base, mais écrit dans le texte pour faciliter la tâche d'un humain. Ce qui est très différent de CIL:
Cette dernière balle est une clé essentielle, une décision de conception qui rend le CIL fortement différent du bytecode est que les instructions de CIL sont moins de type. Il n'y a qu'une seule instruction, mais les processeurs ont de nombreuses versions. Celles spécifiques qui prennent des octets, courts, int, long, flotteur et doubles opérandes. Nécessaire car différentes parties du noyau de processeur sont utilisées pour exécuter l'add. La gigue choisit le bon, sur la base du type des opérandes qu'elle déduit des instructions de CIL précédentes.
Tout comme l'opérateur + dans la langue C #, il peut également fonctionner avec différents types d'opérande. Ce qui rend vraiment le L en CIL significatif, c'est une langue. Un simple, mais il est seulement simple d'aider à faciliter la rédaction d'une gigue pour cela.
Pourquoi est-il important qu'un processeur physique existe? Et si quelqu'un fait un processeur physique pour le bytecode de CIL à l'avenir, cela fera-t-il soudainement une langue d'assemblage? En outre, cela signifie-t-il que Mixal n'est pas une langue d'assemblage?
Un tel "que si" n'est pas très productif. Le fait est qu'il n'existe pas de processeur de ce type, la dernière partie de ma réponse a souligné une raison probable pour laquelle nous n'en avons toujours pas un. Même Java n'est pas là, Jazelle n'exécute pas tous les codes d'octets. Je vais promettre cela dès que j'en ai un dans ma machine qui me permet de poster à alors je vais l'utiliser éditer cette réponse. Pourrait arriver, voyons ce que produit Midori.
Mon point est qu'une définition qui repose sur l'existence d'une pièce spécifique de matériel est idiote. Le matériel spécifique ne fait pas une langue d'assemblage, la mécanique de sa compilation.
Hmm, non, cela fait dans le cas de l'assemblage. Votre exemple de mixal nécessite un émulateur , une partie du logiciel qui émule du matériel. Le processeur fictif de Knuth dans ce cas. Ce n'est jamais un intérêt académique (les étudiants apprenant des MIPS par exemple), ou intéressant d'exécuter des roms d'anciens matchs, les émulateurs sont trop lents pour toujours être utiles dans l'informatique générale.
Donc, vous dites que la langue de l'assemblage de mélange n'est pas une langue d'assemblage et que Knuth ne sait pas ce que "langage de montage" signifie?
Les émulateurs exécutent les 1s et les 0s produits par un assembleur. Je n'ai pas particulièrement en train de profiter de la direction de ce sentier de commentaire, appelons ça quitte.
La ligne est en fait assez floue ... les arguments que j'ai vus contre appelant Intel et AMD n'ont pas fait que les processeurs qui exécutent des instructions de montage exactement comme étant émis dans des décennies (si jamais), un code "natif" n'est donc pas très différent de l'exécution d'une machine virtuelle dont le bytecode est spécifié dans < Code> x86 / si Pour ajouter encore une autre ride, la manière dont un Je suppose donc que voici des critères qui peuvent justifier les mettre en deux catégories distinctes:
donc concernant le "code CIL Un "langage d'assemblage" peut s'appliquer presque aussi à x86 / x86-64 dans la pratique.
x86-64 .
x86 / x86-64 sont la chose la plus basse que les développeurs typiques ont accès à, donc si nous devions mettre notre pied en panne et appeler quelque chose dans notre écosystème un "Langue de montage", qui gagnerait, et puisque cil bytecode nécessite finalement x86 / x86-64 instructions pour pouvoir exécuter sur un processeur Dans cette famille, il y a alors une affaire assez forte à faire valoir qu'il ne "ressent que" comme ça devrait compter.
x86 / x86-64 processeurs, nous ne faisons presque jamais référence à des processeurs qui exécutent x86 / x86-64 sans le traduire en quelque chose d'autre (c'est-à-dire quel que soit le microcode).
x86 / x86-64 Le processeur exécute une séquence d'instructions donnée peut changer simplement en mettant à jour le microcode. Une recherche rapide montre que Linux peut même faciliter la tâche de faire ce que vous-même dans le logiciel !
cil bytecode sont implémentées dans des logiciels?
x86 / x86-64 d'une manière différente après avoir été instruit de le faire dans des logiciels?
x86 / x86-64 processeurs? < / li>
cil une question de langage de montage" Les meilleures réponses que je peux donner sont "Cela dépend" (pour les scientifiques) et "à peu près" (pour les ingénieurs).
Question intéressante, j'ai essayé de répondre, mais ce n'est pas si facile. Je pense que vous ne pouvez pas considérer cela une langue d'assemblage puisqu'il n'y a pas de véritable processeur qui l'exécute directement.
@Felicepollano puis cil peut-être une langue d'assemblage partielle .. :)
Langue de montage Mnemonics correspondre 1: 1 avec des instructions de code de machine spécifiques spécifiques à la CPU. Un assembleur mappe simplement le code de montage lisible par l'homme (Sorta) à ces instructions. Ce n'est certainement pas le cas avec CIL. Ce n'est pas partiel, ce n'est tout simplement pas - la langue de montage a une définition très claire.
@jamietre vous avez raison, mais alors y peuple appelle ça un langage de montage orienté objet
Je ne l'ai pas entendu appelé cela auparavant, je pense que le bytecode orienté objet serait plus précis
Je ne suis même pas sûr si "orienté objet" est-ce important pour CIL (même si l'architecture de la CLI favorise clairement le paradigme OO). Son modèle d'évaluation basé sur la pile est beaucoup plus important, de même que l'accent mis sur la fourniture de métadonnées en plus de bytecode. Votre langage de montage typique ne se soucierait pas des métadonnées du tout.
@stakx Je dirais que la statique, l'instance et les méthodes virtuelles distinctes et même une instruction spécifique spécifiquement pour les appels virtuels rendent OO assez importante.
Il == langue intermédiaire, donc non.