La gestion des parties hautes et basses des registres

La gestion des parties hautes et basses des registres

 Analyse de l’existant

 L’interface

La première approche que nous avons eue avec l’application réalisée par Fréderic Baulieu et Yan Le Cam est bien sûr l’interface graphique. Nous avons en effet pris un peu de temps pour tester l’application avant de tenter de la modifier pour nous rendre compte par nous-mêmes de son fonctionnement ainsi que des points que nous allions avoir à modifier.
Au lancement de l’application, on observe sept fenêtres ayant chacune un contenu précis. Ces fenêtres sont indépendantes en terme de position, elle sont bien réparties sur l’écran au démarrage, avec la possibilité de choisir de n’afficher que certaines d’entre-elles, grâce au menu affichage.

Le logiciel est donc composé à son lancement de 7 partie distinctes : en haut, la barre de menu, à droite, la fenêtre contenant les variables normales, la fenêtre contenant les tableaux et celle contenant les registres et les flags, au centre nous avons le code source et enfin a droite, les entrées/sorties et la pile.
Les informations sont relativement bien réparties, nous allons tenter de garder une disposition similaire. Mais nous allons devoir modifier cette interface et y ajouter certaines parties.

Les fonctionnalités

les caractéristiques

Avant de nous lancer dans la modification du projet effectué par nos prédécesseurs, nous avons dû nous pencher sérieusement sur la compréhension du travail qui avait déjà été effectué, sans quoi nous aurions perdu notre temps à modifier sans succès les fichiers qui le constituent.
Après le test du logiciel et la lecture du rapport de stage correspondant à ce projet, nous avons pu déterminer précisément les caractéristiques générales de l’émulateur. Premier point important, le programme gère uniquement une taille de seize bits, non signé.

C’est à dire que pour qu’un programme soit lisible pour l’émulateur, chaque variable ou élément de tableau doit être déclarée comme étant un mot (DW) ce qui autorise des valeurs allant de 0 à 65535. Nous voyons ici le premier point à améliorer.
Pour ce qui est de l’émulation du matériel, le processeur possède 7 registres, 4 registres de données (AX,BX,CX,DX), 2 registres pointeurs de pile (BP et SP) et 1 pointeur d’instruction (IP). Tous ces registres ont une taille de 16 bits et il est encore impossible de manipuler séparément les parties hautes et basses des registres de données. Voilà un second point sur lequel il a été nécessaire de nous pencher.
L’émulateur gère 4 flags :
– ZF : il est mis à 1 lorsque le résultat d’une opération vaut 0
– CF : il est mis à 1 lorsque le calcul comporte une retenue
– OF : il est mis à 1 s’il y a eu un débordement arithmétique (par exemple lors d’une addition)
– SF : il est mis à 1 lorsque le résultat d’une opération est négatif
Il existe d’autres flags qui n’ont pas été implémenté initialement car ils n’intervenaient pas dans les instructions supportées par l’émulateur. Nous ne modifierons donc pas cette partie, les seules instructions que nous allons ajouter n’auront pas effet sur d’autres flags que ceux implémentés ici.
En ce qui concerne la mémoire, elle n’est pas gérée strictement comme le ferait un processeur de type 8086. Emul8086 sert à comprendre et déboguer un programme écrit dans un langage proche de l’assembleur, la gestion interne de la mémoire importe peu ici. Nous allons être amenés à modifier les méthodes concernant cette partie de l’application pour notre projet, nous garderons cependant le même principe de gestion.

la structure d’un programme

Comme indiqué dans le rapport de projet, les programmes chargés par l’émulateur seront sous forme de fichiers texte, comportant deux section DATA et CODE, mots clé qui devront être dans cet ordre.

 Les modifications apportées

Le but de notre stage était donc d’apporter des modifications et des améliorations à ce logiciel. Nous allons vous présenter les différents points sur lesquels nous avons effectué des changements, que ce soit au niveau de l’interface ou au niveau du cœur de l’application.

Interface

La première modification, la plus visible au premier abord, est l’amélioration de l’interface graphique. Comme nous l’avons vu dans la partie « Analyse de l’existant », le logiciel original se composait de 7 fenêtres séparées. Au lancement du programme, cela ne gênait en rien : les fenêtres étaient automatiquement placées d’une façon plutôt fonctionnelle.
Cependant, cette indépendance des fenêtres se révèle vite être un défaut à l’utilisation. Dès que l’on commence à les déplacer, on se retrouve vite avec une interface peu pratique et des fenêtres qui se superposent.
C’est pourquoi nous avons commencé par modifier cette interface pour rassembler toutes les fenêtres en une seule.
Nous avons donc modifié la relation d’héritage pour que JEmu8086Dialog hérite de JPanel et Jemul8086Frame de JFrame, puis ensuite modifié en conséquence tous les appels de méthodes spécifiques à JPanel. Ce changement semble au final assez logique, les deux étant des conteneurs.
Cette première modification effectuée, nous avons dû ajouter un gestionnaire de mise en page (GridBagLayout) à la fenêtre principale (représentée par la classe TFenPrinc) afin d’y ajouter nos nouveaux éléments de façon à respecter au mieux une disposition proche de ce que proposait l’application originale.

 Gestion du 32 bits

Passage en 32 bits

