c'est pas la première fois que je te surprend à dire une connerie, et en proférant souvent moi aussi, je décèle chez toi une certaine incompréhension sur la compilation et sa théorie.
Oui oui.
Il y a machine virtuelle et machine virtuelle. Dans le cas qui nous préoccupe ici, Java et Mono, il s'agit d'une "vraie" machine virtuelle. C'est à dire que nous avons un programme, qui lit un espèce d'assembleur (à pile... j'en entend certain rigoler) et dispose de quelques primitives.
Non, il n'y a pas "machine virtuelle et machine virtuelle". Il y a le concept de machine virtuelle, point. Par contre on va parler d'environnement d'exécution virtuel. Le fameux VES de la CLI de .net. L'espèce d'assembleur ça s'appelle du code intermédiaire, et c'est un point commun à toutes les machines virtuelles. Dans la théorie qui t'es chère on attache à une machine virtuelle un langage, et on empile ces machines virtuelles. Pour Mono, le langage c'est donc du CIL.
Donc dans ce sens, le commentaire auquel tu réponds n'a pas tout à fait tord. En créant une représentation abstraite sous la forme d'un langage particulier (le fameux RTL) pour les machines basées sur des registres, gcc devient donc l'hôte d'une machine virtuelle.
C'est d'ailleurs ce qui permet de faire de la cross-compilation si je ne m'abuse.
Donc, même si le pseudo compilateur java produit un pseudo assembleur, il faut le traduire cet assembleur, surtout qu'il est d'assez haut niveau. Ca prend du temps, tout ça.
Tout à fait. Ça prend du temps, ce que quelqu'un a appellé ici "le temps de chauffe".
Un programme compilé n'a pas ce problème, l'assembleur est là, prêt à être exécuté.
Modulo les relocations, tout à fait. Mais c'est oublié tous les avantages que fournissent les environnements modernes.
Je pense que le futur est à une synthèse entre les deux, ou plutôt à une intégration de concepts issu de l'interprétation dans la compilation : On peut imaginer un langage dans lequel on spécifie les intervales de définition les plus probables, où l'analse de flot détecterait des fonctions souvent rappelées et peu susceptibles de donner des résultats changeant en squeezant les appels et les remplaçant par des tables de hash. OU encore, mais ça me plait moins, d'entraîner le code sur des données et de recompiler sur des statistiques (Intel le fait).
Là on entre dans le moi je.
Concernant la synthèse issu de l'interprétation, je n'y crois pas. On n'interprète plus vraiment quoi que ce soit. Même la JVM qui pouvait balancer entre l'interprétation et la JIT compilation ne fait maintenant presque plus que de la compilation.
Cela dit, je pense qu'on tend vers quelque chose d'encore plus dynamique. Mais encore plus dynamique que ce qu'on a dans nos environnement d'exécution. Il y a des travaux sur les JITs pour pouvoir instrumenter le code assembleur émit pour pouvoir le regénérer en optimisant les portions les plus utilisées. Mais on va mettre ça dans les environnements d'exécution, et pas dans les langages. Sinon ça va devenir encore un langage que personne n'utilisera, un de plus.
Bref une belle thèse de doctorat (s'il y a des étudiants en Master 2 ou 1 prometeur dans la salle, contactez moi, je ferai passer) en perspective.
Oh moi ces trucs là j'ai arrêté à cause de la théorie que tu nous tartines.
[^] # Re: Le passage Mono dans le document
Posté par Jb Evain . En réponse au journal Mono et Gnome. Évalué à 4.
Oui oui.
Non, il n'y a pas "machine virtuelle et machine virtuelle". Il y a le concept de machine virtuelle, point. Par contre on va parler d'environnement d'exécution virtuel. Le fameux VES de la CLI de .net. L'espèce d'assembleur ça s'appelle du code intermédiaire, et c'est un point commun à toutes les machines virtuelles. Dans la théorie qui t'es chère on attache à une machine virtuelle un langage, et on empile ces machines virtuelles. Pour Mono, le langage c'est donc du CIL.
Donc dans ce sens, le commentaire auquel tu réponds n'a pas tout à fait tord. En créant une représentation abstraite sous la forme d'un langage particulier (le fameux RTL) pour les machines basées sur des registres, gcc devient donc l'hôte d'une machine virtuelle.
C'est d'ailleurs ce qui permet de faire de la cross-compilation si je ne m'abuse.
Tout à fait. Ça prend du temps, ce que quelqu'un a appellé ici "le temps de chauffe".
Modulo les relocations, tout à fait. Mais c'est oublié tous les avantages que fournissent les environnements modernes.
Là on entre dans le moi je.
Concernant la synthèse issu de l'interprétation, je n'y crois pas. On n'interprète plus vraiment quoi que ce soit. Même la JVM qui pouvait balancer entre l'interprétation et la JIT compilation ne fait maintenant presque plus que de la compilation.
Cela dit, je pense qu'on tend vers quelque chose d'encore plus dynamique. Mais encore plus dynamique que ce qu'on a dans nos environnement d'exécution. Il y a des travaux sur les JITs pour pouvoir instrumenter le code assembleur émit pour pouvoir le regénérer en optimisant les portions les plus utilisées. Mais on va mettre ça dans les environnements d'exécution, et pas dans les langages. Sinon ça va devenir encore un langage que personne n'utilisera, un de plus.
Oh moi ces trucs là j'ai arrêté à cause de la théorie que tu nous tartines.