Mini-compilateur C 1 Arbre de syntaxe abstraite 2 Types et ... - LRI

Master M1 2012–2013 Projet de programmation
Mini-compilateur C
analyse sémantique
à rendre avant le lundi 5 Novembre 2012, 17h00
1 Arbre de syntaxe abstraite
Dans l’arbre de syntaxe abstraite du corrigé de la première partie, les expressions
e1[e2] et e->id ne sont pas présentes. Celles-ci sont éliminées par l’analyseur syntaxique
qui produit les expressions équivalentes *(e1+e2) et (*e).id respectivement.
2 Types et environnements de typage
Dans tout ce qui suit, les expressions de types sont de la forme suivante :
τ ::= void | int | char | struct id | union id | τ* | typenull
où id désigne un identificateur de structure ou d’union et s une constante entière. Il
s’agit là d’une notation pour la syntaxe abstraite des expressions de types. On introduit
la relation ≡ sur les types comme la plus petite relation réflexive et symétrique telle que
τ1, τ2 ∈ {int, char, typenull}
τ1 ≡ τ2 typenull ≡ τ* void* ≡ τ*
Un environnement de typage Γ est une suite de déclarations de types de la forme
τ x, de déclarations de structures de la forme struct S {τ1 x1 · · · τn xn}, de déclarations
d’union de la forme union S {τ1 x1 · · · τn xn} et de déclarations de profils de fonctions de
la forme τ f(τ1, . . . , τn). On notera struct S {τ x} (resp. union S {τ x}) pour indiquer
que la structure S (resp. l’union S) contient un champ x de type τ.
Dans la suite, on dira qu’un type est numérique, et on notera num(τ) si τ est compatible
avec typenull, char, int ou un type pointeur.
3 Typage
3.1 Bonne formation des types
On dit qu’un type τ est bien formé dans un environnement Γ, et on note Γ ⊢ τ bf,
si tous les identificateurs de structures ou d’unions apparaissant dans τ correspondent à
des structures ou des unions déclarées dans Γ.
1

3.2 Typage des expressions
En C, il existe une classe d’expressions particulières nommées « valeurs gauches ».
Intuitivement, les valeurs gauches sont les expressions que l’on a le droit de placer à gauche
d’une affectation (d’où leur nom). À l’inverse d’autres langages, le fait d’être une valeur
gauche en C dépend du type de l’expression. C’est pourquoi on introduit simultanément
le jugement Γ ⊢ e : τ signifiant « dans l’environnement Γ, l’expression e est bien typée
de type τ » et le jugement Γ ⊢l e : τ signifiant « dans l’environnement Γ, l’expression e
est une valeur gauche bien typée de type τ ». Ces jugements sont définis par les règles
d’inférence suivantes :
(constantes)
(affectations)
Γ ⊢ 0 : typenull
c constante de type τ
Γ ⊢ c : τ
Γ ⊢l e : τ num(τ) op ∈ {++, --}
Γ ⊢ op e : τ
(comparaisons)
Γ ⊢l e1 : τ1 Γ ⊢ e2 : τ2 τ1 ≡ τ2
Γ ⊢ e1 = e2 : τ1
Γ ⊢ τ bf τ ≡ void
Γ ⊢ sizeof(τ) : int
Γ ⊢l e : τ num(τ) op ∈ {++, --}
Γ ⊢ e op : τ
Γ ⊢ e1 : τ1 Γ ⊢ e2 : τ2 τ1 ≡ τ2 op ∈ {==, !=, =}
Γ ⊢ e1 op e2 : int
(arithmétique et logique)
Γ ⊢ e : τ τ ≡ int op ∈ {+, -}
Γ ⊢ op e : int
Γ ⊢ e : τ num(τ)
Γ ⊢ !e : int
τ1 ≡ struct s
τ1 ≡ union s
τ1 ≡ void
Γ ⊢ e1 : τ1 Γ ⊢ e2 : τ2 τ1 ≡ τ2 τ1 ≡ int op ∈ {+, -, *, /, %, ||, &&}
Γ ⊢ e1 op e2 : int
(arithmétique de pointeurs)
Γ ⊢ e1 : τ1 Γ ⊢ e2 : τ2 τ1 ≡ τ ′ 1* τ2 ≡ int op ∈ {+, -}
Γ ⊢ e1 op e2 : τ ′ 1*
Γ ⊢ e1 : τ1 Γ ⊢ e2 : τ2 τ1 ≡ τ ′ 2* τ2 ≡ τ ′ 2*
Γ ⊢ e1 - e2 : int
2
Γ ⊢ e2 + e1 : τ
Γ ⊢ e1 + e2 : τ

(appel de fonction)
(accès)
Γ ⊢ e : struct S struct S {τ x} ∈ Γ
Γ ⊢ e.x : τ
(adresse)
Γ ⊢l e : τ
Γ ⊢ &e : τ*
(valeurs gauches)
Γ ⊢ ei : τi τ f(τ ′ 1, . . . , τ ′ n) ∈ Γ τi ≡ τ ′ i
Γ ⊢ f(e1, . . . , en) : τ
Γ ⊢l e : τ
Γ ⊢ e : τ
τ x ∈ Γ
Γ ⊢l x : τ
Γ ⊢l e : struct S struct S {τ x} ∈ Γ
Γ ⊢l e.x : τ
3.3 Typage des instructions
Γ ⊢ e : union S union S {τ x} ∈ Γ
Γ ⊢ e.x : τ
Γ ⊢ e : τ*
Γ ⊢l *e : τ
Γ ⊢l e : union S union S {τ x} ∈ Γ
Γ ⊢l e.x : τ
On introduit le jugement Γ, τ0 ⊢i i signifiant « dans l’environnement Γ, l’instruction i
est bien typée, pour un type de retour τ0 ». Intuitivement, τ0 représente le type de retour
de la fonction dans la quelle se trouve l’instruction i. Ce jugement est établi par les règles
d’inférence suivantes :
3

Γ, τ0 ⊢i ;
Γ, τ0 ⊢ e : τ
Γ, τ0 ⊢i e; Γ, void ⊢i return;
Γ ⊢ e : τ num(τ) Γ, τ0 ⊢i i1 Γ, τ0 ⊢i i2
Γ, τ0 ⊢i if (e) i1 else i2
Γ ⊢ e : τ num(τ) Γ, τ0 ⊢i i
Γ, τ0 ⊢i while(e) i
Γ, τ0 ⊢i i1 Γ ⊢ e : τ num(τ) Γ, τ0 ⊢i i2 Γ, τ0 ⊢i i3
Γ, τ0 ⊢i for(i1; e; i2) i3
Γ ⊢ e : τ0
Γ, τ0 ⊢i return e;
∀j ≤ k, Γ ⊢ τj bf τj ≡ void ∀j ≤ n, {τ1 x1, . . . , τk xk} ∪ Γ ⊢i ij
Γ, τ0 ⊢i {τ1 x1 · · · τk xk;i1 · · · in}
Cette dernière règle signifie que pour typer un bloc constitué de k déclarations de
variables (locales au bloc) et de n instructions, on vérifie d’abord la bonne formation des
déclarations puis on type chacune des instructions dans l’environnement augmenté des
nouvelles déclarations.
De plus, on a les équivalences suivantes :
– if (e1) e2 équivaut à if (e1) e2 else;
– si i1 ou i3 est omis dans for(i1;e2;i3) alors il équivaut à ;
– si e2 est omis dans for(i1;e2;i3) alors il équivaut à 1
– dans la construction for, une liste d’expressions e1, e2, . . . , en équivaut à la séquence
e1;e2; . . . ;en.
3.4 Typage des fichiers
On rappelle qu’un fichier est une liste de déclarations. On introduit le jugement « Γ ⊢
d → Γ ′ » qui signifie « dans l’environnement Γ, la déclaration d est bien formée et produit
un environnement Γ ′ ». Ce jugement est dérivable grâce aux règles suivantes :
Déclarations de variables (globales)
Déclarations de structures et d’unions
Γ ⊢ τ bf τ ≡ void
Γ ⊢ τ x → {τ x} ∪ Γ
Γ, struct id {τ1 x1 · · · τn xn} ⊢ τi bf
Γ ⊢ struct id {τ1 x1; · · · τn xn; } → {struct id {τ1 x1 · · · τn xn}} ∪ Γ
Γ, union id {τ1 x1 · · · τn xn} ⊢ τi bf
Γ ⊢ union id {τ1 x1; · · · τn xn; } → {union id {τ1 x1 · · · τn xn}} ∪ Γ
On vérifiera d’autre part que les types de champs τi ne font référence à la structure ou à
l’union id elle-même que sous un pointeur.
4

Déclarations de fonctions
Γ ⊢ τi bf ∀i > 0, τi ≡ void {τ0 f(τ1, . . . , τn), τ1 x1, . . . , τn xn} ∪ Γ, τ0 ⊢i b
Γ ⊢ τ0 f(τ1 x1, . . . , τn xn) b → {τ0 f(τ1, . . . , τn)} ∪ Γ
On remarque que le prototype d’une fonction est ajouté à l’environnement pour le typage
de cette dernière, cela dans le but de typer les fonctions récursives.
Fichiers. On introduit finalement le jugement Γ ⊢f d1 · · · dn signifiant « dans l’environnement
Γ le fichier constitué par la suite de déclarations d1, . . ., dn est bien formé ».
Le typage d’un fichier consiste à typer successivement les déclarations dans le contexte
étendu par chaque nouvelle déclaration, d’où les règles :
Γ ⊢f ∅
Γ ⊢ d1 → Γ ′ Γ ′ ⊢f d2 · · · dn
Γ ⊢f d1 d2 · · · dn
Règles d’unicité. Enfin, on vérifiera l’unicité :
– des identificateurs de structures sur l’ensemble du fichier ;
– des identificateurs d’union sur l’ensemble du fichier ;
– des champs de structure à l’intérieur d’une même structure ;
– des symboles (variables globales et fonctions) sur l’ensemble du fichier.
On notera qu’une structure et une union peuvent avoir le même identificateur.
Fonctions prédéfinies. Les fonctions suivantes sont supposées prédéfinies et devront
être connues à l’analyse sémantique :
int putchar(int n);
void *sbrk(int n);
De plus, on vérifiera la présence d’une fonction main avec l’un des deux prototypes
suivants :
int main();
int main(int argc, char** argv);
dans le fichier.
4 Travail demandé
Vous devez étendre votre compilateur, minic de la première partie (ou repartir du
corrigé) de manière à ce qu’il accepte sur la ligne de commande exactement un fichier C
et éventuellement l’option -type-only (l’option -parse-only de la partie 1 doit arrêter
le compilateur après l’analyse syntaxique, i.e. avant la phase de typage).
Si le fichier est conforme à la syntaxe et bien typé, le programme doit terminer avec
le code de sortie 0 (exit 0 explicite ou terminaison normale du programme), sans rien
afficher. En cas d’erreur lexicale, syntaxique ou de typage, celle-ci doit être signalée comme
en partie 1 et le programme doit terminer avec le code de sortie 1 (exit 1). En cas d’autre
erreur (une erreur du compilateur lui-même), le programme doit terminer avec le code de
sortie 2 (exit 2).
5

Anticipation La connaissance du type d’une expression est nécessaire pour la génération
de code (par exemple, dans l’expression e1+e2, il est nécessaire de connaître les
types de e1 et e2 pour savoir si on va générer le code pour une addition de pointeurs, une
addition d’entiers, etc. Vous ne pouvez donc pas vous contenter d’écrire une fonction de
typage renvoyant vrai ou faux (selon que le fichier est bien typé ou pas) mais vous devez
générer un nouvel AST contenant les informations de typage.
5 Notation
Le barème suivant est donné à titre indicatif
– Rapport : 6 points ;
– Qualité du code : 6 points (commentaires, indentation et lisibilité générale, élégance)
;
– Validité du compilateur : 8 points (obtenus par des tests automatiques, il est donc
très important de respecter scrupuleusement les modalités de rendu, sous peine
d’avoir 0/8 à cette partie).
Afin d’individualiser les notes au sein du binôme, il vous est demandé d’annoter chaque
fonction (ou fichier) conséquent par son auteur.
Modalités de remise de votre projet. Votre projet doit se présenter sous forme d’une
archive tar compressée (option “z” de tar), appelée binome_1-binome_2 .tar.gz qui doit
contenir un répertoire appelé binome_1-binome_2. Exemple : dupont-durand.tar.gz.
Utilisez des « _ » pour les noms composés et utilisez uniquement « - » pour séparer
les deux noms. Utilisez uniquement des minuscules, sans accent et sans espace. Dans ce
répertoire doivent se trouver les sources de votre programme (ne donnez pas les fichiers
compilés). Quand on se place dans ce répertoire, la commande make doit créer votre
compilateur, qui sera appelé minic. La commande make clean doit effacer tous les fichiers
que make a engendré et ne laisser dans le répertoire que les fichiers sources.
Le projet est à faire impérativement en binôme. Il doit être remis à votre chargé de
TP par e-mail 1 au plus tard
le Lundi 5 Novembre 2012, 17h00
Le non respect (même minime) des consignes ci-dessus entraînera une perte de points.
1. Groupe 1 : atafat@lri.fr, Groupe 2 : kn@lri.fr, Groupe 3 : iguer@lri.fr
6