2  Comment ça se passe

D’abord, je vous recommande de travailler sous Linux, et plus spécifiquement (à Cachan) sur les machines de la salle C411. Il vous faut un Linux 32 bits, ou 64 bits depuis l’année 2013 (merci à Lucca Hirschi).

Si vous voulez travailler chez vous, et que votre machine est sous Windows, ou Mac OS, je vous recommande de travailler sous VirtualBox: voir en section 8 pour les détails pratiques.

Le projet sera écrit en OCaml. Toutes les versions de Caml ou OCaml ≥ 2.04 devraient faire l’affaire.

Ensuite, vous devez récupérer l’archive du projet. Décompressez-là avec bzip2 et désarchivez le tout avec tar (ou avec 7zip sous Windows; sur MacOSX, double-cliquez). Vous pouvez faire le tout en une seule étape en tapant tar xvjf projetminic.tbz.

Vous devriez obtenir un répertoire MiniC et les fichiers suivants:

Votre travail consiste à écrire le fichier manquant compile.ml. Vous pouvez y écrire ce que vous voulez, l’important est de définir la fonction dont le type est spécifié dans le fichier d’interface compile.mli:

val compile : out_channel -> Cparse.var_declaration list -> unit;;

Cette fonction prend un canal de sortie en premier argument, appelons-le out, et un programme C--, appelons-le π, et imprime sur out un texte en assembleur x86 qui code le programme π. Ce texte en assembleur ressemblera donc au texte de l’introduction (voir le fichier cat.s).

Lorsque vous aurez écrit le fichier compile.mli, compilez le tout en invoquant make. Comme vous l’aura sûrement expliqué Sébastien, ceci va appliquer un certain nombre de commandes dans un ordre défini par les dépendances exprimées dans le fichier Makefile.

Le résultat sera un programme, qui s’appellera mcc et sera dans le répertoire ProjetMiniC. Vous pourrez tester ce programme en tapant ./mcc suivi du nom d’un fichier C-- à compiler.

Par exemple, si vous tapez (en partant du répertoire ProjetMiniC):

Ceci devrait produire un fichier assembleur cat.s, que vous pourrez consulter, et un fichier exécutable cat, que vous pourrez tester en tapant (sous le répertoire ProjetMiniC/Exemples):

Il est évidemment plus que probable que le code assembleur que vous produisiez, au moins au début, ne soit pas de la meilleure qualité. Notamment, mcc appelle le compilateur gcc pour compiler le code assembleur que vous aurez produit vers un vrai exécutable. Si votre code assembleur n’est pas syntaxiquement correct, ceci échouera. Il se peut aussi que vous obteniez un exécutable, mais qu’il plante (message Segmentation fault, typiquement).

Dans tous les cas, vous pouvez:

• Limiter mcc à ne produire que le code assembleur, sans le compiler. Appelez-le avec l’option -E:

  ../mcc -E cat.c

  Ceci affichera le code que votre fonction compile produit. Vous pouvez envoyer ce code dans un fichier, disons cat.s encore une fois, par:

  ../mcc -E cat.c >cat.s

• Ou bien, et ceci si votre exécutable plante, utiliser le débogueur graphique ddd. Si vous ne l’avez pas, rabattez-vous sur xxgdb, ou dans le pire des cas sur gdb. Utilisez les commandes
  • Menu “Data”, item “Status Displays...”, cliquez sur “List of integer registers and their contents” (pas “List of all registers...”!), puis “Close” sous ddd pour voir le contenu des registres de la machine. Sous gdb, tapez info registers pour le même effet (en moins beau).
  • Menu “Data”, item “Memory...”, tapez sur disons 32 dans la case “View”, puis cochez “hex”, “words”, et l’adresse mémoire à laquelle vous voulez regardez dans la case “from”. Par exemple, si %esp vaut 0xbffff8e0, tapez 0xbffff8d0 dans le champ “from” pour voir un peu de part et d’autre de 0xbffff8e0. Sous gdb, vous obtiendrez le même effet (en moins beau) avec l’incantation:
    x/32xw 0xbffff8d0