La VM est chargée d'exécuter alors que le compilateur produit du code autonome. Dans le code produit par le compilateur, rien n'empèche d'intégrer une sorte de profiler/optimiseur et ainsi choisir d'inliner certaines fonctions/boucles de la même manière qu'une bonne VM. Ca peut paraître compliqué, mais si une VM peut le faire, un compilo aussi.
Pour en revenir à la spécialisation de code, il y a un exemple assez intéressant qui faisait partie des tests: prenons la fonction int interpreter(char* bytecode, int size), chargée d'interpréter du bytecode Java. Le test consistait à spécialiser cette fonction en donnant au spécialiseur le bytecode... résultat, on obtenait une fonction sans paramètre qui n'était autre qu'une version compilée du bytecode!! Grace à ce projet, il suffit donc d'écrire l'interpréteur d'un langage pour obtenir en quelques commandes un compilateur pour ce même langage :-) C'est-y pas beau.
[^] # Re: Oui, mais...
Posté par pas_moi . En réponse à la dépêche Miguel DeIcaza et .NET. Évalué à 2.
La VM est chargée d'exécuter alors que le compilateur produit du code autonome. Dans le code produit par le compilateur, rien n'empèche d'intégrer une sorte de profiler/optimiseur et ainsi choisir d'inliner certaines fonctions/boucles de la même manière qu'une bonne VM. Ca peut paraître compliqué, mais si une VM peut le faire, un compilo aussi.
Pour en revenir à la spécialisation de code, il y a un exemple assez intéressant qui faisait partie des tests: prenons la fonction int interpreter(char* bytecode, int size), chargée d'interpréter du bytecode Java. Le test consistait à spécialiser cette fonction en donnant au spécialiseur le bytecode... résultat, on obtenait une fonction sans paramètre qui n'était autre qu'une version compilée du bytecode!! Grace à ce projet, il suffit donc d'écrire l'interpréteur d'un langage pour obtenir en quelques commandes un compilateur pour ce même langage :-) C'est-y pas beau.