Rapport Master Bechir Zalila

7/23/2019 Rapport Master Bechir Zalila

1/52

Mmoire de stageMasterSystmes et Applications Rpartis

Optimisation, Dterminisme et Asynchronisme desSouches et Squelettes CORBA pour Systmes RpartisTemps-Rel

tudiant : Responsables du stage :

Bechir ZALILA Laurent PAUTET

Fabrice KORDON

15 Septembre 2005


2/52

ii


3/52

Table des matires

Remerciements v

Rsum vii

I Introduction 1I.1 Autour de la problmatique du temps rel . . . . . . . . . . . . . . . . . . . . . 1I.2 Autour des optimisations dans les intergiciels . . . . . . . . . . . . . . . . . . . 1I.3 Autour des architectures de compilateurs. . . . . . . . . . . . . . . . . . . . . . 3I.4 Description du mmoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

II Conformit au standardCORBA3.0 7II.1 Compilateur prototypeIAC1.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

II.1.1 Ancienne architecture deIAC. . . . . . . . . . . . . . . . . . . . . . . . 8II.1.1.1 La partie frontale . . . . . . . . . . . . . . . . . . . . . . . . 8

II.1.1.2 La partie dorsale . . . . . . . . . . . . . . . . . . . . . . . . . 10II.1.2 Avantages par rapport IDLAC . . . . . . . . . . . . . . . . . . . . . . . 12II.1.3 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

II.1.3.1 Les fonctionnalits manquantes . . . . . . . . . . . . . . . . . 13II.1.3.2 Les dfauts darchitecture . . . . . . . . . . . . . . . . . . . . 13

II.2 Nouvelle architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13II.2.1 Nouveau schma de fonctionnement . . . . . . . . . . . . . . . . . . . . 14

II.2.1.1 Expansion de code. . . . . . . . . . . . . . . . . . . . . . . . 14II.2.1.2 Factorisation de code . . . . . . . . . . . . . . . . . . . . . . 15

II.2.2 Fonctionnalits implmentes dans la partie frontale . . . . . . . . . . . 15II.2.3 Fonctionnalits implmentes dans la partie dorsale. . . . . . . . . . . . 16

II.2.3.1 Fonctionnalits compltes . . . . . . . . . . . . . . . . . . . 16II.2.3.2 Fonctionnalits Ajoutes . . . . . . . . . . . . . . . . . . . . 16

II.2.4 Validation de la conformit. . . . . . . . . . . . . . . . . . . . . . . . . 19

III Vers un intergiciel optimis et dterministe 21III.1 Utilisation des tables de hachage minimales parfaites . . . . . . . . . . . . . . . 21

III.1.1 Approche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22III.1.1.1 Premire approche. . . . . . . . . . . . . . . . . . . . . . . . 22III.1.1.2 Deuxime approche . . . . . . . . . . . . . . . . . . . . . . . 23

III.1.2 Gains obtenus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23III.2 Limplmentation de laSII . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

III.2.1 Approche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25III.2.2 Gains obtenus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

iii


4/52

iv TABLE DES MATIRES

IV Conclusions et perspectives 31IV.1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31IV.2 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Bibliographie 33

Annexe A : Description de larbreIDL 351 Description gnrale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352 Avantages par rapport lASTde IDLAC . . . . . . . . . . . . . . . . . . . . . . 363 Entits gnres . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Annexe B : Description de larbreAda 391 Description gnrale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392 Liaisons entre les deux arbres. . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Annexe C : Cas particulier du module CORBA 431 Modification de larbreIDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432 Anomalies dansorb.idl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44


5/52

Remerciements

Je tiens exprimer mes remerciements les plus sincres M. Laurent PAUTET pour mavoir ac-cueilli dans son quipe pendant ce stage et pour les comptences que jai acquises dans le domainede linformatique rpartie et le dveloppement des compilateurs.

Je remercie galement Jrme HUGUES pour les conseils quil ma donns et pour les rponses toutes les questions que je lui posais trs souvent qui mont fait gagner un temps prcieux.

Mes vifs remerciement vont aussi Thomas VERGNAUD et Khaled BARBARIA pour les aideset conseils quils mont apports.

Finalement, je remercie mes collgues stagiaires pour les agrables cinq mois et demi que jaipass avec eux.

v


6/52

vi REMERCIEMENTS


7/52

Rsum

Dans le cadre de mon Master Systmes et Applications Rpartis lUniversit Pierre et MarieCurie, jai effectu un stage de six mois dans le dpartementINFRESdeTelecom Paris. Ce rapportdcrit le travail effectu pendant le stage ainsi que les rsultats obtenus.

Le stage, qui sintitule :Optimisation, Dterminisme et Asynchronisme des Souches et SquelettesCORBApour Systmes Rpartis temps-rel, consiste :

Dans un premier temps complter limplmentation de IAC(Idl to AdaCompiler), lenouveau compilateur IDLde lintergiciel schizophrnePolyORB. IACremplacera IDLAC,lancien compilateur dePolyORBen raison de la difficult de la maintenance de ce dernier.

Dans un second temps, proposer puis mettre en uvre des optimisations qui augmente-ront les performances des souches et des squelettes gnrs par ce compilateur.

vii


8/52

viii RSUM


9/52

Chapitre I

Introduction

I.1 Autour de la problmatique du temps rel

Linformatique temps-rel permet de dvelopper des applications qui doivent respecter des contraintestemporelles plus ou moins strictes (temps rel dur vs. temps rel souple). Une des principales ca-ractristiques dune application temps-rel est le dterminisme, ce qui veut dire que les tempsdexcution des diffrentes actions doivent tre borns.

Quand le besoin du temps-rel est exprim par une application rpartie, le dterminisme est plusdifficile obtenir parce que les communications en rseau introduisent beaucoup dalas dans

les temps dexcution des diffrentes actions entre les diffrentes entits de lapplication rpartie.Ajoutons cela le fait que les entits dune mme application rpartie pourraient sexcuter surdes plates-formes diffrentes et le problme devient beaucoup plus difficile.

Pour pallier le problme de lhtrognit, une nouvelle invention a vu le jour : les intergiciels(Middleware). Les intergiciels on t conus pour pouvoir faire communiquer des entits sex-cutant sur des plates-formes diffrentes et ventuellement crites dans des langages de program-mation diffrents. Tout ceci en pargnant au dveloppeur la programmation de la partie commu-nication proprement-dite et en le laissant se concentrer sur ce que doit effectivement faire sonapplication rpartie. Dans le monde des intergiciels,CORBA(Common Object Request Broker Ar-chitecture) est un standard trs connu. Il a t crit par lOMG(Object Management Group) [7] en

1991 pour les raisons et les besoins voqus plus haut.Le fait darriver faire communiquer des entits htrognes diminue considrablement les per-formances de lapplication rpartie et rend les contraintes du temps rel beaucoup plus difficiles respecter. Cest pourquoi tous les efforts sont fournis pour optimiser le fonctionnement des inter-giciels.

I.2 Autour des optimisations dans les intergiciels

Le standardCORBArepose sur la philosophie suivante : Le client et le serveur peuvent tre dvelopps dans des langages de programmation diff-rents et tourner sur des plates-formes diffrentes.

1


10/52

2 CHAPITRE I. INTRODUCTION

Interface

Repository

Fichier IDL

Implementation

Repository

Compilateur IDL

Client

Serveur

Obj

Ref

DIISouche

IDL

Interface de

LORB

Squelette

IDL DSI

Adapteur DObjet

ORB Core GIOP/IIOP

Object (Servant)

Opration()

in args + inout args

out args + inout args

FIGUREI.1 Architecture gnrale deCORBA

La localisation de lobjet distant est faite de faon transparente par rapport au client. Ceciveut dire que dans le code du client dvelopp par le programmeur, il ny a aucune rf-rence ladresse du serveur (qui peut dailleurs changer entre deux excutions successivesdu client)

La communication entre le client est le serveur est essentiellement faite de faon synchrone(bien que la spcification prsente deux autres types de communication : semi-synchroneet asynchrone).

La figureI.1donne un aperu global de larchitecture CORBA. Pour construire une applicationrpartie reposant sur ce standard, le dveloppeur dcrit les relations entre les diffrentes entits delapplication (les interfaces de lapplication) dans un langage de description darchitectures (IDL).Gnralement, chaque intergiciel dispose de son propre langage de description dinterfaces. LestandardCORBAdcrit son langageIDLdans le chapitre 3 de la spcification [7].

Un compilateurIDLse charge de gnrer le code qui dcrit la partie communication entre le clientet le serveur (lessoucheset lessquelettes).

Durant les dernires annes, le dbit du transfert des donnes dans les rseaux est devenu plusgrand et ne constitue plus un goulot dtranglement pour lapplication rpartie. Dsormais, cest lecode de lapplication elle-mme qui doit tre optimis. En particulier, le code gnr par les compi-lateursIDLa besoin dtre trs performant pour ne pas dgrader les performances de lapplicationrpartie.

Lintergiciel utilis dans le cadre de ce stage est lintergiciel schizophrnePolyORB. La schizo-phrnie dans le domaine des intergiciels a t introduite pour permettre linteroprabilit entrediffrents modles de rpartition (Middleware To Middleware). Ainsi, un intergiciel schizophrneinstancie simultanment plusieurs personnalits et leur permet de cohabiter et dinteragir [11].

Comme toute implmentation classique de la spcification publie par lOMG, la personnalitCORBAde PolyORBsouffre de quelques problmes dcrits longuement dans le mmoire biblio-graphique qui a prcd le stage [13]. Les principaux problmes dont souffre une application


11/52

I.3. AUTOUR DES ARCHITECTURES DE COMPILATEURS 3

rpartie conue selon le standardCORBAsont :

Le temps de communication long des requtes qui est principalement d au fait que le

standard CORBA effectue une abstraction de lhtrognit et que tous les traitementsfaits lors de lexcution dune requte ne sont pas toujours ncessaires (cas o le client et leserveur sexcutent sur la mme plate-forme). La personnalitCORBAajoute cela le faitquelle utilise un mcanisme dynamique de traitement des requtes qui a, certes, lavantagede pouvoir omettre de prciser le type des donnes changes lors de la compilation maisqui introduit un dlai supplmentaire non ngligeable lors du traitement des requtes.

Lindterminisme : en effet, le temps dexcution des requtes dpend fortement de lasignature de lopration correspondante la requte et du nombre total doprations dansune mme interface de lapplication rpartie.

La grande empreinte mmoire de lapplication rpartie qui est aussi due labstraction delhtrognit des diffrentes entits.

Le synchronisme qui peut parfois tre considr comme une limite. Le traitement par d-faut des requtes dansCORBAest synchrone. Il existe des types doprations ditesonewayqui permettent au client de poursuivre son excution juste aprs lenvoi de la requte sansse bloquer, mais ce type dasynchronisme ne peut sappliquer quaux oprations qui neretournent pas de rsultat au client.

La taille des messages changs par les diffrentes entits de lapplication rpartie estgrande et implique un temps dexcution long des requtes.

Pour chacun des problmes de CORBAvoqus, des solutions (des optimisations) ont t propo-ses dans le mmoire bibliographique [13] en se basant sur diffrents travaux de recherches sur lestandardCORBA.

La principale partie de lintergiciel qui doit tre optimise tant le compilateur IDL, il faut quecelui-ci soit trs bien conu au dpart et quil soit, de plus, facilement maintenable pour pouvoir yintgrer les optimisations avec le moins de peine possible.

I.3 Autour des architectures de compilateurs

Le compilateurIDLde PolyORBsappelleIDLAC(IDL to AdaCompiler).IDLACpossde larchi-tecture classique dun compilateur :

Une partie frontale "Parse" le fichier sourceIDL, vrifie sa syntaxe et gnre un arbre syn-taxique abstrait (AST). Cet arbre subit une expansion pour le rendre plus explicite et pourfaciliter la gnration de code partir de cet arbre.

Une partie dorsale qui prend en entre lASTet qui gnre du codeAdaconformment auxspcifications du mapping Adapublies par lOMG[6].

IDLACa subi plusieurs modifications au fur et mesure de lvolution de lintergicielPolyORB. chaque modification, le compilateur devient de plus en plus complexe. Actuellement, IDLACest uncompilateur trs difficilement maintenable et souffre de plusieurs anomalies de fonctionnement.Ces proprits de IDLACse situent aux antipodes des proprits attendues dans un compilateurpour faciliter son optimisation.

La meilleure solution pour avoir un compilateur flexible et optimisable tait de construire un nou-veau compilateur IDL en vitant de tomber dans les mmes piges de conception rencontrs lors


12/52


du dveloppement de IDLAC. IAC, (Idl to AdaCompiler) est un nouveau compilateurIDL qui estcens remplacer IDLACdans PolyORB la fin de ce stage. La partie frontale de IACa t dve-loppe pendant lt 2003. Ses petites diffrences par rapport la partie frontale deIDLACseront

dtailles dans le chapitreIII.Le dveloppement de la partie dorsale deIACa commenc en 2004dans le cadre dun stage de DEA. Larchitecture de cette partie est totalement diffrente de celledeIDLAC. Elle utilise le concept novateur de transformation darbre. Ce concept sera dtaill lorsde la description de larchitecture deIACdans le chapitreIII.

Lobjectif de ce stage est de :

1. Achever la conception de IACen le mettant niveau vers la version la plus rcente deCORBAet en faisant en sorte quil offre toutes les fonctionnalits prsentes dans IDLAC.Ce travail na pas t une tche facile parce que la construction des compilateurs est diff-rente de la construction des applications classiques (aussi complexes soient-elles). Il ma

fallu donc une priode dapprentissage pour mapproprier les sources de IACet pour mefamiliariser avec les concepts utiliss pour ensuite pouvoir men servir durant le dvelop-pement.

2. Proposer et implmenter des optimisations dansIACen sinspirant du travail de rechercheeffectu dans le mmoire bibliographique. A lissue de cette phase, les applications rpar-ties dont les souches et les squelettes ont t gnrs avecIACdevraient tre nettement plusperformantes que les applications dveloppes laide deIDLAC.

I.4 Description du mmoire

Le plan de ce mmoire sarticule en deux parties principales conformment lobjectif du stage.

Dans le chapitreII,je dcrirai larchitecture de dpart de IAC, je prsenterai ses avantages parrapport larchitecture deIDLAC. Ensuite je prsenterai les modifications et les ajouts que jai tamen implmenter dansIACpour le mettre niveau vers la dernire version du standardCORBAnotamment le nouveau schma de fonctionnement de IACqui intgre un expanseur darbre (II.2.1).Je listerai ensuite les nouvelles fonctionnalits ajoutes IACpour le mettre niveau par rapport IDLAC.

Le chapitreIIIprsente les optimisations qui ont t retenues et implmentes dansIAC: Lutili-sation des fonctions de hachage minimales parfaites pour garantir le dterminisme dans le tempsdexcution des requtes et loptimisation du traitement des requtes en utilisant des mthodesstatiques la place des mthodes dynamiques qui taient les seules utilises par PolyORB. Pourchaque optimisation, je dcrirai lapproche utilise pour son implmentation et je donnerai lesgains en performance obtenus.

Le chapitreIVconclue ce mmoire et prsente les diffrentes perspectives qui souvrent devantIAC. Il y aura notamment une listes de fonctionnalits utiles implmenter dans le futur et uneexplication sur la manire de faire voluerIAC.

la fin de ce mmoire trois annexes contiennent des informations supplmentaires et utiles :

Les annexes A et B dcrivent les structures des arbres syntaxiques respectivement pour leslangages IDLet Ada. Ces descriptions sont crites en "PSEUDO IDL" et un programme


13/52

I.4. DESCRIPTION DU MMOIRE 5

spcial (mknodes) gnre les paquetagesAda ncessaires pour la construction et la mani-pulation de ces arbres.

Lannexe C dcrit le cas particulier du moduleCORBAexistant dans le fichier "orb.idl"

et les dispositions spciales qui ont t prises dans IACpour rendre possible lanalyse dece module.


14/52



15/52

Chapitre II

Conformit au standardCORBA3.0

IAC(Idl toAdaCompiler) est un gnrateur de codeAda partir de descriptionsIDL. Il est destin remplacerIDLACcar il est plus volutif que lui. En effet, le dveloppement de IACa t fait defaon plus structure que celle deIDLAC. Les sparations entre diffrentes parties du compilateursont plus claires. De plus, IACpeut facilement tre tendu pour gnrer des souches et des sque-lettes dans un langage autre queAda partir du langageIDL(mais le nom naurait plus une grandesignification dans ce cas).

Bien entendu, IACna pas t dvelopp partir de zro : plusieurs parties bien faites de IDLACont t amliores et intgres dansIACtelles que la gestion des erreurs et des avertissements, lemcanisme de lanalyse de fichiers, la sparation de Parseret Lexer. Certaines parties de IAC,

comme le mcanisme de construction de lAST(Abstract Syntax Tree) ont t reprises ou inspiresdes sources du compilateur Ada GNAT. La partie dorsale deIACest diffrente de celle deIDLAC,elle permet davoir plus de flexibilit et de maintenabilit pour le compilateur.

Au dbut du stage, le niveau deIACntait pas aussi avanc que celui de IDLAC. Il implmentait laplupart du langageIDL, mais la version deCORBAdont il sagissait ntait pas la dernire commecest le cas pour IDLAC. La version de dpart de IACimplmente la grammaire IDL publie dansla version 2.3 de la spcification de CORBA(rgles 1 98). Par exemple, IACne gnrait pastous les sous-paquetagesHelperqui contiennent des mthodes utiles pour la conversion de types.La mme remarque est valable pour les paquetages_IDL_Filequi regroupent les entit dclares lextrieur de tout module et de toute interface. Pour tous ces paquetages, IACse contentait de

gnrer des squelettes (des paquetages vides) de fichiers.La premire phase du stage a consist mettre IAC niveau pour quil implmente la gnra-tion de code pour la dernire version de la spcificationCORBA(3.0.4). Hormis le fait que cettephase a mis IAC niveau par rapport IDLAC, elle ma permis de mapproprier ses sources et decomprendre les mcanismes et les technologies de dveloppement des compilateurs en lesquels jenavais pas une grande exprience au dbut du stage.

II.1 Compilateur prototypeIAC1.0

Comme IDLACet comme tout autre compilateur, IACse compose dune partie frontale (frontend)et dune partie dorsale (backend). Le dveloppement de ces deux parties dans IACa t fait dune

7


16/52

8 CHAPITRE II. CONFORMIT AU STANDARDCORBA3.0

faon plus modulaire que dansIDLAC.

titre dexemple, la manipulation des chanes de caractres nest plus faite de faon directe

comme dans le cas de IDLAC. Un niveau dabstraction a t ajout : la table de noms. Toutesles manipulations de chanes de caractres en partant de lanalyse du fichier source IDLjusqu lagnration de codeAdautilisent le paquetage Nametqui offre toutes les mthodes ncessaires. Ceniveau dabstraction emprunt des sources du compilateurAda GNATpermet au dveloppeur deslever dun cran dans la construction de IAC. Il est aussi noter que la majorit crasante destypes de donnes utiliss dans IAC sont des types personnaliss ce qui constitue un autre niveaudabstraction qui va assurer une dpendance vis--vis des diffrentes architectures et une flexibilitdu compilateur.

II.1.1 Ancienne architecture deIAC

Avant de dtailler larchitecture deIAC, il est important de parler dune des phase les plus impor-tantes de la compilation : le Preprocessing. Cette phase consiste traiter des directives spciales(commenant par le caractre "#" en dbut de ligne) qui ne font pas partie de la syntaxe du lan-gage trait, en loccurrence le langage IDLdans notre cas. Son principal effet est dinclure desdfinitions partir dautres fichiers source (par le biais de la directive #include) et de suppri-mer ou garder des portions de code selon les options donnes en ligne de commande (directive#ifdefpar exemple). LePreprocessingpeut tre implment dans le compilateurIDL comme ilpeut tre effectu en utilisant un programme indpendant. IDLACet IACutilisent tous les deux lepr-processeur deGCCpour traiter toutes les directives lexception de #pragmaqui nest pasreconnue par le pr-processeur C++.

lissue de la phase de Preprocessing, on obtient une suite de Tokens(cest le terme utilis dansla spcification de CORBApour dfinir les diffrentes entits existant dans un fichier sourceIDL).Il existe cinq catgories deTokens:

Les identificateurs : qui servent nommer les modules, les interfaces... Les mots-cls : qui sont la base du langageIDL. Les valeurs littrales dentiers, de rels, de chanes de caractres... Les oprateurs comme le "+", le "-"... Les autres sparateurs comme les accolades, les parenthses, le point-virgule...

LOMGdfinit pour certains types de Tokensdes rgles de construction (les identificateurs). Pour

dautres Tokens, une liste exhaustive de toutes les valeurs possibles est donne (les mots-cls).Cest en respectant ces rgles, et en sappuyant sur la grammaire du langageIDL(chapitre 3 de [7])que la partie frontale deIACva traiter un fichier source IDLet produire une sortie correcte utilisablepar la partie dorsale.

II.1.1.1 La partie frontale

Le fonctionnement de la partie frontale deIACest similaire celui de tout autre compilateur. Enentre, la partie frontale reoit un fichier sourceIDLcrit conformment la grammaire du langage

spcifie par lOMG. La sortie principale de cette partie est un arbre reprsentant la structure dufichier : larbre syntaxique abstrait (Abstract Syntax Tree). Les sorties secondaires de la partiefrontale consistent en dventuels avertissements ou messages derreurs. La figureII.1donne un


17/52

II.1. COMPILATEUR PROTOTYPEIAC1.0 9

Fichier source

IDL

Arbre Syntaxique

Abstrait

Avertissments

Erreurs

Partie Frontale

de IAC

FIGUREII.1 Partie frontale deIAC: fonctionnement global

aperu global sur le fonctionnement de la partie frontale deIAC.

La partie frontale deIACest dcompose en trois parties principales : Le lexeur (Lexer), le parseur(Parser) et lanalyseur (Analyzer). Le fonctionnement de ces trois parties nest pas squentiel, dumoins pour le lexeur et le parseur. La figureII.2montre la circulation du flux de donnes entre cestrois composantes de la partie frontale.

Le Lexeur : Cette partie parcourt le fichier sourceIDLcaractre par caractre et essaie de recon-natre les diffrentsTokensrencontrs (identificateur, mot-cl, valeur littrale...). Chaquedemande cette partie davancer dans le traitement du fichier et de vrifier le prochaintokenmet jour un ensemble de variable indiquant le type du token, lidentificateur de sonnom dans la table des noms et la valeur sil sagit dune valeur littrale. Une des proprits la fois intressante et utile de IACest quon peut enregistrer un moment donn ltatdu lexeur, ensuite revenir vers cet tat un moment ultrieur. Cette fonctionnalit facilite

beaucoup le traitement dun fichier sourceIDL.

Le Parseur : Les routines prsentes dans cette partie utilisent le lexeur et la grammaireIDLpourvrifier la syntaxe du fichier source IDLet construire lAST. Globalement, pour chaquergle de la grammaireIDL [7], il existe une fonctionParse_XXXXqui appelle les routinesdu lexeur et construit une partie de lAST. Leffet principal du parseur est de transfor-mer les sourcesIDL dune squence linaire deTokensen une structure arborescente for-me de plusieurs nuds. La racine des source IDL tant la spcification, le point dentrevers le parseur de IACest donc la fonction Parse_Specificationqui, selon la naturedes Tokensque le lexeur lui envoie, appelle les fonctions Parse_XXXX correspondantes.La fonction Parse_Specificationretourne la racine de lASTqui est un nud de type

K_Specification. La structure de larbre IDLainsi que les mcanismes mis en uvrepour sa gnration sont expliqus dans lannexe A de ce mmoire.

LAnalyseur : Larbre IDLconstruit par le parseur vrifie certes la grammaire IDLmais la s-mantique nest pas ncessairement vrifie. Il se peut par exemple que certaines constantesdclares aient des valeurs qui se situent lextrieur de lintervalle de leur type. Lana-lyseur vrifie la smantique des sourcesIDL. Il complte aussi la construction de certaineparties de larbre qui ne peuvent tre ajoutes que si le parseur a parcouru tout le fichiersource (lesforward interfaceet la rsolution des noms par exemple).

lissue de lanalyse de la partie frontale, on obtient un arbre de syntaxe reprsentant la structuredes sourcesIDL. Cet arbre va constituer lentre de la deuxime partie de IAC: la partie dorsale.


18/52


Lexeur

Parseur

Ananlyseur

Squence linaire

de Tokens

Contrle

Arbre IDL

incomplet

Fichier source

IDL

Erreurs et avertissements

de syntaxe

Erreurs et avertissements

de smantique

AST

FIGUREII.2 Partie frontale deIAC: dtails

II.1.1.2 La partie dorsale

Comme il a t dit prcdemment,IACa t construit pour supporter plusieurs parties dorsales. Lechoix du backendutilis nest donc pas fig dans les sources du compilateur comme cest le caspourIDLAC. Avec la ligne de commande, on choisi lebackend laide de loption de compilation- dans laquelle dsigne un langage de programmation support parIAC. Dans ltatactuel des choses,IACdispose de deux parties dorsales :

1. Une partie dorsale IDL servant gnrer un fichier source IDL partir de larbre syntaxi-que construit dans la partie frontale. Ceci sert vrifier le bon fonctionnement de la partiefrontale.

2. Une partie dorsaleAdaqui gnre les souches et les squelettesCORBAconformment auxspcifications de mapping [6]. Cest cette partie qui a constitu lobjet principal du travaildurant le stage. partir de ce moment, et dans le reste du mmoire, le terme "Partie dorsaledeIAC" dsigne la partie dorsale relative au langageAda.

La partie dorsale deIACest diffrente de celle deIDLAC. Alors que dans IDLAC, la gnration decode se rsume desPut_Line,IACadopte une autre stratgie : partir de larbreIDLgnr dans

la phase frontale de la compilation, le compilateur gnre un arbreAdaqui contient la descriptiondes souches et squelettes implmenter.

La partie dorsale est donc dcoupe en deux parties principales (cf figureII.3) :

II.1.1.2.1 Construction de larbreAda Dans cette partie, larbreIDLest parcouru un nombrede fois gal au nombre de types de paquetages Adaqui doivent tre gnrs. Pour gnrer lessouches, lesHelpers, les squelettes et les implmentations, il faut donc parcourir larbreIDL4 fois.Il faut noter que larbreAdana pas une seule racine comme il est le cas pour larbreIDL, mais ildispose dune liste de racines (4 si on ne gnre que les souches, lesHelpers, les squelettes et les

implmentations). Chacune de ces racines est gnre lors dun parcours de lAST. Pour plus dedtails concernant la structure de larbreAda et la manire dont il est construit, voir lAnnexe Bde ce mmoire.


19/52

II.1. COMPILATEUR PROTOTYPEIAC1.0 11

Construction de

larbre Ada

Arbre

Ada

Gneration du

Code Ada

Arbre

IDL

Code Ada

Partie dorsale de IAC

FIGUREII.3 Partie dorsale deIAC: fonctionnement global

Lordre de la construction des paquetages est crucial. Tout dabord il faut construire toutes les sp-cifications de paquetages avant les corps de ces paquetages parce que les branches correspondantaux corps utilisent des nuds de la branche correspondant aux spcifications. Par exemple pourconstruire le corps dun sous-programme, on ne construit pas une nouvelle spcification mais onutilise celle cre lors de la construction de la partie spcification. Ceci va diminuer le nombretotal de nuds dans larbreAda.

De plus, certains types de paquetages utilisent des entits dclares dans dautres types. Par exemple,lesHelpersutilisent les entits dclares dans les souches, les corps des squelettes utilisent des en-tits des spcifications des Helperset des implmentations. Lordre de construction qui respecteces dpendances est le suivant :

1. Construction des spcifications des Souches

2. Construction des spcifications desHelpers

3. Construction des spcifications des Implmentations

4. Construction des spcifications des Squelettes

5. Construction des corps des Souches

6. Construction des corps desHelpers

7. Construction des corps des Squelettes

8. Construction des corps des Implmentations

Pour pouvoir accder aux nuds cres lors de la gnration dun type de paquetage donn, lesdeux arbres IDLest Adasont lis et les Bindingsncessaires sont crs au fur et mesure de laconstruction de larbreAda (voir lannexe B pour plus de dtails sur lesBindingsentre les deuxarbres).

Une deuxime amlioration consiste grer de faon abstraite les noms des paquetages de lAPICORBA. Toutes les entits sont dclares dans un paquetage spar (Backend.BE_Ada.Runtime).


20/52


Si une entit change de lieu dans lAPI, il suffit deffectuer la modification dans ce paquetage. Deplus la gestion de la clausewithest effectue de faon tout fait transparente pour lutilisateur :la fonction Expand_Designatordu paquetage Backend.BE_Ada.Expandqui sert gnrer des

identificateurs compltement qualifis ajoute les clauses withncessaires au paquetage couranttout en sassurant de la non duplication dune mme clause.

II.1.1.2.2 Gnration du codeAda Une fois larbreAdaconstruit, la gnration du code sef-fectue en appelant la mthodeGeneratedu paquetage Backend.BE_Ada.Generatorsur la liste-racine de larbreAda. Cette mthode effectue des appelsdispatchantvers les diffrentes mthodesGenerate_XXXXselon les types de nuds rencontrs.

II.1.2 Avantages par rapport IDLAC

Pour pouvoir comparer les parties dorsales des deux compilateurs, il est ncessaire de dcrire leurfonctionnement. Celle de IACtant dcrite enII.1.1.1, voici une brve description de la partiedorsale deIDLAC:

Avant de gnrer le code partir de larbreIDLconstruit dans la partie frontale, il faut savoir queles informations contenues dans cet arbre sont incompltes. En effet, il existe plusieurs donnesimplicites qui nont pas t reprsentes dans larbre comme les oprations et les attributs hritspar une interface, les membres dune exception... La phase de lexpansion consiste ajouter lesdonnes manquantes larbre pour quil soit prt la gnration de code. Il faut noter que cette

phase aurait pu tre omise ou plus prcisment intgre dans la phase de gnration de code maisceci va beaucoup compliquer cette dernire phase.

Aprs la phase dexpansion, arrive la dernire phase qui est la phase de gnration de code. Lorsde cette phase, larbreIDLest parcouru en profondeur et le code ncessaire pour chaque nud estgnr en respectant les spcifications du mappingAdapublies par lOMG[6]. Cette manire trsintuitive de gnrer le code prsente plusieurs inconvnients :

Il ny a pas de possibilit de retour en arrire, ce qui veut dire que pour gnrer le corpsdune procdure, il faut imprativement gnrer toute la partie dclarative avant la partieinstructions, ou encore, dans un paquetage, il faut ajouter toutes les clauseswithnces-

saires manuellement au dbut. Ceci pose beaucoup de contraintes si on veut implmenterdes optimisations dans le compilateur : lendroit o implmenter ces optimisations seraimpos par le fait que le code est gnr de faon linaire. Ce qui va ventuellement rendreles sources du compilateur trs difficiles comprendre.

Puisque la plus grande partie du code est gnre en utilisant des appels la procdurePut_Line, la maintenabilit du compilateur est mise en question. Par exemple, si lAPIpour laquelle le code est gnr est modifie, plusieurs modifications doivent tre effec-tues surIDLAC.

Le fait de sparer dansIACla partie traitement des donnes de la partie gnration de code apporteune grande flexibilit ce compilateur. Le dveloppeur ne manipule plus des chanes de caractres

qui, une fois gnres dans un fichier, ne peuvent plus tre modifies. Il manipules des nuds etdes listes quil peut modifier volont tant que la phase gnration de code na pas t entame.Le mcanisme dajout des clauseswithprofite pleinement de ce concept.


21/52

II.2. NOUVELLE ARCHITECTURE 13

De plus, la liaison (Binding) effectue entre larbre IDLet larbre Adapermet daccder desnuds dj cres et de les utiliser sans devoir crer de nouveaux nuds. Ceci contribue diminuerle nombre de nuds dans larbreAda.

II.1.3 Limitations

Les limitations deIACpeuvent tre divises en deux catgories, les fonctionnalits manquantes etles dfauts darchitecture.

II.1.3.1 Les fonctionnalits manquantes

Au dbut du stage, il y avait tellement de fonctionnalits manquantes dans la partie dorsale de IAC

quil narrivait pas gnrer du codeAdacorrect pour le simple fichierIDLsuivant :

module Tpcorba {

exception divisionParZero {};

interface Calcul {

void Bid_Rac(inout long Data);

void Bid_Carre(inout long Data);

};

};

Ceci ma empch dentamer directement la partie optimisation ds le dbut du stage car il fal-lait un compilateur capable de compiler la plupart du langage IDL. Il a fallu alors une prioderelativement longue (la moiti de la dure du stage temps plein, ensuite en parallle avec les op-timisations) pour implmenter toutes les fonctionnalits manquantes dans la partie dorsale deIAC.Les fonctionnalits qui ont t implmentes dansIACsont dtailles dansII.2.2et dansII.2.3.

II.1.3.2 Les dfauts darchitecture

Au fur et mesure de lajout de nouvelles fonctionnalits dans IACje me suis aperu que la partieexpansion, jusque l inexistante, tait ncessaire pour rsoudre plus simplement certains problmesrencontrs, notamment pour traiter certains cas particuliers desforwarddinterfaces. Jai constataussi de la rplication de code plusieurs endroits dans les source de IACchose qui rend trsfastidieuse la correction des bogues et la modification des sources.

II.2 Nouvelle architecture

Dans la partieII.2.1,je dcrirai la nouvelle architecture de la partie dorsale de IAC. Cette nou-velle architecture a rendu IACplus flexible et a facilit considrablement limplmentation desoptimisations dcrites dansIII.


22/52


Construction de

larbre Ada

Arbre

Ada

Gneration du

Code Ada

Arbre IDL

Code Ada

Expansion de

Code

Arbre IDL

Expans

FIGUREII.4 Partie dorsale deIAC: nouvelle architecture

II.2.1 Nouveau schma de fonctionnement

II.2.1.1 Expansion de code

Comme il a t prcis dansII.1.3.2,une partie expansion sest avre ncessaire pour rendrela gnration de code plus simple et pour garder une structure flexible pour IAC. Plusieurs fonc-tionnalits seront implmentes directement dans la partie expansion, comme lajout des forwardimplicites dinterfaces impos par la nature du langageAda. Dautres fonctionnalits existant djdans le cur de la partie dorsale devraient tre dplaces dans la partie expansion pour allger laconstruction de larbreAda.

La nouvelle partie dorsale deIACdcrite par la figureII.4se compose dsormais de 3 parties :

La partie expansion : qui prend en entre larbre IDLconstruit par la partie frontale (AST), lemodifie pour gnrer en sortie un arbreIDL qui donne lieu une gnration de code Ada

beaucoup plus simplement.

La construction de larbreAda: qui, en parcourant larbre IDLexpans, gnre un arbre Ada


23/52


qui dcrit la structure des souches et des squelettesCORBAde lapplication rpartie encours de dveloppement. Le parcours de larbre IDL seffectue laide des procduresVisit_ o dsigne un type de nud de larbreIDL.

La construction de larbreAdase fait en utilisant les fonctions Make_dupaquetage Backend.BE_Ada.Nutilso dsigne un type de nud delarbreAda.

La gnration de code Ada: Une fois larbre Adaconstruit, la gnration de code se fait laidedes procdures Generate_ du paquetage Backend.BE_Ada.Generator .

II.2.1.2 Factorisation de code

Lors de la construction de larbreAda, la cration de certains types de nuds ncessite laccs dautres nuds dj cres. Par exemple pour pouvoir crer un appel vers une fonctionTo_Anydun certain type, il faut connatre le type du paramtre pour crer lappel vers la bonne fonctionAu fur et mesure de lvolution de IAC, de nouveaux cas de figure pour laccs au nuds sontapparus et la duplication de code allait rendre le dveloppement fastidieux. Le code a donc tfactoris en sous-programmes. Pour accder aux fonctionsTo_Anyet From_Anydun type donn,le dveloppeur doit utiliser les fonctions Get_From_Any_Nodeet Get_To_Any_Nodedu paque-tage Backend.BE_Ada.Nutils. Ces deux fonctions effectuent les tests de tous les cas de figurepossibles et retournent le bon nud.

II.2.2 Fonctionnalits implmentes dans la partie frontale

La mise niveau de la partie frontale vers la version la plus rcente deCORBA3.0.4 est quasimentacheve. Il ne manque plus que lanalyse desimportqui impose que le parseur de IACdoive trerepens et qui, pour des contraintes temporelles na pu tre acheve par manque de temps. Lestypeprefix et les typeidont t implments mais ne sont pas compltement tests (notammenttous les cas particuliers donns dans la specificationCORBA[7]).

Les fonctionnalits qui ne sont pas implmentes dans PolyORB(lesvaluetypespar exemple) nesont implmentes ni parIACni par IDLAC.

Certaines anomalies de fonctionnement trouves dans la partie frontale ont t corrigs :

Dans une opration, une structure ou une union, il ntait pas permis dutiliser un paramtre(ou membre) de mme nom que son type, ce qui est lgal. Bien entendu, le type dont il estquestion est un type interface, structure ou union ou un type qui redfinit un type de basecar il est interdit dutiliser les mots-cls comme des identificateurs.

Une des optimisations apportes par la partie frontale de IACconsiste valuer les ex-pressions littrales avant de les intgrer dans larbreIDL le type de lexpression nest paschang en fonction de sa nouvelle valeur. Exemple :

const short a = 1 - 2;

La constantea vaut -1, mais le type de la valeur littrale -1 reste toujours non sign (carle type des constantes1 et 2 est non sign) ce qui gnre une erreur lors de la vrificationdes bornes la phase danalyse.


24/52


II.2.3 Fonctionnalits implmentes dans la partie dorsale

II.2.3.1 Fonctionnalits compltes

II.2.3.1.1 La gestion des exceptions : Au dbut du stage, IACne gnrait pas la constante_Repository_Id . Il ne gnrait pas non plus le corps de la fonction Get-_Members impose par les spcification du mappingAda[6]. Il manquait aussi les fonctions From-_Any, To_Anyet la constante TC_qui sont ncessaires pour la conversion desmembersde lexception ainsi que la procdureRaise_Exception. la fin du stage, les exceptions dutilisateurs, les exceptions systme et les exceptions inconnuessont parfaitement gres parIAC.

II.2.3.1.2 Les interfaces : Il manquait la constante _Repository_Id. Lescorps des diffrents sous programmes dclars dans la spec(les souches) (construction des re-qutes, empaquetages des paramtres...) sont incomplets, il manque la gestion des paramtres demodeout etinout. Toutes ces fonctionnalits manquantes ont t ajoutes et sont oprationnelles.

II.2.3.1.3 Le squelette : Jai implment la gestion des exceptions et la mise jour des para-mtresoutetinoutdune opration.

II.2.3.2 Fonctionnalits Ajoutes

II.2.3.2.1 Linitialisation des paquetagesHelperet des squelettes : Cette partie est nces-saire pour le bon fonctionnement de lapplication rpartie et pour quePolyORBpuisse initialiserles diffrents paquetages dans le bon ordre.

II.2.3.2.2 Les squences : La gnration de code pour les squences bornes et non bornesqui est une fonctionnalit vitale pour un compilateurIDLa t implmente et teste avec succs.

II.2.3.2.3 Lhritage des interfaces : le langage IDL, permet une interface dhriter duneou plusieurs autres interfaces. Dans ce cas, linterface fille possde toutes les oprations et les attri-

buts des interfaces parentes. De plus, toutes les dfinitions de types et les dclarations de constanteset dexceptions qui existent dans les interfaces parentes doivent tre visibles dans linterface fille.Pour cela les spcifications du mappingAda[6] imposent de "renommer" (au sensAdadu terme)les constantes et les exceptions ou de crer des sous-types dans le mapping de linterface fille.Visiblement,IDLACna pas choisi cette voie. Il utilise directement les constantes, exceptions outypes partir du mapping de linterface parente.La partie frontale de IACsemble stre engage sur la mme voie que IDLAC. En partant delexemple ci dessous :

module m {

interface int1 {typedef long T1;

typedef short T2;


25/52


long op1();

attribute long attr1;

exception myException {};

};

interface int2 : int1 {

typedef string T2;

string op3() raises (myException);

attribute string attr3;

T1 op31();

T2 op32();

int1::T2 op33();

};

};

Linterface int2hrite de linterfaceint1. Elle doit donc pouvoir accder au type T1dfini parint1comme sil tait dfinit par elle.Par contre, dans la ligne "T2 op32();", le type T2 dsigne le type dfini dans int2. La ligne"int1::T2 op32();" ne prsente aucune ambigut. En utilisant le backend IDLde IAC, le rsultatest le suivant :

module m {

interface int1 {

typedef long T1;

typedef short T2;long op1();

attribute long attr1;

exception myException {

};

};

interface int2 : m::int1 {

typedef string T2;

string op3() raises (m::int1::myException);

attribute string attr3;

m::int1::T1 op31();

m::int2::T2 op32();m::int1::T2 op33();

};

};

On voit bien donc que :

int2utilise les types et les exceptions de int1. Le typeT2a t redfini dansint2. Laccs la version deT2dfinie dansint1demeure possible en indiquant les noms com-

plets.

La gnration de code pour lhritage multiple dinterfaces a t implmente dans la partie dorsalede IAC. Les constantes et les dfinitions de types et dexceptions dans les interfaces parentes sont


26/52


renommes dans linterface fille pour permettre au client davoir accs ces entits. Si un conflitest dtect, par exemple, si deux parents contiennent des dfinitions de mmes noms, seule lapremire est renomme. Les autres seront ignores.

II.2.3.2.4 Les tableaux multidimensionnels et imbriqus : Cette fonctionnalit tait absenteau dbut du stage. Elle tait parmi les premires fonctionnalits que jai implment dans IAC.Cependant suite une modification de la faon dont PolyORBencode les tableaux, jai t amen la rimplementer conformment la nouvelle spcification dePolyORB. Actuellement, le codegnr pour les tableaux multidimensionnels et imbriqus est correct.

II.2.3.2.5 Lutilisation de types cres par des interfaces : les interfaces IDL sont des construc-teurs de types, on doit donc pouvoir utiliser le nom dune interface comme type de paramtre dans

une opration par exemple.

II.2.3.2.6 Les interfaces locales : Ces types dinterfaces diffrent des interfaces classiques parle fait quelles ne peuvent faire lobjet dune communication entre deux entits diffrentes (clientet serveur). Ceci a pour consquence la non gnration de squelettes et de fonction de conversion partir et vers le type Anypour ce type dinterfaces.

II.2.3.2.7 Les interfaces Abstraites : Ce sont des interfaces qui ne peuvent tre utilises di-

rectement mais doivent tre hrites par des interfaces ou desvaluetypes. La partie concernant lesinterfaces dans les interfaces abstraites t implmente avec succs.

II.2.3.2.8 Les unions : La gnration de code pour les typesunionest maintenant implmen-tes et teste avec succs. Ces types ont lavantage dconomiser lempreinte mmoire par rapportaux simples structures.

II.2.3.2.9 La forward declaration des interfaces : Cest une fonctionnalit vitale pour uncompilateur IDL. Cette fonctionnalit a t implmente avec succs dans la partie dorsale deIAC. Certains cas particuliers o on doit ajouter desforward declarationspour viter le problmede la dpendance mutuelle de deux paquetages Adaont t rsolus par la partie expansion de code.

II.2.3.2.10 La gnration de commentaires : Pour rendre le code gnr plus lisible, descommentairesAdaont t gnrs diffrents endroits des souches et des squelettes. Des enttesde commentaires ont t gnrs pour prciser que les fichiers sont gnrs automatiquement etquil ne faut pas les modifier la main (sauf pour les fichiersImpl).

II.2.3.2.11 Traitement des fonctions implicites deCORBA: dans CORBAle client peut in-voquer des mthodes implicites. Pour traiter ces mthodes, un nouveau paquetage est ajout de lapersonnalit CORBAde PolyORB: PolyORB.CORBA_P.Implicit_CORBA_Methods.


27/52


II.2.3.2.12 Analyse du module CORBA : Daprs le chapitre 5 de [6], le fichier orb.idlcontient un module particulier, le moduleCORBA. Pour des raisons relatives la nature du langageAda, larbre IDLrelatif au fichier orb.idldoit tre restructur. Aprs cette modification, deux

nouveaux sous modules du module CORBAsont cres :1. CORBA::Repository_Root qui contient toutes lesforwardinterfaces et les entits relatives

lInterface Repository

2. CORBA::IDL_Sequences qui contient la dclaration de types squences dfinis partir destype de baseCORBA

La raison principale de cette restructuration est que les entits des deux sous-paquetages ne sontpas utilises par la plupart des applications rparties et, tant donn que le forwarddinterfaceet les types sequenceimpliquent des instanciations de paquetages gnriques en Ada, la taille dupaquetage CORBAde lintergiciel deviendrait norme ce qui augmenterait lempreinte mmoirede lapplication rpartie.

Lanalyse du fichier orb.idlsert dans la plupart des cas uniquement faire entrer lescopedumodule CORBAdans le global scopeet ne doit gnralement pas donner lieu a une gnration decode Ada. Il se trouve que certains paquetages dont le mapping Ada [6] recommande lexistencesont des souches et des squelettes dentits se trouvant dans le fichier orb.idlet leur intgrationdans le dpt contraint le principe disant quil ne faut pas intgrer du code gnr automatiquementdans un dpt. Ces paquetages sont gnrs automatiquement lors de la compilation de PolyORB.Pour plus de dtails sur lanalyse du moduleCORBA, voir lannexe C.

II.2.4 Validation de la conformit

La validation des diffrentes fonctionnalits ajoutes sest effectue en utilisant une suite trs richede tests de rgression. Les diffrentes catgories de tests pour IACsont :

1. ada0001 ada0009 :Les tests de la bonne gnration des spcifications des paquetagespour les souches et les squelettes. Les spcifications gnres sont compiles avec des corpsde paquetages gnrs parIDLAC. Ces tests couvrent une large partie des la gnration decode, tels que les types, les unions, les structures, les exceptions...

2. ada0010 ada0018 :Les tests de la bonne gnration des corps des paquetages pour lessouches et les squelettes. Ce sont les mmes tests que la suite prcdente mais l, tout lecodeAdaest gnr parIAC.

3. ada0019 ada0022 :Les tests pour la redfinition de types de baseCORBA.4. chicken-egg, circular et forward01 forward01 :Les tests pour lesforward declara-

tionsdes interfaces. Lexemple est tir de la spcificationCORBA[7]. Il y a aussi les testspour les cas particuliers o le compilateur doit gnrer des forward declarationsimplicitespour les besoins du langage Ada.

5. inherit001 inherit005 :Les tests pour lhritage des interfaces. La complexit de cestests augmente avec leur numro, allant du simple hritage jusqu arriver vers lhritagemultiple avec redfinition des constantes, types et exceptions.

6. local001 local002 :Les tests pour les interfaces locales.

7. abstract001 :Test pour les interfaces abstraites.

8. idl* :Les tests vrifiant le bon fonctionnement du parseur, lexeur et analyseur et la bonnegnration des messages derreur.


28/52


9. test001 test054 :Tests vrifiant la bonne construction de lAST.

10. corba-idl :Test vrifiant que le module CORBAest bien analys.

En plus de tous les tests cits ci-dessus et qui sont passs avec succs, trois exemples dapplicationrpartie sont fournis pour tester le bon fonctionnent du code gnr parIAC:

all_functions : teste tous les modes de passages de paramtres possibles dans une opration. Cetest vrifie aussi le bon fonctionnement de lasynchronisme (oprationsoneway).

all_types : teste tous les types de donnes quon peut dclarer dans un fichier IDL (squences,unions, tableaux, types de base...)

all_types_local : exactement le mme que all_types mais avec une interface locale.


29/52

Chapitre III

Vers un intergiciel optimis etdterministe

La partie mise niveau deIAC pris un peu plus de temps que prvu (un peu plus de la moiti dustage) cause du nombre important de fonctionnalits manquantes. Le dbut de la phase doptimi-sation ne pouvait se faire sans la prsence dun compilateur parfaitement oprationnel qui compileune large varit de fichiers sourceIDL.

Il a fallu donc choisir les optimisations les plus importantes parmi celles que jai propos dans lemmoire bibliographique [13] et rejeter les autres. Le deux optimisations qui ont t juges lesplus importantes sont :

1. Lapport du dterminisme dans le traitement des requtes par les squelettes en utilisant lestables de hachage minimales parfaites.

2. Limplmentation de laSII.

III.1 Utilisation des tables de hachage minimales parfaites

Quand le squelette dune application rpartie reoit une requte traiter, il compare le nom de larequte avec les noms de toutes les oprations de linterface jusqu trouver la bonne opration etappeler son implmentation. Cette mthode de recherche doprations est adopte par IDLACet at reprise dansIAC. Par exemple si une interfaceIDLcontient dix oprations :

long echoLong01 (in long data) ;


...


La structure du squelette va avoir cette allure :

if (Operation = "echoLong01") then

;

21


30/52

22 CHAPITRE III. VERS UN INTERGICIEL OPTIMIS ET DTERMINISTE

elsif (Operation = "echoLong02") then

;

...

elsif (Operation = "echoLong10") then;

else

;

end if;

Cette manire trs intuitive de traiter les requtes un inconvnient principal : le temps que metle serveur pour trouver une opration est directement li la place o cette opration est dclare(au dbut ou la fin de linterface).

Loptimisation consiste rendre le temps de recherche du nom de lopration constant quelquesoit lendroit o elle est dclare. Ceci est effectu en utilisant les tables de hachages minimalesparfaites.

Une fonction de hachage h est une fonction qui associe les lments dun ensemble de motsWde taillemaux lments dun intervalle dentiers[0, k1]. La fonctionh(w)calcule gnralementune adresse ou un indice dans un tableau o le motwest stock. Ce tableau est connu aussi sous lenom de "Table de Hachage". On dit quil y a une collision si deux ou plusieurs mots ont le mmecode de hachage. Une fonction de hachage parfaiteest une fonction injective. Une fonction dehachage minimale parfaite est une bijection de lensemble des mot Wvers lintervalle[0, k1]cequi implique que les tailles des deux ensembles soient gales.

Le compilateur Ada GNAT implmente un algorithme de gnration de fonctions de hachageminimales parfaites. Cest un algorithme probabiliste crit par Czech, Havas et Majewski en1992 [3]. La gnration statique de fonctions de hachage minimales parfaites impose la contraintede connatre tous les mots de lalphabet avant lexcution de lalgorithme. Il se trouve que cestle cas des squelettes : la compilation dun fichier sourceIDL, on a accs aux noms de toutes lesoprations. Lalgorithme implment peut fonctionner en deux modes : un mode optimisant lem-preinte mmoire des excutables et un autre mode optimisant le temps de calcul. Les deux modessont supports parIACet lutilisateur peut choisir loptimisation qui lui convient.

III.1.1 Approche

III.1.1.1 Premire approche

Une premire approche a consist construire pour chaque opration, une procdure Invoke_-. La fonction de hachage est gnre en mme temps que les souches et lessquelettes. Les hash codes sont des indices dans un tableau de pointeurs sur les procduresInvoke_-. Le rle de la procdureInvokeest de calculer le hash codedune oprationet, ensuite, dinvoquer la bonne procdure ou de gnrer un erreur si lopration nexiste pas.

Cette approche a trs vite t carte car les indirections induites par lutilisation de pointeurs surdes procdures namliorent les performances que lorsque le nombre doprations est trs grand(voir les rsultats des tests enIII.1.2).


31/52

III.1. UTILISATION DES TABLES DE HACHAGE MINIMALES PARFAITES 23

III.1.1.2 Deuxime approche

La deuxime approche qui a t retenue est trs proche de la premire mais dans ce cas, le table

de hachage ne contient plus des pointeurs sur des procdures mais les chanes de caractres elles-mmes pour des raisons de vrification. La structure conditionnelle dans la procdure Invokeestremplace par un switch case dont les paramtres sont les hash codes (qui appartiennent untype scalaire et peuvent donc tre utiliss dans un switch case). Cette approche fait augmenterconsidrablement les performances vu que leswitch caseeffectue des sauts directs et ne teste pastoutes les conditions (cfIII.1.2).

III.1.2 Gains obtenus

Tous les tests ont t effectus sur un PC compatible IBM qui possde les caractristiques sui-vantes :

Processeur : Intel(R) Pentium(R) 4 3.00 GHz

Mmoire vive : 1 Go

OS : Debian GNU Linux (unstable) avec un noyau 2.6.8

CompilateurAda: GNAT Pro 5.03a (20050114-34)

Le test consiste en une application rpartie contenant une centaine doprations :

interface test_hash {

long echoLong00 (in long data) ;long echoLong01 (in long data) ;

...


}

Le script du test automatique compile trois fois lapplication rpartie : une premire fois sans uti-liser loptimisation des tables de hachage minimales parfaites, une deuxime fois en optimisant letemps de calcul et une troisime fois en optimisant lempreinte mmoire. Aprs chaque compila-tion, le serveur et le client sont excuts. Le client effectue 4 types dinvocations un nombre donnde fois (donn en ligne de commande) :

1. En excutant seulement la premire opration

2. En excutant seulement la dernire opration

3. En excutant toutes les oprations dans lordre de faon circulaire

4. En excutant toutes les oprations dans un ordre alatoire

Type doptimisation Pas doptimisation Temps CPU Empreinte mmoireClient 2165 2165 2165Serveur 2979.55 2979.64 2979.27

TABLEIII.1 Taille des excutables (Kilo-Octets) en fonction du type doptimisation


32/52


0.00019

0.000195

0.0002

0.000205

0.00021

0.000215

0.00022

0.000225

0.00023

0 10 20 30 40 50 60 70 80 90 100

Imple

mentationfetchingtime(sec)

Operation index

Fetching times (ordered)

No_OptCPU_OptMem_Opt

FIGUREIII.1 Premire approche dutilisation des tables de hachage

0.00019

0.000195

0.0002

0.000205

0.00021

0.000215

0 10 20 30 40 50 60 70 80 90 100

Implementationfetchingtime(sec)

Operation index

Fetching times (ordered)

No_OptCPU_OptMem_Opt

FIGUREIII.2 Deuxime approche dutilisation des tables de hachage


33/52

III.2. LIMPLMENTATION DE LASII 25

Les temps dexcution sont rcuprs dans des fichiers qui donnent lieu ensuite un graphiquegrce un script GNU Plot. La figureIII.1montre les temps dexcution en fonction de lin-dice de lopration en utilisant la premire approche (celle des pointeurs). La figureIII.2montre

les mmes rsultats mais en utilisant la deuxime approche (celle duswitch case). On voit bienlamlioration de performance apporte par le seconde approche : on gagne ds lutilisation de lapremire opration. Le tableauIII.1montre les tailles des excutables pour les trois cas de figure.Bien entendu, puisque le client nutilise pas le squelette de lapplication rpartie, sa taille reste in-change. Quant au serveur, sa taille lors de loptimisation CPU est un peu plus grande que celle ducas sans optimisation. Ceci est d lutilisation de tables relativement grandes pour les calcul deshash codes. Loptimisation mmoire permet dobtenir la plus petite taille mmoire. tant donnque les performances sont quasiment les mmes quavec loptimisation CPU (au contraire de cequi est affirm dans larticle [3]), cest cette optimisation quil est conseill dutiliser.

III.2 Limplmentation de laSII

LintergicielPolyORBtraite toutes les requtes dune manire dynamique. Ce mode de traitementsappelle laDII(Dynamic Invocation Interface). Il a lavantage de permettre le traitement dune re-qute mme si la signature exacte de lopration nest pas connue la compilation de lapplicationrpartie. Dans ce type de traitement, le client construit une liste des paramtres convertis au typeAny(la NVList). Cette liste est passe la couche protocolaire qui se charge de faire lempaque-tage des paramtres aprs les avoir convertis une deuxime fois vers leur types dorigine. Du cotserveur, le processus inverse est effectu : les paramtres sont dsempaquets dubuffer, convertisau type Any et mis dans une NVListpar la couche protocolaire de lintergiciel. Le squelette de

lapplication rpartie se charge de convertir les paramtres vers leur type dorigine avant dappelerlimplmentation. Pour envoyer le rsultat dune requte et les diffrent paramtresoutetinout,le mme travail est effectu. La figureIII.3dcrit le fonctionnement de la DIIdansPolyORB.

On voit bien daprs la figureIII.3quil existe plusieurs conversions vers et partir du typeAny. Sila signature de lopration est connue la compilation, il serait judicieux dempaqueter les para-mtres directement sans les convertir vers le typeAny. Cest le principe de laSII(Static Invocation

Interface). La figureIII.4dcrit le fonctionnement de laSII. Au contraire de la DII, la couche ap-plicative du client ne remplit pas une NVListmais met jour les champ dun enregistrement. Ceschamps reprsentent les diffrents paramtres de lopration en plus du rsultat sil sagit dunefonction. Ainsi, on arrive viter lutilisation inutile des types Any.

III.2.1 Approche

Pour pouvoir implmenter la SII, il faut que chaque opration dispose de ses propres fonctionsdempaquetage (marshalling) et de dsempaquetage (unmarshalling) des paramtres. Ces deuxfonctions sont gnres automatiquement parIACdans un sous-paquetage spar, de mme niveauque lesHelpers et qui est appel CDRspour (Common Data Represenatation). En plus de ces deuxsous programmes, le paquetageCDRscontient la dclaration du type enregistrement qui contientles paramtres et le rsultat. Ce type hrite du type abstraitRequest_Args dcrit dans le paquetagePolyORB.Requests:

type Request_Args is abstract tagged null record;


34/52


1

2

3

4 5

6

7

8

Couche applicative

Couche applicative

Couche protocolaire

Couche protocolaire

NVList

NVList

NVList

NVList

Buffer

Buffer Buffer

Buffer

Rseau

Client

Serveur

Paramtres

IN et INOUT

Paramtres

IN et INOUTRsultat +

Paramtres

OUT et INOUT

Rsultat +

Paramtres

OUT et INOUT

Appel To_Any et

remplissage de la

NVList

Appel From_Any et

remplissage du

Buffer

Vidage du Buffer, appel To_Any et remplissage

de la NVList

Appel From_Any

Excution de

limplmentation

Appel To_Any et

remplissage de la

NVList

Appel From_Any etremplissage du

Buffer

Vidage du Buffer, appel

To_Any et remplissage

de la NVList

Appel From_Any

FIGUREIII.3 Fonctionnement de laDII


35/52


1

2

3

4 5

6

7

8

Couche applicative

Couche applicative

Couche protocolaire

Couche protocolaire

Enregistrement

de paramtres

Buffer

Buffer Buffer

Buffer

Rseau

Client

Serveur

Paramtres

IN et INOUT

Paramtres

IN et INOUTRsultat +

Paramtres

OUT et INOUT

Rsultat +

Paramtres

OUT et INOUT

Remplissage dun

enregistrement

Remplissage

du Buffer

Vidage du Buffer,etremplissage de

lenregistrement

Excution de

limplmentation

Enregistrement

de paramtres

Enregistrement

de paramtres

Enregistrement

de paramtres

Mise jour des

valeurs des paramtres

Mise jour des

valeurs des paramtres

Remplissage

du Buffer

Vidage du Buffer,et

remplissage de

lenregistrement

Remplissage dun

enregistrement

FIGUREIII.4 Fonctionnement de laSII


36/52


-- This type should be extended in order to contain the request arguments

type Request_Args_Access is access all Request_ArgsClass;

Un troisime sous programme est gnr automatiquement pour mettre jour le nouveau champqui a t ajout la structure de la requte : cest le champPayloadqui est un pointeur vers unevariable de type Request_Payload. Ce dernier type est un enregistrement qui contient un champde type Request_Args_Access. Il est aussi dclar dans PolyORB.Requests:

type Request_Payload is tagged record

Args : Request_Args_Access;

end record;

-- This type may be extended to add accesses to subprograms that handle the

-- arguments

type Request_Payload_Access is access all Request_PayloadClass;

La personnalit protocolaireGIOPtend ce type pour ajouter deux pointeurs vers les fonctionsdempaquetage et de dsempaquetage :

-- The Payload-derived type which contains the accesses

type Operation_Payload is new PolyORB.Requests.Request_Payload with

record

From_CDR : CDR_Subprogram_Type;

To_CDR : CDR_Subprogram_Type;

end record;

Il existe quatre endroits dans lesquels les paramtres de lopration sont traits :

1. Lempaquetage des paramtres IN et INOUT par le client

2. Le dsempaquetage des paramtres IN et INOUT par le serveur

3. Lempaquetage des paramtres OUT et INOUT par le serveur

4. Le dsempaquetage des paramtres OUT et INOUT par le clientDans ces quatre endroits, un test est ajout. On vrifie si le champ Payloadde la requte a bient mis jour. Si oui, on utilise la SIIon appelant les fonctions gnres automatiquement. Sinon,on utilise laDIIexactement comme si aucune modification navait t apporte.

III.2.2 Gains obtenus

La gnration automatique des fonctions dempaquetage et de dsempaquetage est oprationnellepour les types suivants :

Les long Les unsigned long Les short


37/52


FIGUREIII.5 Comparaison de laSIIet laDIIpour certains types (10000 itrations)

Les string Les squences de types supports (bornes et non bornes)

Le principe du test de performance est le suivant : effectuer un grand nombre de fois des appelsvers des fonctionsechoqui prennent comme paramtre une variable dun certain type etse contentent de retourner la mme variable. Les tests sont effectus sur une plate-forme identique celle deIII.1.2.

La figure III.5 donne une comparaisons des temps dexcution de 10000 requtes pour les unsignedlong,stringet squences de 10unsigned long. Les gains en performance sont trs clairs :

Pour lesunsigned long: 11% Pour lesstring: 11% Pour les squences : 33%

Test Unsigned Long String Squence

Entit Client Serveur Client Serveur Client ServeurDII 1811.57 2497.05 1813.21 2495.85 2050.73 2774.70SII 1811.46 2496.06 1819.59 2501.67 2053.74 2767.87

TABLEIII.2 Taille des excutables (Kilo-Octets) enSIIetDII

Le tableauIII.2donne les tailles des excutables utiliss dans le dernier test. On remarque quilnexiste pas de rgle gnrale pour la modification de lempreinte mmoire de ces excutables enpassant de la DII la SII. Dans le cas des long, la taille mmoire du client et du serveur diminueen passant la SII. Elle augmente dans le cas des string. Dans le cas des squences, cette taille

augmente pour le client et diminue pour le serveur. Ceci est d au fait que le passage la SIIncessite lajout dun code supplmentaire lapplication (la structure contenant les paramtres etles deux procdures de stockages des paramtres). Il implique aussi la non utilisation des fonctions


38/52


FIGUREIII.6 Comparaison de laSIIet laDIIpour les squences (1000 itrations)

de stockage de PolyORButilisant la DII. Toutefois, les tailles des excutables sont trs proches etles diffrences ne dpassent jamais la dizaine de Kilo-Octets.

La figureIII.6montre lvolution des gains en performance pour lexcution de 1000 itrationspour les squences en changeant leur longueur. On remarque que plus les squences sont longues,plus le gain en performance est important. Dans le cas de laDII, le temps dexcution augmentetrs rapidement en fonction de la longueur de la squence tandis que dans le cas de la SII, cettecroissance est lente.


39/52

Chapitre IV

Conclusions et perspectives

IV.1 Conclusions

la fin de ce stage, je peux dire que les objectifs qui ont t fixs au dpart ont t atteints : lecompilateur IACest maintenant au niveau de IDLAC. Le remplacement de IDLACpar IACdans lessources dePolyORBne ncessite plus quun minime effort.IACest un compilateur flexible et seprte la maintenance beaucoup plus facilement que IDLAC.

Les deux optimisations qui ont t implmentes dans IACont beaucoup augment les perfor-mances des applications rparties gnres par ce compilateur aussi bien en ajoutant le dtermi-

nisme (tables de hachage minimales parfaites) quen diminuant considrablement le temps dex-cution des requtes (SII).

Maintenant que les tests ont montr le grand apport en performance de la SII, la poursuite de lagnration de code pour le reste des types (structures, unions, tableaux) qui est une tche facilemais qui va prendre un temps considrable peut tre entame.

IV.2 Perspectives

Certaines fonctionnalits nont pu tre ajoutes dans IACpar manque de temps, il serait intres-sant de commencer par les implmenter avant de poursuivre lvolution de IACet pour pouvoirremplacer dfinitivementIDLACpar IAC:

1. Lachvement des importsqui va ncessiter lapport de modifications profondes dans lastructure duParser.

2. Limplmentation de la gnration de code pour les types anonymes (cf 3.11.6 de [7]). Bienque lutilisation de tels types soit obsolte dans CORBA3.0, certains fichiers sourceIDLdePolyORB les contiennent. Limplmentation de cette fonctionnalit devrait tre effectue

dans la partie expansion de la partie dorsale.

3. Les chanes de caractres bornes.

31


40/52

32 CHAPITRE IV. CONCLUSIONS ET PERSPECTIVES

Deux fonctionnalits qui sont trs utiles dans un compilateurIDL, et qui constitueraient des enri-chissements deIACpar rapport IDLAC(avec loptimisation des squelettes et limplmentation delaSII) seraient :

1. La gnration de code pour lesforward declarationsde structures et dunions. Une telleimplmentation ne serait pas aussi facile que laforward declaration des interfaces. En effet,dans la spcificationCORBA, la possibilit dune telle dclaration est prcise. Cependant,dans les spcifications du mappingAda[6], la marche suivre nest pas donne.

2. Limplmentation de la gnration de code pour lesvaluetypesdansIACet dansPolyORB.

Une optimisation trs intressante qui pourrait aussi tre implmente dansIACdans la continuitde la SII, est lallocation statique des buffersen calculant lavance leur taille. Ce nest pas unetche trs simple vu que cette taille dpend, en plus du nombre et de la nature des paramtres,de la version du protocoleGIOP. Il faudra aussi implmenter les mcanismes dallocation statiquedans le paquetagePolyORB.Buffers. On pourrait aussi envisager dutiliser les mmes procduresdempaquetage et de dsempaquetage pour les oprations ayant les mmes signatures. Ceci appor-tera un gain en taille mmoire et peut savrer utile pour les applications embarques.

Enfin, voici quelques conseils que je donne tous ceux qui veulent apporter des modifications oudes optimisations IAC:

Pour les liaisons entre les arbres IDL et Ada, utiliser les fonctions Get_XXXX_Node dclaresdans le paquetage Backend.BE_Ada.Nutilsen priorit sur les fonctions XXXX_Nodedupaquetage Backend.BE_Ada.Nodes. Car les premires contiennent beaucoup de tests etvitent la rplication de code.

Prfrer la fonctionGet_Correct_Parent_Unit_Name du paquetageBackend.BE_Ada.-Nutils la fonction Get_Parent_Unit_Name du paquetage Backend.BE_Ada.Nodesquand cela est possible.

Ne pas hsiter crer ses propres liens entre les deux arbres en suivant la mme dmarcheque pour les liens dj crs.


41/52

Bibliographie

[1] Imran Ahmad and Shikharesh Majumdar. Achieving High Performance in CORBA-BasedSystems with Limited Heterogeneity. InISORC, pages 350359, 2001.

[2] John Barnes. Programmer en Ada 95. Traduction de Hugues Foconnier, 2me dition,Vuibert, 2000.

[3] Zbigniew J. Czech, George Havas, and Bohdan S. Majewski. An Optimal Algorithm forGenerating Minimal Perfect Hash Functions. InInformation Processing Letters, pages 257264, Oct 1992.

[4] Eric Eide, Kevin Frei, Bryan Ford, Jay Lepreau, and Gary Lindstrom. Flick : A Flexible,Optimizing IDL Compiler. InProceedings of the ACM SIGPLAN97 Conferance PLDI, LasVegas, NV, June 1997.

[5] Aniruddha Gokhale and Douglas C. Schmidt. Optimizing a CORBA Inter-ORB Protocol(IIOP) Engine for Minimal Footprint Embedded Multimedia Systems.

[6] The Object Management Group.Ada Language Mapping Specification. Version 1.2, 2001.[7] The Object Management Group. The Common Object Request Broker : Core Specification.

Version 3.0.3, 2004.

[8] Andread Haeberlen, Jochen Liedtke, Yoonho Park, Lars Reuther, and Volkmar Uhlig. Stub-Code Performance is Becoming Important. InProceedings of the 1st Workshop on Industrial

Experiences with Systems Software, San Diego, CA, October 2000.

[9] Michi Henning and Steve Vinoski. Advanced CORBA Programming with C++. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 1999.

[10] Shivakant Mishra and Nija Shi. Improving the Performance of Distributed CORBA Ap-plications. In IPDPS 02 : Proceedings of the 16th International Parallel and Distributed

Processing Symposium, page 184. IEEE Computer Society, 2002.[11] Laurent Pautet. Intergiciels schizophrnes : une solution linteroprabilit entre modles

de rpartition. Habilitation diriger des recherches, Universit Pierre et Marie Curie ParisVI, December 2001.

[12] Thomas Vergnaud, Jrme Hugues, Laurent Pautet, and Fabrice Kordon. PolyORB : A Schi-zophrenic Middleware to Build Versatile Reliable Distributed Applications. InAda-Europe,pages 106119, 2004.

[13] Bechir Zalila. Optimisation Dterminisme et Asynchronisme des Souches et SquelettesCORBA pour Systmes Rpartis Temps-rel. Mmoire bibliographique du stage de Master 2SAR, April 2005.

33


42/52

34 BIBLIOGRAPHIE


43/52

Annexe A : Description de larbreIDL

1 Description gnrale

La partie frontale deIACgnre un arbre syntaxique abstrait qui est une reprsentation plus labo-re de la squence linaire deTokensque sont les sourcesIDL compiler.

Durant le dveloppement de IACla structure de cet arbre subit des volutions, ne serait ce quepour mettre jour le compilateur vers une version plus rcente de la spcificationCORBA. Il estdonc ncessaire que cette mise jour de la structure de larbre seffectue avec le moins de peinepossible pour le dveloppeur. Pour ce faire, seuls les diffrents types de nuds sont donns parle dveloppeurs. Ensuite un programme nommmknodesgnre automatiquement les diffrentssous-programmes qui contrlent lASTet qui permettent de lenregistrer en mmoire. Cette struc-ture est dcrite dans un fichier pseudo-IDLo chaque interface reprsente une entitIDL(interface,module, opration...) et les champs dclars dans chaque interface correspondent aux entits quon

peut trouver dans cette entit et aux proprits de cette entit. Gnralement, chaque interface dansle fichier dcrivant larbre correspond une rgle de la grammaireIDL[7]. Par exemple, les rglesde la grammaire dfinissant la dclaration dune interface sont :

(5) ::= "{" "}"

(7) ::= [ "abstract" | "local" ] "interface"

[ ]

(8) ::= *

(9) ::= ";"

| ";"

| ";"

| ";"

| ";"

| ";"

| ";"

Dans la description de larbre IDLon trouve une description trs similaire pour la dclarationdinterface :

interface Interface_Body : List_Id {};

interface Interface_Declaration : Scope_Definition {boolean Is_Abstract_Interface;

boolean Is_Local_Interface;

35


44/52

36 ANNEXE A : DESCRIPTION DE LARBREIDL

List_Id Interface_Spec;

List_Id Interface_Body;

List_Id Type_Prefixes;

};

Linterface Scope_Definitionqui est le parent de Interface_Declarationest dclare aussidans le mme fichier et dcrit le nom des entits IDL. On remarque la similarit entre les deux typesde dclarations lexception de lordre car en IDLon ne peut utiliser que des entits dclaresauparavant.

2 Avantages par rapport lASTdeIDLAC

DansIDLAC, la construction des paquetages relatifs larbreIDLest elle aussi faite de faon auto-matique mais un peu plus primitive que dans IAC. Dans les deux compilateurs, le type reprsentantun nud de larbre est un enregistrement et larbre est une table denregistrement instancie partirdu paquetage gnrique GNAT.Table. Dans le cas deIDLAC, lensemble des champs contenus danslenregistrement est lunion (au sens ensembliste du terme) des champs de tous les types de nuds.Par exemple, le nud correspondant unattributecontient un champ boolenIs_Readonlyet lenud correspondant une interface contient un champ boolen Local. Dans lenregistrementreprsentant un nud de larbreIDL, on verra :

type Node_Type is record

...Is_Readonly : Boolean;

...

Local : Boolean;

...

end record;

En appliquant ce procd tous les types de nuds possibles, on obtient un enregistrement quicontient 77 champs ce qui est trs pnalisant et trs coteux en taille mmoire.

DansIAC, une optimisation a t faite pour diminuer considrablement le nombre de champs dans

lenregistrement reprsentant un nud de larbre IDL. Lide est la suivante : pour deux typesde nuds contenant un champ de mme type mais de noms diffrents, il serait intressant depouvoir confondre les deux champs dans lenregistrement qui contient dsormais des tableauxreprsentant le nombre maximal de champs dun type donn prsents dans un type de nud donn.On obtient un enregistrement qui est beaucoup plus compact et qui ne contient que 5 champs donttrois tableaux dont les longueurs sont calcules la gnration des paquetages pour larbreIDL:

type Boolean_Array is array (1 .. 2) of Boolean;

type Byte_Array is array (1 .. 1) of Byte;

type Int_Array is array (1 .. 10) of Int;

type Node_Entry is record

Kind : Node_Kind;


45/52

3. ENTITS GNRES 37

B : Boolean_Array;

O : Byte_Array;

L : Int_Array;

Loc : Location;end record;

Ceci rduit considrablement le nombre de champs prsents dans lenregistrement 15, soit 5fois plus petit que IDLAC. Tout ceci est bien entendu fait de faon automatique et transparente etlutilisateur naura pas grer les index dans les tableaux : des "accesseurs" pour chaque entitdun type de nud sont gnrs. Cest lobjet de la partie qui suit.

3 Entits gnres

Le programmemknodesParse le fichier frontend-nodes.idl(pseudo-IDL) en utilisant le lexeuret le parseur de IAC(cfII.1.1.1). Le rsultat est un paquetageAdaappel Frontend.Nodesquicontient, pour chaque champ dclar dans une interface du fichier IDL, deux "accesseurs" pourpouvoir lire et modifier la valeur de ce champ. Cest dans ces "accesseurs" quest faite la rsolutiondes index des tableaux. Par exemple, pour le champ boolen Is_Abstract_Interfaceindiquantsi une interface est abstraite, deux sous programmes sont gnrs :

function Is_Abstract_Interface (N : Node_Id) return Boolean;

procedure Set_Is_Abstract_Interface (N : Node_Id; V : Boolean);

De plus, pour permettre un dbogage facile de IACchaque sous programme contient un ensembledassertions au dbut pour vrifier si le champ auquel on veut accder existe vraiment dans le typede nud donn en paramtre du sous-programme :

function Is_Abstract_Interface (N : Node_Id) return Boolean is

begin

pragma Assert (False

or else Table (Node_Id (N)).Kind = K_Forward_Interface_Declaration

or else Table (Node_Id (N)).Kind = K_Interface_Declaration);

return Boolean (Table (Node_Id (N)).B (1));

end Is_Abstract_Interface;

Le paquetage Frontend.Nodescontient aussi des sous programmes qui servent crire chacundes nuds si le dveloppeur dsire regarder larbreIDLgnr.


46/52

38 ANNEXE A : DESCRIPTION DE LARBREIDL


47/52

Annexe B : Description de larbreAda

1 Description gnrale

Avant la gnration de code Ada, et pour rendre le compilateurIACplus flexible, il y a une phasede transformation de larbreIDLen un arbreAda.

La structure de larbre est fortement inspire de la structure de lASTde GNATdcrite dans lefichiersinfo.adsdans les sources du compilateurAdamais seulement une partie de cette struc-ture est utilise dans la partie dorsale deIAC(suffisamment pour pouvoir gnrer les structures dedonnes des souches et des squelettes).

Comme pour larbre IDL, la structure de larbre Adaest dcrite dans un fichier pseudo-IDLochaque interface reprsente une entitAda(appel un sous-programme, dclaration dobjet, sp-cification dun paquetage...) et les champs dclars dans chaque interface correspondent aux enti-

ts quon peut trouver dans cette entit et aux proprits de cette entit. Les paquetages Ada quipermettent de construire et de manipuler larbreAda sont gnrs automatiquement par le mmeprogrammemknodesqui gnre les fichiers relatifs larbreIDL.

Ci-dessous, un petit exemple prsente comment est dcrite la structure conditionnelleif dans lefichier backend-be_ada-nodes.idl:

interface If_Statement : Node_Id {

Node_Id Condition;

List_Id Then_Statements;

List_Id Elsif_Statements;

List_Id Else_Statements;

};

Ensuite, pour crer une telle structure, on commence par crer les diffrentes parties qui la com-posent, et finalement on appelle la fonction :

function Make_If_Statement

(Condition : Node_Id;

Then_Statements : List_Id;

Elsif_Statements : List_Id := No_List;Else_Statements : List_Id := No_List)

return Node_Id;

39


48/52

40 ANNEXE B : DESCRIPTION DE LARBREADA

Le nud retourn par cette fonction est de type K_If_Statement et il reprsente la structureconditionnelle cre. On pourra lajouter dans larbreAda laide des diffrentes mthodesMake-_XXXXdu paquetage Backend.BE_Ada.Nutilsou directement en utilisant la procdureAppend-

_Node_To_Listdu mme paquetage si on sait exactement o ajouter le nud.

2 Liaisons entre les deux arbres

Comme il a t prcis dansII.1.1.2, la construction de larbreAdaseffectue en parcourant larbreIDLun certain nombre de fois, et il arrive trs souvent quon utilise des nuds dj crs. Cetteutilisation est rendue possible grce des liaisons cres entre les deux arbres. Prenons lexempleIDLsuivant :

interface myInt {

typedef MyStr string;

MyStr echoString (in MyStr data);

};

Lors du parcours pour gnrer le paquetageHelperde linterfacemyInt,IACgnre les fonctionTo_Anyet From_Anypour le typeMyStr. Ces deux fonctions sont utilises dans la souche et dansle squelette. Pour pouvoir accder ces fonctions et plusieurs autres entits, IACcre une liaisonentre le dclarateurMyStret les deux nuds des deux fonctions. Cette liaison est rendue possibleen ajoutant un nouveau champsBE_Nodepour le nud Identifierde larbreIDL:

interface Identifier : Node_Id {

...

Node_Id BE_Node;

// Links nodes together

};

Ce nouveau champ pointe vers un nud de type BE_Ada de larbre Ada qui contient commechamps, les diffrents nuds vers lesquels il peut y avoir une liaison :

interface BE_Ada : Node_Id {

Node_Id Stub_Node;

Node_Id Helper_Node;

Node_Id Skel_Node;

Node_Id Impl_Node;

Node_Id TC_Node;

Node_Id From_Any_Node;

Node_Id To_Any_Node;

Node_Id To_Ref_Node;

Node_Id U_To_Ref_Node;

Node_Id Type_Def_Node;Node_Id Forward_Node;

Node_Id BE_Ada_Instanciations;


49/52

2. LIAISONS ENTRE LES DEUX ARBRES 41

Node_Id From_CDR_Node;

Node_Id To_CDR_Node;

Node_Id Set_Args_Node;

};

Le fait de passer par un nud intermdiaire permet de simplifier la structure de larbre IDL. Lesens inverse de la liaison existe :

interface Node_Id {

Node_Id Next_Node;

Node_Id FE_Node;

};

Cette faon de lier les deux arbres simplifie beaucoup la construction de larbreAda et vite dycrer des nuds identiques. Il existe cependant des situations o on est oblig de crer des nudsidentiques dans larbreAda ; par exemple, un mme nud ne peut tre prsent dans deux listesdiffrentes car la structure de la liste repose sur le champNext_Nodeet un nud ne possde quunseul champNext_Node. Pour cette raison, la fonctionCopy_Nodeest utilise pour crer des copiesidentiques de certains types de nuds.


50/52

42 ANNEXE B : DESCRIPTION DE LARBREADA


51/52

Annexe C : Cas particulier du moduleCORBA

La description du module particulier CORBAexiste dans le chapitre 5 des spcifications du map-ping Ada de CORBA[6]. Ce module contient les dclarations de plusieurs entits vitales pour lefonctionnement de lintergiciel (cration de requtes,DII,Repository_Id, exceptions systme...). Ilcontient aussi la dfinition de types squences pour la plupart des types de base CORBA. Toutesces entits sont dcrites dans un fichier particulier appelorb.idl.

Les spcifications du mapping donnent la plupart des spec Ada gnrer. La plupart du temps, lecode qui doit tre gnr est diffrent du code gnr pour un fichierIDL classique. Pour ces parties,le codeAdaa t crit manuellement (et non gnr automatiquement) lors du dveloppement dela personnalitCORBAde PolyORB. Cependant il peut se trouver quun fichier sourceIDLincluele fichier orb.idlpour pouvoir utiliser les entits qui y sont dcrites. Il faut donc empcher lecompilateurIDLde gnrer du codeAdapour les parties crites manuellement, tout en gnrant le

bon code pour le fichier source classique. Ajoutons cela que certaines partie du modules CORBAsont crites en pseudo-IDLet certaines autres ne respectent pas la grammaire et nous nous trouvonsdevant un problme trs difficile. Dans ce qui suit, je donnerai la description de la manire dont lemoduleCORBAest analys et des diffrentes anomalies de syntaxe et de smantique prsentes dansle fichierorb.idl.

1 Modification de larbreIDL

Comme il a t dit prcdemment, des types squences pour les types de bases sont dclarsdans le module CORBA. Lutilisation de ces types est trs rare par les applications rparties. Sa-chant que toutes les applica

Documents

Rapport Master Bechir Zalila