Interface graphique pour visualiser le fonctionnement d'une architecture


Définition progressive de l'interface et décisions communes

Au cours de chaque réunion, des idées ou des décisions qui peuvent affecter tous les groupes peuvent émerger. Le but de cette section est de les résumer et les diffuser à tous les groupes. Prenez l'habitude de consulter cette page le lendemain de chaque réunion. Attention, je souhaite que les interfaces et les projets se distinguent les uns des autres; le but de cette section n'est pas d'homogénéiser les projets mais de les harmoniser sur des points essentiels.

Etapes

L'article décrivant l'interface utilisée pour le simulateur du processeur Alpha (outil propriétaire non diffusé et non vendu) donne une assez bonne idée de ce que l'on veut réaliser: on exécute instruction par instruction un programme sur un processeur et on veut faire apparaître tous les évènements qui donnent une information importante sur le comportement du programme sur l'architecture; il s'agit notamment de tous les évènements qui vont avoir un impact sur la performance: défauts de cache, défauts de prédiction de branchement... On veut pouvoir savoir quelle instruction du programme assembleur, voir du programme source, a causé ce problème.
  • Tout d'abord, même si le projet ne consiste pas à faire des architectures, il vous faut être familier avec la structure d'un processeur tel que vu en Licence, et pour certains, en option de Maîtrise. La structure d'un processeur pipeliné simple, tel que le processeur exemple DLX décrit dans le livre de Hennessy et Patterson, est décrite dans votre poly de Licence. Il est également recommandé de se familiariser avec la structure des processeurs actuels, tels que le P4 d'Intel ou l'Alpha de Compaq. Un très bon article de synthèse a été écrit sur le sujet.
  • Les données à afficher se présentent sous la forme d'une trace en XML. Outre cette trace, le programme assembleur est fourni en XML également. Cette trace indique tous les évènements qui se sont produits et le PC de l'instruction assembleur qui en est responsable. La première étape consiste à parser le code XML pour pouvoir visualiser les informations contenues. Il est important de prendre en compte que la structure XML de la trace comme du programme va évoluer. Il est donc impératif de concevoir le parser en ayant cette contrainte d'évolution à l'esprit.
  • Dans un deuxième temps, on pourra commencer la conception de l'interface graphique. Le but principal de l'interface est de représenter la trace sous forme de chronogramme; par exemple, dans l'interface utilisée pour l'Alpha, le temps est représenté horizontalement, et verticalement, on représente les différentes étages du pipeline (les différents composants de l'architecture). Un évènement classique (exécution d'une instruction) ou anormal (défaut de cache) est représenté par des carrés de différentes couleurs. En outre, une fenêtre contenant le code reprend cette nomenclature pour décrire les évènements par instruction: le temps est toujours représenté horizontalement, et en regarde de chaque instruction, on voit les évènements qu'elle a provoqués.
    Cet exemple est destiné à vous donner des idées d'interface: vous pouvez le reproduire, ou proposer une interface différente.
    Dans tous les cas, un point très important est de prendre en compte le fait que l'interface graphique sera amenée à évoluer, la qualité de la programmation (modularité, clarté, facilité de réutilisation) aura donc beaucoup d'influence dans l'évaluation du travail.
  • Pour l'environnement graphique de programmation, vous avez plusieurs possibilités: soit utiliser la librairie graphique de Java, soit utiliser Qt sous Linux/Windows (moins portable mais plus rapide), ou encore créer votre interface au sein d'une applet, dans le but de visualiser à distance le résultat d'une simulation. Ce dernier cas peut être intéressant dans le cas d'un serveur de simulation utilisé par plusieurs chercheurs distants et qui veulent observer le résultat de leurs simulations; il faudra alors traiter la partie communication entre le serveur et le client, par exemple en Java.

    Fonctionnement du TER

  • Vous pouvez réaliser le TER en binôme.
  • Vous aurez beaucoup d'autonomie dans les choix de réalisation, mais le travail sera suivi chaque semaine sous la forme d'un rendez-vous hebdomadaire, d'une quinzaine de minutes environ, pour chaque binôme.

    Description

    La conception d'architectures dans l'industrie ou la recherche académique repose l'utilisation de simulateurs. Ce sont des logiciels décrivant en détail le fonctionnement de chacun des composants d'un processeur ou d'un système. En raison du nombre croissant de transistors (42 millions dans le Pentium IV), ces architectures deviennent très complexes, et il devient difficile d'en appréhender le fonctionnement, ce qui en freine le développement. En outre, il devient de plus en plus difficile de comprendre le comportement d'un programme sur une architecture et donc d'en optimiser la performance.

    Nous voulons développer une interface de visualisation d'architectures qui permettra de montrer de façon intuitive l'exécution de programmes sur le simulateur d'un processeur ou un système. Ce projet est couplé à un projet de recherche de l'équipe Architecture du LRI dont le but est de proposer une méthode modulaire de conception des simulateurs d'architecture: chaque simulateur est scindé en "boîtes" qui correspondent chacune à un composant de l'architecture (mémoire, unité fonctionnelle, cache...). Cette méthode modulaire de conception se prête bien à la visualisation: on peut spécifier indépendamment, au sein de chaque boîte, les éléments de l'architecture (structures de données) à visualiser. La liaison entre le simulateur modulaire et la visualisation se fera par le biais de XML: chaque boîte générera des informations au format XML qui seront interprétées puis affichées par l'interface graphique.

    Le propos du TER est de réaliser la visualisation graphique à partir des sorties XML; il n'est donc pas demandé de travailler sur les simulateurs d'architectures, mais la façon de visualiser les informations exploite largement les connaissances acquises pendant le cours d'architecture. Dans le cadre du TER, il faudra donc extraire les informations contenues dans les sorties XML, puis les afficher, notamment sous forme de chronogramme. De façon optionnelle, on pourra également réfléchir à un affichage des composants de l'architecture et des transferts d'information entre ces composants. La qualité de programmation est un point très important du TER: plutôt que le nombre de fonctionnalités, on privilégiera la capacité à implémenter de nouvelles fonctionnalités dans le futur, au fur et à mesure des besoins. Il faudra donc réfléchir à la façon dont l'interface pourrait évoluer.

    Cette interface est destinée à être réellement utilisée en recherche en architecture: dans l'équipe du LRI dans un premier temps, mais elle sera également diffusée auprès d'autres groupes de recherche. Parmi les interfaces développées dans le cadre du TER et qui correspondent au cahier des charges fixé, nous retiendrons la meilleure interface qui servira de base à de futurs développements et qui sera diffusée comme indiquée ci-dessus.

    Bibliographie

    Environnement

    Enseignant(s)

    Olivier Temam
    Email : temam@lri.fr

    ue -'); //-->