La compilation de codee source vers du code octet combiné avec l'utilisation d'une machine virtuelle ou d'un interpréteur pour l'exécuter est devenue une pratique courante qui permet de conserver une indépendance face à la plateforme matérielle. Les interpréteurs sont portables et offrent une simplicité de développement qui en font un choix intéressant pour la conception de prototypes de nouveaux langages de programmation. L'optimisation des techniques d'interprétation existantes est un sujet de recherche qui nous intéresse particulièrement. Nous avons voulu, par l'entremise de notre projet de recherche, étudier jusqu'où il est possible de pousser l'optimisation dans un interpréteur. Après avoir étudié les types d'interpréteurs existants, nous avons constaté que les interpréteurs les plus performants se basent tous sur le même principe: La réduction du coût associé aux répartitions entre les instructions interprétées. Ce coût est causé par les instructions de répartitions elles-mêmes, mais surtout par l'augmentation du taux d'erreur qu'elles procurent dans les prédicteurs de branchement qui se trouvent au sein des processeurs modernes. Des mauvaises prédictions de branchements occasionnent des coûts importants sur une architecture pipelinée. L'interpréteur linéaire inclusif est un des plus performants qui existe. En nous basant sur cet interpréteur, nous avons fait la conception et l'implémentation d'un mécanisme qui lui permet d'augmenter la longueur des ses super-instructions et par le fait même de diminuer le nombre de répartitions pendant l'exécution. Nous avons mis au point un mécanisme dynamique d'inclusion partielle des méthodes dans cet interpréteur. Nous avons aussi conçu un système de profilage qui nous permet de détecter les sites d'invocations chauds et d'y effectuer l'inclusion du chemin le plus fréquenté de la méthode appelée. En brisant ainsi la frontière entre le corps des méthodes, nous parvenons à augmenter la longueur moyenne des super-instructions. Nous avons surmonté et résolu toutes les difficultés inhérentes à l'implémentation d'un tel système dans une véritable machine virtuelle Java (synchronisation, exceptions, présence d'un nettoyeur de mémoire, présence de sous routines dans le code octet Java). Nous fournissons une étude empirique de l'impact de notre système sur un interpréteur linéaire inclusif en exécutant des applications Java d'envergure. Dans tous les cas étudiés, on arrive à augmenter la longueur moyenne des super-instructions invoquées et à diminuer le nombre de répartitions pendant l'exécution. ______________________________________________________________________________ MOTS-CLÉS DE L’AUTEUR : Interpréteur, Inclusion, Inclusion partielle, Profilage, Machine virtuelle, Java, JVM, SableVM.

SableCC est un générateur de compilateurs. Il permet de construire des analyseurs lexicaux, des analyseurs syntaxiques et des arbres syntaxiques. Il est toutefois limité à la génération de code en langage Java. Dans ce mémoire, nous présentons un outil qui s'intègre à SableCC et qui permet à celui-ci une génération de code dans d'autres langages orientés objets. La méthode que nous proposons pour permettre la génération de code dans un autre langage consiste à construire des scripts et des patrons pour chaque nouveau langage. La rédaction des scripts se fait dans le langage Hiber, un langage que nous avons conçu pour faciliter la tâche de décrire les règles de génération de code. Les scripts sont interprétés par un interpréteur construit avec SableCC. Cet interpréteur reçoit de SableCC une structure de données qui est accessible à partir de scripts. Le principe original de SableCC pour la génération de code est donc conservé. Pour vérifier le bon fonctionnement de l'interpréteur et de la structure de données, nous avons effectué la génération en Java avec notre méthode et nous avons comparé le code généré avec celui de la version originale de SableCC. Par la suite, nous avons ajouté la génération en C++. C'est un langage ayant des similitudes avec Java. Cet exercice nous a permis de raffiner l'interpréteur et la structure de données. Dans le but de démontrer une plus grande maturité de la génération, un troisième langage est ajouté: Python. Ce langage est très différent des deux derniers, ce qui démontre l'adéquation de notre méthode de génération pour les langages orientés objets. La méthode de génération proposée permet de bien séparer les modèles de génération, les règles de génération et la structure de données. Elle rend possible l'ajout d'un nouveau langage destination en écrivant un script qui est peu volumineux, facile à lire et à maintenir. ______________________________________________________________________________ MOTS-CLÉS DE L’AUTEUR : Générateur de compilateur, Interpréteur, Structure de données, Hiber, Script.