compilateur, interpréteur, bytecode, MSIL et code natif

Bonjour, :D

je suis en train de lire le cours de C# de Rm di Scala et j'ai quelques difficultés à comprendre certaines notions: 8O:roll:

je mets ce que j'ai compris:

compilateur : il traduit le programme source en programme cible,ce qui permet au processeur d'exécuter ce programme cible en une seule fois.

interpréteur : traduit une instruction du programme source, aussitôt exécutée par le processeur, puis nouvelle traduction de l'instruction suivante, ensuite exécutée par le processeur, et ainsi de suite...

p-machine : ???

bytecode : code cible après compilation ou interprétation;

MSIL : bytecode avant la prise en charge par le CLR

code natif : bytecode après prise en charge par le CLR
c'est le même que MSIL sauf qu'il est exéuté par le processeur sous le controle du CLR

Merci de me corriger et de m'apporter des précisions... :D

Bonjour Cyrano,

je vais essayer de te donner les definitions dans le contexte du cours de Mr Di Scala (je n'ai pas la toute derniere version mais ca devrait etre ca).

Un compilateur traduit un langage X en un langage Y. Le langage Y peut soit directement utilisé par la machine dans le cas d'un compilateur de langage machine (dans le cas des langages n'ayant pas besoin de machine virtuelle pour fonctionner (le C ou le C++ par exemple)), soit en un langage tiers qui sera reconnu par une machine virtuel (on y reviendra).

Pour l'interpreteur, tu as l'idée, ca ne produit rien (en terme de source ou de programme) mais ca lit et interprete au fur et à mesure les instructions qu'on lui donne.

