Les b´en´efices directs de l’IDM

L’infrastructure de compilation GeCoS est issue de travaux [121] proposant un environnement pour la conception et la compilation pour des soft-core sur FPGA. L’objectif de cette infrastructure ´etait alors d’utiliser Eclipse pour profiter d’un environnement hautement modulaire, facilitant l’´evaluation rapide d’approches exp´erimentales. Cette flexibilit´e a rapidement fait naˆıtre le besoin de formaliser et de standardiser le processus de d´eveloppement de l’infrastructure. L’IDM constitue une r´eponse directe `a ce besoin. GeCoS ´etant fortement coupl´e `a Eclipse, nous nous sommes naturellement int´eress´es aux outils de m´etamod´elisation fournis par EMF4_.

Le mod`ele constitue une documentation Un b´en´efice imm´ediat de l’IDM est que l’int´egralit´e des informations cl´es r´eside dans la sp´ecification du m´etamod`ele. Celui-ci ne concerne qu’un do- maine sp´ecifique d’un probl`eme, il est donc exempt des informations parasites d’une mise en œuvre concr`ete. Cette abstraction, qui est un pr´erequis, permet `a de nouveaux acteurs du d´eveloppement de s’approprier rapidement les diff´erentes structures de donn´ees, y compris dans les cas, fr´equents, o`u la documentation est manquante. D’autre part, le travail de mod´elisation effectu´e lors de la cr´ea- tion du m´etamod`ele ´evite la mise en œuvre« fr´en´etique » et donc source d’erreurs d’une approche exp´erimentale.

G´en´erateur de code : du mod`ele `a sa r´ealisation L’homog´en´eisation du code et l’utilisation de bonnes pratiques logicielles sont une cons´equence directe de l’IDM. Les g´en´erateurs de code (e.g., g´en´erateur de code Java EMF) produisent une impl´ementation respectant des interfaces standard et assurant la consistance structurelle des mod`eles. Le code g´en´er´e offre notamment une r´eflexivit´e avanc´ee (e.g., informations sur la composition et les attributs des objets) qui facilite l’´ecriture de fonctions utilitaires sans n´ecessiter une instrumentation du m´etamod`ele, fastidieuse et ´eloign´ee des pr´eoccupations du probl`eme mod´elis´e.

168 Chapitre 7. Compilation et ing´enierie dirig´ee par les mod`eles

Acc`es `a des outils g´en´eriques Les outils g´en´eriques, applicables `a n’importe quel m´etamod`ele, offrent une valeur ajout´ee significative pour un tr`es faible coˆut de mise en œuvre. Ces outils par- ticipent `a am´eliorer la robustesse des compilateurs. Tout d’abord, un mod`ele valide doit respecter les propri´et´es structurelles de son m´etamod`ele. Ces propri´et´es peuvent ˆetre facilement v´erifi´ees, par exemple lors de la s´erialisation d’un mod`ele. Cette s´erialisation, fonctionnalit´e de base fournie par EMF, analyse les arit´es des r´ef´erences et s’assure de leur coh´erence avec le m´etamod`ele. De plus, un mod`ele s´erialis´e est visualisable dans un ´editeur arborescent g´en´er´e automatiquement par EMF. L’arborescence provient de l’analyse des informations de composition d´ecrites dans le m´etamod`ele. La figure7.1illustre l’´editeur l´eg`erement personnalis´e de la repr´esentation interm´ediaire standard de GeCoS . Celui a ´et´e g´en´er´e directement `a partir de son m´etamod`ele. La racine de l’´editeur correspond `

a l’ensemble des proc´edures d´eclar´ees dans le fichier C. L’arborescence de cette racine fait notamment apparaˆıtre la hi´erarchie des blocs du programme et les instructions qui sont contenues dans les blocs de base. Cette facilit´e d’observation permet de d´etecter rapidement des erreurs apparaissant dans le r´esultat d’une transformation.

1 void MM(float **a, float **b, float

**c, int M){ 2 int i,j,k; 3 for (i=0;i<M;i=i+1){ 4 for (j=0;j<M;j=j+1){ 5 c[i][j]=0.0; 6 for (k=0;k<M;k=k+1){ 7 c[i][j]+=a[i][k]*b[k][j]; 8 } 9 } 10 } 11 }

Figure 7.1 – Visualisation de la repr´esentation interm´ediaire arborescente de GeCoS pour une mul- tiplication de matrices.

Le langage de contraintes OCL5_{peut ˆetre utilis´e pour exprimer des r`egles additionnelles de valida-}

tion des mod`eles. Il offre la possibilit´e d’exprimer des requˆetes complexes sur la structure d’un mod`ele `a partir des informations issues du m´etamod`ele. Le langage OCL dispose d’un ensemble d’op´erations sur les ensembles qui facilite particuli`erement la mise en œuvre des requˆetes sur des repr´esentations interm´ediaires arborescentes. Cela s’av`ere utile dans un flot de compilation optimisant constitu´e d’une s´equence complexe de transformations pour assurer, `a chaque ´etape, que les pr´e et post conditions d’une transformation sont respect´ees. Par exemple, une passe d’´evaluation des constantes d’un pro- gramme est plus efficace sur une repr´esentation interm´ediaire sous une forme `a assignation unique (SSA6_{). Une requˆete OCL simple (cf. figure 7.2) garantissant que chaque variable n’est affect´ee}

qu’une seule fois, correspond alors `a une pr´e-condition de l’optimisation.

G´en´eraliser ces v´erifications additionnelles permet d’accroˆıtre la robustesse globale du compilateur

5. Object Constraint Language 6. Static Single Assignment

7.3. Utilisation de l’IDM dans les compilateurs 169

1 let affectations : Collection(SymbolInstruction) = 2 self.basicBlocks.instructions

3 ->select(i | i.oclIsTypeOf(SetInstruction))

4 ->collect(set | set.oclAsType(SetInstruction).dest)

5 in

6 self.scope.allSymbols

7 ->forAll(s | affectations->select(e | e.symbol=s)->size()<=1)

Figure 7.2 – V´erification OCL de la forme SSA d’une proc´edure GeCoS.

tout en facilitant l’appr´ehension d’un flot de compilation complexe en identifiant clairement les inter- actions des diff´erentes transformations. L’int´egration d’un interpr´eteur OCL dans les ´editeurs g´en´er´es automatiquement par EMF est une fonctionnalit´e standard qui permet de prototyper rapidement des contraintes OCL sur des mod`eles concrets de repr´esentations interm´ediaires.