Une autre grande modification apportée à ce logiciel est la gestion du 32 bits, mais aussi des parties hautes et basses des nouveaux registres généraux. Pour obtenir ce résultat nous avons commencé par faire une simple modification pour passer du 16 bits uniquement au 32 bits uniquement.
Cela a consisté principalement à changer le nom des registres aux différents endroits dans le logiciel (AX devient EAX) ainsi que modifier la plage de nombres acceptés (0 à 232-1 au lieu de 0 à 216-1). Nous avons ici été confrontés à une première difficulté liée à la gestion des types dans le langage JAVA. Pour le moment, chaque valeur était stockée dans un type int.
En Java, contrairement à certains langages comme le C, les types sont de tailles fixes, peut importe la machine sur laquelle le programme est exécuté. En l’occurrence, le type int de java est codé sur 32 bits dont un bit de signe. Nous ne pouvons donc pas stocker des nombres entiers positifs de 32 bits, il nous a fallu utiliser le type long, et faire les modifications nécessaires dans les différentes classes.

La gestion des parties hautes et basses des registres

La seconde partie du travail, la plus importante en terme de fonctionnalité des registres 32 bits, a consisté à pouvoir gérer séparément les parties hautes et basses des registres généraux ce qui permet d’ajouter de l’intérêt au logiciel en s’approchant un peu plus de l’utilisation réelle du langage assembleur.Pour cela nous avons choisi de ne pas modifier le diagramme de classe établi par les précédents développeurs, qui nous semblait être adapté tel qu’il était pour l’ajout de cette fonctionnalité. Nous avons donc ajouté et modifié les méthodes impliquées dans la traduction de la partie DATA en zones mémoires et de la traduction du programme en instruction lisibles par l’émulateur. Lors de l’analyse, on accepte maintenant les mots clés DD (double mot : 32bits) et DB (byte : 8 bits) en plus de DW (mot : 16 bits). Cette modification s’applique aussi bien aux variables classiques qu’aux tableaux, auquel cas cela indique la taille d’un élément du tableau.

SSE

Le SSE en quelques mots

L’une des modifications importantes que nous avons apportée au programme est la gestion de quelques instructions SSE (Streaming SIMD Extensions) « SSE est un jeu de 70 instructions supplémentaires pour microprocesseurs x86, apparu en 1999 sur le Pentium III en réponse au 3DNow! d’AMD apparu 1 an plus tôt. »
L’intérêt principal de ces instructions est le fonctionnement de type SIMD (Single Instruction on Multiple Data). Cela signifie que la même instruction est appliquée simultanément à plusieurs données pour produire plusieurs résultats.Le SSE a donc ajouté huit nouveaux registres de XMM0 à XMM7. Ce sont des registres 128 bits. Ils peuvent donc compacter ensemble par exemple 4 nombres flottants 32 bits simple précision (en utilisant le standard IEEE 754).

Notre représentation

L’un de nos buts lors du développement du projet était de réussir à insérer quelques unes de ces instructions SSE dans le programme. Cela nous obligeait à compléter le schéma des classes existant pour gérer des registres 128 bits. La difficulté étant de choisir comment représenter 128 bits sachant que le type le plus grand en java est le type « long » sur 64.

Gestion des erreurs

Avec le logiciel original, quand nous essayions de charger un programme qui comportait une erreur de syntaxe, le logiciel qui rencontrait donc une erreur à la traduction de ce programme semblait ne rien charger, et c’était dans la console que se trouvait la réponse à cette erreur. Nous avons donc pris le temps de gérer les exceptions provoquées par ces erreurs. Désormais, on obtient un message d’erreur lors du chargement d’un fichier qui comporte des erreurs. L’utilisateur sait maintenant le numéro de la ligne de la première erreur ainsi que son type quand il est connu (erreur de paramètre pour une instruction, variable non déclarée…)

Le nouveau diagramme de classes

Nous avons commenté le code et nous avons également tenu à le réorganiser avec les possibilités qu’offre le langage. Nous avons donc créé 3 paquetages et réparti les classes. Ces modifications font suite à la difficulté que nous avons eue à bien comprendre le code original, très peu commenté.

Table des matières

I – INTRODUCTION 
II – ANALYSE DE L’EXISTANT
1 – L’INTERFACE 
2 – LES FONCTIONNALITES
2.1 – les caractéristiques
2.2 – la structure d’un programme
3 – LE DIAGRAMME DE CLASSES 
4 – EXPLICATION DU FONCTIONNEMENT 
4.1 – les types
4.2 – Les flags
4.3 – La mémoire
4.4 – Instructions et paramètres
4.5 – Programme
III – LES MODIFICATIONS APPORTEES
1 – INTERFACE 
2 – GESTION DU 32 BITS
2.1 – Passage en 32 bits
2.2 – La gestion des parties hautes et basses des registres
3 – SSE
3.1 – Le SSE en quelques mots
3.2 – Notre représentation
3.3 – Les classes modélisant les données 128 bits
3.4 – Les instructions
3.5 – Exemple
3.6 – Conclusion de la partie SSE
4 – GESTION DES ERREURS
5 – LE NOUVEAU DIAGRAMME DE CLASSES 
IV – CONCLUSION 
BIBLIOGRAPHIE / SITOGRAPHIE

Télécharger le rapport complet