Une p-machine dans ce cours, c'est un synonyme de machine virtuelle, en gros elle sert d'interface entre le materiel concret et le programme permettant de faire abstraction de la machine sous-jacente. Cette machine virtuelle sait reconnaitre et interpreter dans le langage de la machine surlaquelle elle se trouve un langage specifique (l'IL dans le cas de .Net). Un des gros avantage, est que de fait, tu n'as plus à te preoccuper de compiler ton programme pour plusieurs plateformes, c'est à la machine virtuelle d'etre concue specifiquement pour chaque plateforme. Ce phenomene est ce que tu pourras trouver denommé comme portabilité binaire.

Pour l'IL (ou MSIL chez Microsoft ou encore plus generalement CIL) (Intermediate Language), c'est en fait le bytecode de .Net. C'est le langage compris par l'interpreteur .Net et c'est le resultat de la compilation d'un programme ecrit en C#, VB.Net ou autre. En fait, un exe produit avec un compilateur C# (par exemple), est un fichier comportant des informations et du code sous forme d'IL (donc pas du code natif comme pour d'autres compilateur), cet IL sera lu et compris par la machine virtuelle et traduite en code machine (specifique à la plate forme).

Enfin le code natif, c'est le code que comprend ta machine (concrete).

Pour te donner une idée plus precise sur comment ca marche sur C#, voici un exemple simple, prenons une source :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

using System;   namespace ConsoleApplication1 { class Program { static void Main() { Console.WriteLine("Salut Cyrano !"); } } }

---

la finalité de ce programme est d'afficher "Salut Cyrano !" sur la console et se terminer. Ici c'est ecrit en C#. Quand je vais compiler ce programme avec mon IDE (je vais invoquer le compilateur C# à savoir csc.exe), il va me donner en sortie un fichier .exe. Ce dernier contiendra des informations sur mon programme (les classes presentes, les references necessaires, enfin bref pleins d'infos quant à son fonctionnement), et aussi un code de ce type :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

.class private auto ansi beforefieldinit Program extends [mscorlib]System.Object { .method public hidebysig specialname rtspecialname instance void .ctor() cil managed { .maxstack 8 L_0000: ldarg.0 L_0001: call instance void [mscorlib]System.Object::.ctor() L_0006: ret }   .method private hidebysig static void Main() cil managed { .entrypoint .maxstack 8 L_0000: nop L_0001: ldstr "Salut Cyrano !" L_0006: call void [mscorlib]System.Console::WriteLine(string) L_000b: nop L_000c: ret }   }

---

Ce que tu vois au dessus est le resultat de la compilation de la source plus haut en langage intermediaire (ou bytecode .Net ou IL). Comme tu peux le constater ce langage et bien moins 'human-readable' que le C# (ou un autre langage haut niveau de .Net), mais c'est ce dernier qui est compris par la machine virtuelle de .Net (la CLR). La finalité de ce langage (du moins une de ces finalités) est que quelque soit la plateforme surlaquelle tu te trouves, ce code pourra etre interpreté correctement si il existe une machine virtuelle .Net pour la machine et ce sans recompilation (d'ou "portabilité binaire").

Quand tu va executer ce programme, la CLR va verifier le code IL (detail technique, on ne s'y attardera pas), et compiler au dernier moment le code IL necessaire à l'execution en langage machine specifique à la plateforme. Cette compilation "tardive" est faite par le compilateur JIT (Just-In-Time) au moment de l'execution et au fur et à mesure des methodes appelées.

Pour aller plus loin dans l'execution des programmes managés, tu as cette page de la MSDN pas trop mal faite.

En esperant avoir été clair, et ne pas t'avoir trop embrouillé. Bon courage. =)

merci SirJulio d'avoir pris le temps de me répondre... :D


si je comprends bien, dans le cas du c# :
code source c# --compilatateur--> bytecode .NET --interpréteur--> bytecode exécutable

et j'ai juste besoin du bytecode .NET pour exécuter ce programme sur une autre machine, à condition que cette machine ait un interpréteur .NET...

2 nouvelles questions :
1) le compilateur et l'interpréteur sont-ils tous les 2 compris dans le CLR? (en tout cas dans le framework .NET)
2) est ce le processeur de la machine réelle qui exécute ce bytecode exécutable? si non le processeur de la machine virtuelle (qui a fait l'interprétation)? dans ce cas, le processeur de la machine réelle ne sert-il plus à rien?


merci encore :D

My pleasure !

dans ton schema, l'etape 4 ce n'est pas ca. On ne parle pas d'interpretation du code IL mais bien de compilation ("JIT compiler"). Et ce qui sort de cette compilation juste-à-temps n'est plus un bytecode mais un code machine specifique pour la machine. Pour reprendre ton schema, cela devient :

Source C# -> compilateur (csc.exe) -> Bytecode IL -> compilateur JIT -> code machine.

En tres gros, la CLR va au fur et à mesure de l'execution du programme compilé les blocs de code IL dont elle a besoin en code machine. C'est bien une compilateur et pas un "interprete" instruction par instruction.

Pour le reste, c'est ca, si tu as une machine virtuelle sur un ordinateur (qui correspond au norme de l'IL toussa), tu peux y executer un programme .Net, par exemple le programme ci dessus, une fois compilé (donc une fois l'exe produit) je peux l'executer sur windows (normal) et sur Linux (avec mono le port de .Net sur linux) sans recompiler mon programme. C'est la machine virtuelle qui s'occupera de fournir un code specifique, pas mon programme.

Pour les autres questions :

-Oui les deux sont compris.

-En fait, la machine virtuelle sert d'interface entre le programme et la machine sous-jacente (materielle), donc le processeur sert toujours (comment pourrait il en etre autrement).

yes merci je comprends de mieux en mieux :D

par contre j'aimerai encore savoir quelque chose :

csc.exe est compris dans le CLR ou à un niveau au dessus dans le framework .NET?

quand on veut exécuter le programme, le CLR compile le code .NET grâce au compilateur JIT, pour ensuite demander au processeur de l'exécuter...

si c'est bien ça, il ne me reste plus qu'à te remercier pour tes explications, et le temps que tu as pris pour ça, et à mettre le topic en résolu ! :D

et je continue le cours...

Citation:

---

Envoyé par cyrano_de_bergerac

yes merci je comprends de mieux en mieux :D

par contre j'aimerai encore savoir quelque chose :

csc.exe est compris dans le CLR ou à un niveau au dessus dans le framework .NET?

quand on veut exécuter le programme, le CLR compile le code .NET grâce au compilateur JIT, pour ensuite demander au processeur de l'exécuter...

si c'est bien ça, il ne me reste plus qu'à te remercier pour tes explications, et le temps que tu as pris pour ça, et à mettre le topic en résolu ! :D

et je continue le cours...

---

Le compilateur csc.exe n'est pas contenu dans le CLR à proprement parler car c'est un compilateur C# vers CIL. Le seul compilateur intégré dans le CLR est le compilateur CLI -> Code machine, (JIT signifiant Just In Time).

Pour ta deuxième question, c'est effectivement ce qui se passe, les méthodes appelées sont compilées lors de leur première utilisation.

Allez hop j'apporte mon grain de sel. :mrgreen:
Juste pour dire que la compilation just in time est énorme, car si je ne me trompe pas, les "bloques" d'IL compilé en code machine ne sont pas recompilés si ce n'est pas nécessaire.
Tu va me dire c pas très récent, un prog c compilé par un compilo c en exe n'est jamais recompilé tout seul.
mais c'est là que le compilo .net de il vers code machine est énorme, il offre à la fois cette invariabilité pour éviter que l'application soit lente au démarrage, et il permet la recompilation automatique et autogéré qui peut être nécessaire sur une machine.

Ce comportement est surtout utile pour les applications serveur faite en .Net
A la première connexion au serveur, super long car on compile plein de chose, et après pour n'importe qui c'est super rapide car plus de compilation. Alors que l'on fonctionne dans un mode d'autocompilation autogérée.

N'hesitez pas à me corriger si j'ai dit n'importe koi, ou si je n'ai pas été assez clair.

merci à tous les 2 même si j'ai du mal à comprendre ced600 :king:

puisque csc.exe ne se trouve pas dans le CLR alors où se trouve t'il? je suppose qu'il est quand même bien présent dans l'architecture du framework .NET ?

Citation:

---

Envoyé par ced600

N'hesitez pas à me corriger si j'ai dit n'importe koi, ou si je n'ai pas été assez clair.

---

Non non ca ira : le compilo JIT compil en natif lors de la premiere exécution, et conserve en cache ce code pour les exécutions suivantes...
Mais en fait ca va plus loin (si j'ai moi meme tout parfaitement compris) : il compile tout ce qui est utilisé en premier, et ensuite distingue sur ce qui n'a pas été utilisé, ce qui le sera le plus souvent, et lui inflige le meme traitement... jusqu'à avoir tout passé en revu...

Citation:

---

Envoyé par ced600

Allez hop j'apporte mon grain de sel. :mrgreen:
Juste pour dire que la compilation just in time est énorme, car si je ne me trompe pas, les "bloques" d'IL compilé en code machine ne sont pas recompilés si ce n'est pas nécessaire.
Tu va me dire c pas très récent, un prog c compilé par un compilo c en exe n'est jamais recompilé tout seul.
mais c'est là que le compilo .net de il vers code machine est énorme, il offre à la fois cette invariabilité pour éviter que l'application soit lente au démarrage, et il permet la recompilation automatique et autogéré qui peut être nécessaire sur une machine.

Ce comportement est surtout utile pour les applications serveur faite en .Net
A la première connexion au serveur, super long car on compile plein de chose, et après pour n'importe qui c'est super rapide car plus de compilation. Alors que l'on fonctionne dans un mode d'autocompilation autogérée.

N'hesitez pas à me corriger si j'ai dit n'importe koi, ou si je n'ai pas été assez clair.

---

Totalement, de plus c'est ce compilateur (JIT) qui va assurer pas mal d'optimisation de contexte (Inlining, Forcage à null de variables locales de type ref). Le desavantage de ca, c'est que, surtout de grosses applications, peuvent etre plutot lente à demarrer (si on doit JITer enormement de methode au demarrage).

edit :

@Cyrano :

csc.exe se situe dans le framework (mais comme dit au dessus, n'est pas a proprement parler un composant de la CLR, ce n'est pas un outil d'execution). D'ailleurs, c'est pour ca, qu'on peut faire de la compilation au runtime (compiler sur la machine utilisatrice un code C# pour en faire un assembly).

ok merci beaucoup pour votre aide, en particulier SirJulio... :D

Bah j'ai l'impression que SirJulio connais le .Net sur le bout de ses doigts, alors chacune de ses interventions, concises et claires, apportent beaucoup d'élément de réponses à ce qui se posent des questions sur le .Net donc :king: