TD6: Génération de code C pour les booléens

UFR d’Informatique
Master premiére Année - M1
Parcours Sciences et Technologies du Logiciel - STL
Unité d’enseignement ILP
TD6: Génération de code C pour les booléens
Dans cette séance nous implanterons les opération booléennes usuelles en ILP. Nous travaillerons en TD sur
les listings d’ILP1 mais nous les implémenterons en TME en ILP2.
La syntaxe concrète pour les opérations booléennes existe déjà en ILP1 mais toutes ne sont pas implémentées.
Nous allons voir différents choix d’implémentation pour ces opérations.
Exercice 1
En consultant les fichiers Cgenerator.java et CgenEnvironment.java qui se trouvent à partir de la page
40/60 des listings, compiler le programme ILP
<programme1>
<blocUnaire>
<variable nom=’x’/>
<valeur>
<booleen valeur=’true’/>
</valeur>
<corps>
<operationUnaire operateur=’!’>
<operande>
<variable nom=’x’/>
</operande>
</operationUnaire>
</corps>
</blocUnaire>
</programme1>
On tracera les différents appels de méthodes generate et compileOperator1 et on pourra détailler les
environnements qui interviennent. On pourra remarquer que la compilation introduit une variable temporaire,
pourquoi est-ce nécessaire ?
Exercice 2
En examinant les fichiers ilp.h et ilp.h qui se trouvent à partir de la page 48/60, donner les valeurs qui
sont créées à l’exécution des ce programme.
Exercice 3
Nous souhaitons maintenant implémenter rapidement les opérations booléennes usuelles dans l’interprète
ILP1. En examinant les fichiers EASToperationBinaire.java et CommonPlus.java Expliquez pourquoi
l’évaluation du programme
<programme1>
<operationBinaire operateur=’&’>
<operandeGauche>
<booleen valeur=’true’/>
</operandeGauche>
<operandeDroit>
<booleen valeur=’false’/>
</operandeDroit>
</operationBinaire>
</programme1>
1
échoue.
Exercice 4
Nous souhaitons maintenant faire la génération de code C pour les opérations booléennes binaires. En
reprenant les fichiers Cgenerator.java et CgenEnvironment.java expliquez pourquoi le programme de
l’exercice 3 ne se compile pas. Faites en sorte de pouvoir produire un programme C.
Exercice 5
Nous devons maintenant ajouter dans le runtime C d’ILP les implantations nécessaires pour pouvoir exécuter
l’appel que nous venons de générer. Modifier les fihciers ilp.h et ilp.c de façon à ajouter les opérations
manquantes.
Exercice 6
Nous pouvons maintenant interpréter et compiler des programmes contenant des « et » logiques. Pour
implanter le « ou » nous pouvons nous aider des lois Morgan et implanter a « ou » b à l’aide de
« non »(« non » a « et » « non » b)
Exercice 7
il y a 16 opérations booléennnes à deux arguments, il nous reste deux opérations usuelles à implanter qui
sont le « xor » et le « nand ». Le ou exclusif se note souvent + ou != et nous pouvons utiliser la syntaxe ^
pour le « nand ». On rappelle que a « nand » b vaut !(a & b). Comment implémenter ces notations ?
Exercice 8
Nous avons jusqu’à maintenant implémenté une stratégie d’évaluation et de compilation pour les opérations
logiques dans laquelle les arguments sont complètements évalués, elle se nomme la full evaluation. Toutefois
chacun sait que les valeurs « vrai » et « faux » possèdent des propriétés remarquables pour les opérations
« et » et « ou ». Ainsi dans a « et » b, si a est « faux » il n’est pas nécessaire d’évaluer b pour retourner
« faux ». De même dans a « ou » b, si a est « vrai », il n’est pas nécessaire d’évaluer b pour retourner « vrai ».
La valeur « faux » est dite absorbante pour l’opération « et », et la valeur « vrai » est dite absorbante pour
l’opération « ou ».
Ainsi certains langages de programmation implémentent une stratégie de lazy evaluation qui consiste à
ne pas évaluer le deuxième argument lorsque le résultat de l’évaluation du premier argument est l’absorbant
de l’opération. Ainsi, dans une syntaxe à la ML, un code
a&b
est équivalent à
if a then b else a
Question 8.1
Voyons d’abord l’évaluateur. Pourquoi ne pouvons nous pas modifier CommonPlus.java pour implémenter
cette stratégie ? Faire les modifications nécessaires pour l’implémenter.
Question 8.2
Voyons maintenant la génération de code C. Pourquoi ne peut-on pas se contenter de modifier le runtime
d’ILP ? Faire les modifications nécessaires pour implanter la stratégie d’évaluation paresseuse.
Question 8.3
Donner des exemples de programmes qui s’évaluent,se compilent et s’exécutent correctement avec la sémantique
d’évaluation paresseuse du « et » logique alors que ce ne serait pas le cas avec sa sémantique d’évaluation
complètte.
Question 8.4
Comment se comporte la définition du « ou » logique de l’exercice 6 vis à vis de l évaluation paresseuse ?
Pouvez vous y remédier ?
2