Vous êtes sur la page 1sur 52

Mmoire de stage

Master Systmes et Applications Rpartis

Optimisation, Dterminisme et Asynchronisme des


Souches et Squelettes CORBA pour Systmes Rpartis
Temps-Rel

tudiant :

Responsables du stage :

Bechir ZALILA

Laurent PAUTET
Fabrice KORDON

15 Septembre 2005

ii

Table des matires


Remerciements

Rsum
I

vii

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

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

1
1
1
3
4

II Conformit au standard CORBA 3.0


II.1 Compilateur prototype IAC 1.0 . . . . . . . . . . . . . . . .
II.1.1 Ancienne architecture de IAC . . . . . . . . . . . . .
II.1.1.1 La partie frontale . . . . . . . . . . . . .
II.1.1.2 La partie dorsale . . . . . . . . . . . . . .
II.1.2 Avantages par rapport IDLAC . . . . . . . . . . . .
II.1.3 Limitations . . . . . . . . . . . . . . . . . . . . . .
II.1.3.1 Les fonctionnalits manquantes . . . . . .
II.1.3.2 Les dfauts darchitecture . . . . . . . . .
II.2 Nouvelle architecture . . . . . . . . . . . . . . . . . . . . .
II.2.1 Nouveau schma de fonctionnement . . . . . . . . .
II.2.1.1 Expansion de code . . . . . . . . . . . . .
II.2.1.2 Factorisation de code . . . . . . . . . . .
II.2.2 Fonctionnalits implmentes dans la partie frontale
II.2.3 Fonctionnalits implmentes dans la partie dorsale .
II.2.3.1 Fonctionnalits compltes . . . . . . . .
II.2.3.2 Fonctionnalits Ajoutes . . . . . . . . .
II.2.4 Validation de la conformit . . . . . . . . . . . . . .

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

7
7
8
8
10
12
13
13
13
13
14
14
15
15
16
16
16
19

.
.
.
.
.
.
.
.

21
21
22
22
23
23
25
25
28

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

III Vers un intergiciel optimis et dterministe


III.1 Utilisation des tables de hachage minimales parfaites
III.1.1 Approche . . . . . . . . . . . . . . . . . . .
III.1.1.1 Premire approche . . . . . . . . .
III.1.1.2 Deuxime approche . . . . . . . .
III.1.2 Gains obtenus . . . . . . . . . . . . . . . . .
III.2 Limplmentation de la SII . . . . . . . . . . . . . .
III.2.1 Approche . . . . . . . . . . . . . . . . . . .
III.2.2 Gains obtenus . . . . . . . . . . . . . . . . .
iii

.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

iv

TABLE DES MATIRES

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

31
31
31

Bibliographie

33

Annexe A : Description de larbre IDL


1
Description gnrale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
Avantages par rapport lAST de IDLAC . . . . . . . . . . . . . . . . . . . . . .
3
Entits gnres . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

35
35
36
37

Annexe B : Description de larbre Ada


1
Description gnrale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
Liaisons entre les deux arbres . . . . . . . . . . . . . . . . . . . . . . . . . . . .

39
39
40

Annexe C : Cas particulier du module CORBA


1
Modification de larbre IDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
Anomalies dans orb.idl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

43
43
44

Remerciements
Je tiens exprimer mes remerciements les plus sincres M. Laurent PAUTET pour mavoir accueilli dans son quipe pendant ce stage et pour les comptences que jai acquises dans le domaine
de 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 aides
et conseils quils mont apports.
Finalement, je remercie mes collgues stagiaires pour les agrables cinq mois et demi que jai
pass avec eux.

vi

REMERCIEMENTS

Rsum
Dans le cadre de mon Master Systmes et Applications Rpartis lUniversit Pierre et Marie
Curie, jai effectu un stage de six mois dans le dpartement INFRES de Telecom Paris. Ce rapport
dcrit le travail effectu pendant le stage ainsi que les rsultats obtenus.
Le stage, qui sintitule : Optimisation, Dterminisme et Asynchronisme des Souches et Squelettes
CORBA pour Systmes Rpartis temps-rel, consiste :

Dans un premier temps complter limplmentation de IAC (Idl to Ada Compiler), le


nouveau compilateur IDL de lintergiciel schizophrne PolyORB. IAC remplacera IDLAC,
lancien compilateur de PolyORB en raison de la difficult de la maintenance de ce dernier.
Dans un second temps, proposer puis mettre en uvre des optimisations qui augmenteront les performances des souches et des squelettes gnrs par ce compilateur.

vii

viii

RSUM

Chapitre I

Introduction
I.1 Autour de la problmatique du temps rel
Linformatique temps-rel permet de dvelopper des applications qui doivent respecter des contraintes
temporelles plus ou moins strictes (temps rel dur vs. temps rel souple). Une des principales caractristiques dune application temps-rel est le dterminisme, ce qui veut dire que les temps
dexcution des diffrentes actions doivent tre borns.
Quand le besoin du temps-rel est exprim par une application rpartie, le dterminisme est plus
difficile 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 sur
des 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 sexcutant sur des plates-formes diffrentes et ventuellement crites dans des langages de programmation diffrents. Tout ceci en pargnant au dveloppeur la programmation de la partie communication proprement-dite et en le laissant se concentrer sur ce que doit effectivement faire son
application rpartie. Dans le monde des intergiciels, CORBA (Common Object Request Broker Architecture) 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 performances 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 intergiciels.

I.2 Autour des optimisations dans les intergiciels


Le standard CORBA repose sur la philosophie suivante :
Le client et le serveur peuvent tre dvelopps dans des langages de programmation diffrents et tourner sur des plates-formes diffrentes.
1

CHAPITRE I. INTRODUCTION

Fichier IDL
Implementation
Repository

Interface
Repository
Compilateur IDL

in args + inout args

Serveur

Opration()

Client
Obj
Ref

Object (Servant)
out args + inout args

Squelette
IDL

DII

Souche
IDL

DSI

Interface de
LORB

Adapteur DObjet

ORB Core

GIOP/IIOP

F IGURE I.1 Architecture gnrale de CORBA


La localisation de lobjet distant est faite de faon transparente par rapport au client. Ceci
veut dire que dans le code du client dvelopp par le programmeur, il ny a aucune rfrence ladresse du serveur (qui peut dailleurs changer entre deux excutions successives
du 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-synchrone
et asynchrone).
La figure I.1 donne un aperu global de larchitecture CORBA. Pour construire une application
rpartie reposant sur ce standard, le dveloppeur dcrit les relations entre les diffrentes entits de
lapplication (les interfaces de lapplication) dans un langage de description darchitectures (IDL).
Gnralement, chaque intergiciel dispose de son propre langage de description dinterfaces. Le
standard CORBA dcrit son langage IDL dans le chapitre 3 de la spcification [7].
Un compilateur IDL se charge de gnrer le code qui dcrit la partie communication entre le client
et le serveur (les souches et les squelettes).
Durant les dernires annes, le dbit du transfert des donnes dans les rseaux est devenu plus
grand et ne constitue plus un goulot dtranglement pour lapplication rpartie. Dsormais, cest le
code de lapplication elle-mme qui doit tre optimis. En particulier, le code gnr par les compilateurs IDL a besoin dtre trs performant pour ne pas dgrader les performances de lapplication
rpartie.
Lintergiciel utilis dans le cadre de ce stage est lintergiciel schizophrne PolyORB. La schizophrnie dans le domaine des intergiciels a t introduite pour permettre linteroprabilit entre
diffrents modles de rpartition (Middleware To Middleware). Ainsi, un intergiciel schizophrne
instancie simultanment plusieurs personnalits et leur permet de cohabiter et dinteragir [11].
Comme toute implmentation classique de la spcification publie par lOMG, la personnalit
CORBA de PolyORB souffre de quelques problmes dcrits longuement dans le mmoire bibliographique qui a prcd le stage [13]. Les principaux problmes dont souffre une application

I.3. AUTOUR DES ARCHITECTURES DE COMPILATEURS

rpartie conue selon le standard CORBA sont :


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 traitements
faits lors de lexcution dune requte ne sont pas toujours ncessaires (cas o le client et le
serveur sexcutent sur la mme plate-forme). La personnalit CORBA ajoute cela le fait
quelle utilise un mcanisme dynamique de traitement des requtes qui a, certes, lavantage
de pouvoir omettre de prciser le type des donnes changes lors de la compilation mais
qui introduit un dlai supplmentaire non ngligeable lors du traitement des requtes.
Lindterminisme : en effet, le temps dexcution des requtes dpend fortement de la
signature de lopration correspondante la requte et du nombre total doprations dans
une mme interface de lapplication rpartie.
La grande empreinte mmoire de lapplication rpartie qui est aussi due labstraction de
lhtrognit des diffrentes entits.
Le synchronisme qui peut parfois tre considr comme une limite. Le traitement par dfaut des requtes dans CORBA est synchrone. Il existe des types doprations dites oneway
qui permettent au client de poursuivre son excution juste aprs lenvoi de la requte sans
se bloquer, mais ce type dasynchronisme ne peut sappliquer quaux oprations qui ne
retournent pas de rsultat au client.
La taille des messages changs par les diffrentes entits de lapplication rpartie est
grande et implique un temps dexcution long des requtes.
Pour chacun des problmes de CORBA voqus, des solutions (des optimisations) ont t proposes dans le mmoire bibliographique [13] en se basant sur diffrents travaux de recherches sur le
standard CORBA.
La principale partie de lintergiciel qui doit tre optimise tant le compilateur IDL, il faut que
celui-ci soit trs bien conu au dpart et quil soit, de plus, facilement maintenable pour pouvoir y
intgrer les optimisations avec le moins de peine possible.

I.3 Autour des architectures de compilateurs


Le compilateur IDL de PolyORB sappelle IDLAC (IDL to Ada Compiler). IDLAC possde larchitecture classique dun compilateur :
Une partie frontale "Parse" le fichier source IDL, vrifie sa syntaxe et gnre un arbre syntaxique abstrait (AST). Cet arbre subit une expansion pour le rendre plus explicite et pour
faciliter la gnration de code partir de cet arbre.
Une partie dorsale qui prend en entre lAST et qui gnre du code Ada conformment aux
spcifications du mapping Ada publies par lOMG [6].
IDLAC a subi plusieurs modifications au fur et mesure de lvolution de lintergiciel PolyORB.
chaque modification, le compilateur devient de plus en plus complexe. Actuellement, IDLAC est un
compilateur trs difficilement maintenable et souffre de plusieurs anomalies de fonctionnement.
Ces proprits de IDLAC se situent aux antipodes des proprits attendues dans un compilateur
pour faciliter son optimisation.

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

CHAPITRE I. INTRODUCTION

du dveloppement de IDLAC. IAC, (Idl to Ada Compiler) est un nouveau compilateur IDL qui est
cens remplacer IDLAC dans PolyORB la fin de ce stage. La partie frontale de IAC a t dveloppe pendant lt 2003. Ses petites diffrences par rapport la partie frontale de IDLAC seront
dtailles dans le chapitre III. Le dveloppement de la partie dorsale de IAC a commenc en 2004
dans le cadre dun stage de DEA. Larchitecture de cette partie est totalement diffrente de celle
de IDLAC. Elle utilise le concept novateur de transformation darbre. Ce concept sera dtaill lors
de la description de larchitecture de IAC dans le chapitre III.
Lobjectif de ce stage est de :
1. Achever la conception de IAC en le mettant niveau vers la version la plus rcente de
CORBA et 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 diffrente de la construction des applications classiques (aussi complexes soient-elles). Il ma
fallu donc une priode dapprentissage pour mapproprier les sources de IAC et pour me
familiariser avec les concepts utiliss pour ensuite pouvoir men servir durant le dveloppement.
2. Proposer et implmenter des optimisations dans IAC en sinspirant du travail de recherche
effectu dans le mmoire bibliographique. A lissue de cette phase, les applications rparties dont les souches et les squelettes ont t gnrs avec IAC devraient tre nettement plus
performantes que les applications dveloppes laide de IDLAC.

I.4

Description du mmoire

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


Dans le chapitre II, je dcrirai larchitecture de dpart de IAC, je prsenterai ses avantages par
rapport larchitecture de IDLAC. Ensuite je prsenterai les modifications et les ajouts que jai t
amen implmenter dans IAC pour le mettre niveau vers la dernire version du standard CORBA
notamment le nouveau schma de fonctionnement de IAC qui intgre un expanseur darbre (II.2.1).
Je listerai ensuite les nouvelles fonctionnalits ajoutes IAC pour le mettre niveau par rapport
IDLAC.
Le chapitre III prsente les optimisations qui ont t retenues et implmentes dans IAC : Lutilisation des fonctions de hachage minimales parfaites pour garantir le dterminisme dans le temps
dexcution des requtes et loptimisation du traitement des requtes en utilisant des mthodes
statiques la place des mthodes dynamiques qui taient les seules utilises par PolyORB. Pour
chaque optimisation, je dcrirai lapproche utilise pour son implmentation et je donnerai les
gains en performance obtenus.
Le chapitre IV conclue ce mmoire et prsente les diffrentes perspectives qui souvrent devant
IAC. Il y aura notamment une listes de fonctionnalits utiles implmenter dans le futur et une
explication sur la manire de faire voluer IAC.
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 les
langages IDL et Ada. Ces descriptions sont crites en "PSEUDO IDL " et un programme

I.4. DESCRIPTION DU MMOIRE

spcial (mknodes) gnre les paquetages Ada ncessaires pour la construction et la manipulation de ces arbres.
Lannexe C dcrit le cas particulier du module CORBA existant dans le fichier "orb.idl"
et les dispositions spciales qui ont t prises dans IAC pour rendre possible lanalyse de
ce module.

CHAPITRE I. INTRODUCTION

Chapitre II

Conformit au standard CORBA 3.0


IAC (Idl to Ada Compiler) est un gnrateur de code Ada partir de descriptions IDL. Il est destin
remplacer IDLAC car il est plus volutif que lui. En effet, le dveloppement de IAC a t fait de
faon plus structure que celle de IDLAC. Les sparations entre diffrentes parties du compilateur
sont plus claires. De plus, IAC peut facilement tre tendu pour gnrer des souches et des squelettes dans un langage autre que Ada partir du langage IDL (mais le nom naurait plus une grande
signification dans ce cas).

Bien entendu, IAC na pas t dvelopp partir de zro : plusieurs parties bien faites de IDLAC
ont t amliores et intgres dans IAC telles que la gestion des erreurs et des avertissements, le
mcanisme de lanalyse de fichiers, la sparation de Parser et Lexer. Certaines parties de IAC,
comme le mcanisme de construction de lAST (Abstract Syntax Tree) ont t reprises ou inspires
des sources du compilateur Ada GNAT. La partie dorsale de IAC est diffrente de celle de IDLAC,
elle permet davoir plus de flexibilit et de maintenabilit pour le compilateur.
Au dbut du stage, le niveau de IAC ntait pas aussi avanc que celui de IDLAC. Il implmentait la
plupart du langage IDL, mais la version de CORBA dont il sagissait ntait pas la dernire comme
cest le cas pour IDLAC. La version de dpart de IAC implmente la grammaire IDL publie dans
la version 2.3 de la spcification de CORBA (rgles 1 98). Par exemple, IAC ne gnrait pas
tous les sous-paquetages Helper qui contiennent des mthodes utiles pour la conversion de types.
La mme remarque est valable pour les paquetages _IDL_File qui regroupent les entit dclares
lextrieur de tout module et de toute interface. Pour tous ces paquetages, IAC se contentait de
gnrer des squelettes (des paquetages vides) de fichiers.
La premire phase du stage a consist mettre IAC niveau pour quil implmente la gnration de code pour la dernire version de la spcification CORBA (3.0.4). Hormis le fait que cette
phase a mis IAC niveau par rapport IDLAC, elle ma permis de mapproprier ses sources et de
comprendre les mcanismes et les technologies de dveloppement des compilateurs en lesquels je
navais pas une grande exprience au dbut du stage.

II.1 Compilateur prototype IAC 1.0


Comme IDLAC et comme tout autre compilateur, IAC se compose dune partie frontale (frontend)
et dune partie dorsale (backend). Le dveloppement de ces deux parties dans IAC a t fait dune
7

CHAPITRE II. CONFORMIT AU STANDARD CORBA 3.0

faon plus modulaire que dans IDLAC.


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. Toutes
les manipulations de chanes de caractres en partant de lanalyse du fichier source IDL jusqu la
gnration de code Ada utilisent le paquetage Namet qui offre toutes les mthodes ncessaires. Ce
niveau dabstraction emprunt des sources du compilateur Ada GNAT permet au dveloppeur de
slever dun cran dans la construction de IAC. Il est aussi noter que la majorit crasante des
types de donnes utiliss dans IAC sont des types personnaliss ce qui constitue un autre niveau
dabstraction qui va assurer une dpendance vis--vis des diffrentes architectures et une flexibilit
du compilateur.

II.1.1 Ancienne architecture de IAC


Avant de dtailler larchitecture de IAC, il est important de parler dune des phase les plus importantes 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 langage trait, en loccurrence le langage IDL dans notre cas. Son principal effet est dinclure des
dfinitions partir dautres fichiers source (par le biais de la directive #include) et de supprimer ou garder des portions de code selon les options donnes en ligne de commande (directive
#ifdef par exemple). Le Preprocessing peut tre implment dans le compilateur IDL comme il
peut tre effectu en utilisant un programme indpendant. IDLAC et IAC utilisent tous les deux le
pr-processeur de GCC pour traiter toutes les directives lexception de #pragma qui nest pas
reconnue par le pr-processeur C++.
lissue de la phase de Preprocessing, on obtient une suite de Tokens (cest le terme utilis dans
la spcification de CORBA pour dfinir les diffrentes entits existant dans un fichier source IDL).
Il existe cinq catgories de Tokens :

Les identificateurs : qui servent nommer les modules, les interfaces...


Les mots-cls : qui sont la base du langage IDL.
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...

LOMG dfinit pour certains types de Tokens des 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 langage IDL (chapitre 3 de [7])
que la partie frontale de IAC va traiter un fichier source IDL et produire une sortie correcte utilisable
par la partie dorsale.

II.1.1.1

La partie frontale

Le fonctionnement de la partie frontale de IAC est similaire celui de tout autre compilateur. En
entre, la partie frontale reoit un fichier source IDL crit conformment la grammaire du langage
spcifie par lOMG. La sortie principale de cette partie est un arbre reprsentant la structure du
fichier : larbre syntaxique abstrait (Abstract Syntax Tree). Les sorties secondaires de la partie
frontale consistent en dventuels avertissements ou messages derreurs. La figure II.1 donne un

II.1. COMPILATEUR PROTOTYPE IAC 1.0

Fichier source
IDL

Partie Frontale
de IAC

Arbre Syntaxique
Abstrait
Avertissments
Erreurs

F IGURE II.1 Partie frontale de IAC : fonctionnement global

aperu global sur le fonctionnement de la partie frontale de IAC.


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

Le Lexeur : Cette partie parcourt le fichier source IDL caractre par caractre et essaie de reconnatre les diffrents Tokens rencontrs (identificateur, mot-cl, valeur littrale...). Chaque
demande cette partie davancer dans le traitement du fichier et de vrifier le prochain
token met jour un ensemble de variable indiquant le type du token, lidentificateur de son
nom dans la table des noms et la valeur sil sagit dune valeur littrale. Une des proprits
la fois intressante et utile de IAC est quon peut enregistrer un moment donn ltat
du lexeur, ensuite revenir vers cet tat un moment ultrieur. Cette fonctionnalit facilite
beaucoup le traitement dun fichier source IDL.
Le Parseur : Les routines prsentes dans cette partie utilisent le lexeur et la grammaire IDL pour
vrifier la syntaxe du fichier source IDL et construire lAST. Globalement, pour chaque
rgle de la grammaire IDL [7], il existe une fonction Parse_XXXX qui appelle les routines
du lexeur et construit une partie de lAST. Leffet principal du parseur est de transformer les sources IDL dune squence linaire de Tokens en une structure arborescente forme de plusieurs nuds. La racine des source IDL tant la spcification, le point dentre
vers le parseur de IAC est donc la fonction Parse_Specification qui, selon la nature
des Tokens que le lexeur lui envoie, appelle les fonctions Parse_XXXX correspondantes.
La fonction Parse_Specification retourne la racine de lAST qui est un nud de type
K_Specification. La structure de larbre IDL ainsi que les mcanismes mis en uvre
pour sa gnration sont expliqus dans lannexe A de ce mmoire.
LAnalyseur : Larbre IDL construit par le parseur vrifie certes la grammaire IDL mais la smantique nest pas ncessairement vrifie. Il se peut par exemple que certaines constantes
dclares aient des valeurs qui se situent lextrieur de lintervalle de leur type. Lanalyseur vrifie la smantique des sources IDL. Il complte aussi la construction de certaine
parties de larbre qui ne peuvent tre ajoutes que si le parseur a parcouru tout le fichier
source (les forward interface et la rsolution des noms par exemple).

lissue de lanalyse de la partie frontale, on obtient un arbre de syntaxe reprsentant la structure


des sources IDL. Cet arbre va constituer lentre de la deuxime partie de IAC : la partie dorsale.

CHAPITRE II. CONFORMIT AU STANDARD CORBA 3.0

10

Fichier source
IDL

Lexeur
Squence linaire
de Tokens

Contrle

Erreurs et avertissements
de syntaxe

Parseur
Erreurs et avertissements
de smantique

Arbre IDL
incomplet

Ananlyseur
AST

F IGURE II.2 Partie frontale de IAC : dtails


II.1.1.2

La partie dorsale

Comme il a t dit prcdemment, IAC a t construit pour supporter plusieurs parties dorsales. Le
choix du backend utilis nest donc pas fig dans les sources du compilateur comme cest le cas
pour IDLAC. Avec la ligne de commande, on choisi le backend laide de loption de compilation
-<lang> dans laquelle <lang> dsigne un langage de programmation support par IAC. Dans ltat
actuel des choses, IAC dispose de deux parties dorsales :
1. Une partie dorsale IDL servant gnrer un fichier source IDL partir de larbre syntaxique construit dans la partie frontale. Ceci sert vrifier le bon fonctionnement de la partie
frontale.
2. Une partie dorsale Ada qui gnre les souches et les squelettes CORBA conformment aux
spcifications de mapping [6]. Cest cette partie qui a constitu lobjet principal du travail
durant le stage. partir de ce moment, et dans le reste du mmoire, le terme "Partie dorsale
de IAC " dsigne la partie dorsale relative au langage Ada.
La partie dorsale de IAC est diffrente de celle de IDLAC. Alors que dans IDLAC, la gnration de
code se rsume des Put_Line, IAC adopte une autre stratgie : partir de larbre IDL gnr dans
la phase frontale de la compilation, le compilateur gnre un arbre Ada qui contient la description
des souches et squelettes implmenter.
La partie dorsale est donc dcoupe en deux parties principales (cf figure II.3) :

II.1.1.2.1 Construction de larbre Ada Dans cette partie, larbre IDL est parcouru un nombre
de fois gal au nombre de types de paquetages Ada qui doivent tre gnrs. Pour gnrer les
souches, les Helpers, les squelettes et les implmentations, il faut donc parcourir larbre IDL 4 fois.
Il faut noter que larbre Ada na pas une seule racine comme il est le cas pour larbre IDL, mais il
dispose dune liste de racines (4 si on ne gnre que les souches, les Helpers, les squelettes et les
implmentations). Chacune de ces racines est gnre lors dun parcours de lAST. Pour plus de
dtails concernant la structure de larbre Ada et la manire dont il est construit, voir lAnnexe B
de ce mmoire.

II.1. COMPILATEUR PROTOTYPE IAC 1.0

11

Partie dorsale de IAC

Arbre
IDL

Construction de
larbre Ada
Arbre
Ada

Gneration du
Code Ada

Code Ada

F IGURE II.3 Partie dorsale de IAC : fonctionnement global


Lordre de la construction des paquetages est crucial. Tout dabord il faut construire toutes les spcifications de paquetages avant les corps de ces paquetages parce que les branches correspondant
aux corps utilisent des nuds de la branche correspondant aux spcifications. Par exemple pour
construire le corps dun sous-programme, on ne construit pas une nouvelle spcification mais on
utilise celle cre lors de la construction de la partie spcification. Ceci va diminuer le nombre
total de nuds dans larbre Ada.
De plus, certains types de paquetages utilisent des entits dclares dans dautres types. Par exemple,
les Helpers utilisent les entits dclares dans les souches, les corps des squelettes utilisent des entits des spcifications des Helpers et des implmentations. Lordre de construction qui respecte
ces dpendances est le suivant :
1. Construction des spcifications des Souches
2. Construction des spcifications des Helpers
3. Construction des spcifications des Implmentations
4. Construction des spcifications des Squelettes
5. Construction des corps des Souches
6. Construction des corps des Helpers
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, les
deux arbres IDL est Ada sont lis et les Bindings ncessaires sont crs au fur et mesure de la
construction de larbre Ada (voir lannexe B pour plus de dtails sur les Bindings entre les deux
arbres).
Une deuxime amlioration consiste grer de faon abstraite les noms des paquetages de lAPI
CORBA. Toutes les entits sont dclares dans un paquetage spar (Backend.BE_Ada.Runtime).

12

CHAPITRE II. CONFORMIT AU STANDARD CORBA 3.0

Si une entit change de lieu dans lAPI, il suffit deffectuer la modification dans ce paquetage. De
plus la gestion de la clause with est effectue de faon tout fait transparente pour lutilisateur :
la fonction Expand_Designator du paquetage Backend.BE_Ada.Expand qui sert gnrer des
identificateurs compltement qualifis ajoute les clauses with ncessaires au paquetage courant
tout en sassurant de la non duplication dune mme clause.

II.1.1.2.2 Gnration du code Ada Une fois larbre Ada construit, la gnration du code seffectue en appelant la mthode Generate du paquetage Backend.BE_Ada.Generator sur la listeracine de larbre Ada. Cette mthode effectue des appels dispatchant vers les diffrentes mthodes
Generate_XXXX selon 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 leur
fonctionnement. Celle de IAC tant dcrite en II.1.1.1, voici une brve description de la partie
dorsale de IDLAC :
Avant de gnrer le code partir de larbre IDL construit dans la partie frontale, il faut savoir que
les informations contenues dans cet arbre sont incompltes. En effet, il existe plusieurs donnes
implicites qui nont pas t reprsentes dans larbre comme les oprations et les attributs hrits
par une interface, les membres dune exception... La phase de lexpansion consiste ajouter les
donnes 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 mais
ceci va beaucoup compliquer cette dernire phase.
Aprs la phase dexpansion, arrive la dernire phase qui est la phase de gnration de code. Lors
de cette phase, larbre IDL est parcouru en profondeur et le code ncessaire pour chaque nud est
gnr en respectant les spcifications du mapping Ada publies par lOMG [6]. Cette manire trs
intuitive 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 corps
dune procdure, il faut imprativement gnrer toute la partie dclarative avant la partie
instructions, ou encore, dans un paquetage, il faut ajouter toutes les clauses with ncessaires manuellement au dbut. Ceci pose beaucoup de contraintes si on veut implmenter
des optimisations dans le compilateur : lendroit o implmenter ces optimisations sera
impos par le fait que le code est gnr de faon linaire. Ce qui va ventuellement rendre
les sources du compilateur trs difficiles comprendre.
Puisque la plus grande partie du code est gnre en utilisant des appels la procdure
Put_Line, la maintenabilit du compilateur est mise en question. Par exemple, si lAPI
pour laquelle le code est gnr est modifie, plusieurs modifications doivent tre effectues sur IDLAC.
Le fait de sparer dans IAC la partie traitement des donnes de la partie gnration de code apporte
une 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 et
des listes quil peut modifier volont tant que la phase gnration de code na pas t entame.
Le mcanisme dajout des clauses with profite pleinement de ce concept.

II.2. NOUVELLE ARCHITECTURE

13

De plus, la liaison (Binding) effectue entre larbre IDL et larbre Ada permet daccder des
nuds dj cres et de les utiliser sans devoir crer de nouveaux nuds. Ceci contribue diminuer
le nombre de nuds dans larbre Ada.

II.1.3 Limitations
Les limitations de IAC peuvent tre divises en deux catgories, les fonctionnalits manquantes et
les 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 code Ada correct pour le simple fichier IDL suivant :
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 fallait un compilateur capable de compiler la plupart du langage IDL. Il a fallu alors une priode
relativement longue (la moiti de la dure du stage temps plein, ensuite en parallle avec les optimisations) pour implmenter toutes les fonctionnalits manquantes dans la partie dorsale de IAC.
Les fonctionnalits qui ont t implmentes dans IAC sont dtailles dans II.2.2 et dans II.2.3.
II.1.3.2

Les dfauts darchitecture

Au fur et mesure de lajout de nouvelles fonctionnalits dans IAC je me suis aperu que la partie
expansion, jusque l inexistante, tait ncessaire pour rsoudre plus simplement certains problmes
rencontrs, notamment pour traiter certains cas particuliers des forward dinterfaces. Jai constat
aussi de la rplication de code plusieurs endroits dans les source de IAC chose qui rend trs
fastidieuse la correction des bogues et la modification des sources.

II.2 Nouvelle architecture


Dans la partie II.2.1, je dcrirai la nouvelle architecture de la partie dorsale de IAC. Cette nouvelle architecture a rendu IAC plus flexible et a facilit considrablement limplmentation des
optimisations dcrites dans III.

CHAPITRE II. CONFORMIT AU STANDARD CORBA 3.0

14

Arbre IDL

Expansion de
Code

Arbre IDL
Expans

Construction de
larbre Ada

Arbre
Ada

Gneration du
Code Ada

Code Ada

F IGURE II.4 Partie dorsale de IAC : nouvelle architecture

II.2.1 Nouveau schma de fonctionnement


II.2.1.1

Expansion de code

Comme il a t prcis dans II.1.3.2, une partie expansion sest avre ncessaire pour rendre
la gnration de code plus simple et pour garder une structure flexible pour IAC. Plusieurs fonctionnalits seront implmentes directement dans la partie expansion, comme lajout des forward
implicites dinterfaces impos par la nature du langage Ada. Dautres fonctionnalits existant dj
dans le cur de la partie dorsale devraient tre dplaces dans la partie expansion pour allger la
construction de larbre Ada.
La nouvelle partie dorsale de IAC dcrite par la figure II.4 se compose dsormais de 3 parties :
La partie expansion : qui prend en entre larbre IDL construit par la partie frontale (AST), le
modifie pour gnrer en sortie un arbre IDL qui donne lieu une gnration de code Ada
beaucoup plus simplement.
La construction de larbre Ada : qui, en parcourant larbre IDL expans, gnre un arbre Ada

II.2. NOUVELLE ARCHITECTURE

15

qui dcrit la structure des souches et des squelettes CORBA de lapplication rpartie en
cours de dveloppement. Le parcours de larbre IDL seffectue laide des procdures
Visit_<Frontend_Node> o <Frontend_Node> dsigne un type de nud de larbre IDL.
La construction de larbre Ada se fait en utilisant les fonctions Make_<Backend_Node> du
paquetage Backend.BE_Ada.Nutils o <Backend_Node> dsigne un type de nud de
larbre Ada.
La gnration de code Ada : Une fois larbre Ada construit, la gnration de code se fait laide
des procdures Generate_<Backend_Node> du paquetage Backend.BE_Ada.Generator.

II.2.1.2

Factorisation de code

Lors de la construction de larbre Ada, la cration de certains types de nuds ncessite laccs
dautres nuds dj cres. Par exemple pour pouvoir crer un appel vers une fonction To_Any
dun certain type, il faut connatre le type du paramtre pour crer lappel vers la bonne fonction
Au fur et mesure de lvolution de IAC, de nouveaux cas de figure pour laccs au nuds sont
apparus et la duplication de code allait rendre le dveloppement fastidieux. Le code a donc t
factoris en sous-programmes. Pour accder aux fonctions To_Any et From_Any dun type donn,
le dveloppeur doit utiliser les fonctions Get_From_Any_Node et Get_To_Any_Node du paquetage Backend.BE_Ada.Nutils. Ces deux fonctions effectuent les tests de tous les cas de figure
possibles 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 de CORBA 3.0.4 est quasiment
acheve. Il ne manque plus que lanalyse des import qui impose que le parseur de IAC doive tre
repens et qui, pour des contraintes temporelles na pu tre acheve par manque de temps. Les
typeprefix et les typeid ont t implments mais ne sont pas compltement tests (notamment
tous les cas particuliers donns dans la specification CORBA [7]).
Les fonctionnalits qui ne sont pas implmentes dans PolyORB (les valuetypes par exemple) ne
sont implmentes ni par IAC ni 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 est
question est un type interface, structure ou union ou un type qui redfinit un type de base
car il est interdit dutiliser les mots-cls comme des identificateurs.
Une des optimisations apportes par la partie frontale de IAC consiste valuer les expressions littrales avant de les intgrer dans larbre IDL le type de lexpression nest pas
chang en fonction de sa nouvelle valeur. Exemple :
const short a = 1 - 2;
La constante a vaut -1, mais le type de la valeur littrale -1 reste toujours non sign (car
le type des constantes 1 et 2 est non sign) ce qui gnre une erreur lors de la vrification
des bornes la phase danalyse.

CHAPITRE II. CONFORMIT AU STANDARD CORBA 3.0

16

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, IAC ne gnrait pas la constante
<Nom_Exception>_Repository_Id. Il ne gnrait pas non plus le corps de la fonction Get_Members impose par les spcification du mapping Ada [6]. Il manquait aussi les fonctions From_Any, To_Any et la constante TC_<Nom_Exception> qui sont ncessaires pour la conversion des
members de lexception ainsi que la procdure Raise_Exception.
la fin du stage, les exceptions dutilisateurs, les exceptions systme et les exceptions inconnues
sont parfaitement gres par IAC.
II.2.3.1.2 Les interfaces : Il manquait la constante <Nom_Operation>_Repository_Id. Les
corps des diffrents sous programmes dclars dans la spec (les souches) (construction des requtes, empaquetages des paramtres...) sont incomplets, il manque la gestion des paramtres de
mode out et inout. 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 paramtres out et inout dune opration.
II.2.3.2

Fonctionnalits Ajoutes

II.2.3.2.1 Linitialisation des paquetages Helper et des squelettes : Cette partie est ncessaire pour le bon fonctionnement de lapplication rpartie et pour que PolyORB puisse initialiser
les diffrents paquetages dans le bon ordre.
II.2.3.2.2 Les squences : La gnration de code pour les squences bornes et non bornes
qui est une fonctionnalit vitale pour un compilateur IDL a t implmente et teste avec succs.
II.2.3.2.3 Lhritage des interfaces : le langage IDL, permet une interface dhriter dune
ou plusieurs autres interfaces. Dans ce cas, linterface fille possde toutes les oprations et les attributs des interfaces parentes. De plus, toutes les dfinitions de types et les dclarations de constantes
et dexceptions qui existent dans les interfaces parentes doivent tre visibles dans linterface fille.
Pour cela les spcifications du mapping Ada [6] imposent de "renommer" (au sens Ada du terme)
les constantes et les exceptions ou de crer des sous-types dans le mapping de linterface fille.
Visiblement, IDLAC na pas choisi cette voie. Il utilise directement les constantes, exceptions ou
types partir du mapping de linterface parente.
La partie frontale de IAC semble stre engage sur la mme voie que IDLAC. En partant de
lexemple ci dessous :
module m {
interface int1 {
typedef long T1;
typedef short T2;

II.2. NOUVELLE ARCHITECTURE

17

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 int2 hrite de linterface int1. Elle doit donc pouvoir accder au type T1 dfini par
int1 comme 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 IDL de IAC, le rsultat
est 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 :
int2 utilise les types et les exceptions de int1.
Le type T2 a t redfini dans int2.
Laccs la version de T2 dfinie dans int1 demeure possible en indiquant les noms complets.
La gnration de code pour lhritage multiple dinterfaces a t implmente dans la partie dorsale
de IAC. Les constantes et les dfinitions de types et dexceptions dans les interfaces parentes sont

18

CHAPITRE II. CONFORMIT AU STANDARD CORBA 3.0

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

II.2.3.2.4 Les tableaux multidimensionnels et imbriqus : Cette fonctionnalit tait absente


au dbut du stage. Elle tait parmi les premires fonctionnalits que jai implment dans IAC.
Cependant suite une modification de la faon dont PolyORB encode les tableaux, jai t amen
la rimplementer conformment la nouvelle spcification de PolyORB. Actuellement, le code
gnr 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 constructeurs 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 par
le fait quelles ne peuvent faire lobjet dune communication entre deux entits diffrentes (client
et serveur). Ceci a pour consquence la non gnration de squelettes et de fonction de conversion
partir et vers le type Any pour ce type dinterfaces.

II.2.3.2.7 Les interfaces Abstraites : Ce sont des interfaces qui ne peuvent tre utilises directement mais doivent tre hrites par des interfaces ou des valuetypes. La partie concernant les
interfaces dans les interfaces abstraites t implmente avec succs.

II.2.3.2.8 Les unions : La gnration de code pour les types union est maintenant implmentes et teste avec succs. Ces types ont lavantage dconomiser lempreinte mmoire par rapport
aux simples structures.

II.2.3.2.9 La forward declaration des interfaces : Cest une fonctionnalit vitale pour un
compilateur IDL. Cette fonctionnalit a t implmente avec succs dans la partie dorsale de
IAC. Certains cas particuliers o on doit ajouter des forward declarations pour viter le problme
de la dpendance mutuelle de deux paquetages Ada ont t rsolus par la partie expansion de code.

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

II.2.3.2.11 Traitement des fonctions implicites de CORBA : dans CORBA le client peut invoquer des mthodes implicites. Pour traiter ces mthodes, un nouveau paquetage est ajout de la
personnalit CORBA de PolyORB : PolyORB.CORBA_P.Implicit_CORBA_Methods.

II.2. NOUVELLE ARCHITECTURE

19

II.2.3.2.12 Analyse du module CORBA : Daprs le chapitre 5 de [6], le fichier orb.idl


contient un module particulier, le module CORBA. Pour des raisons relatives la nature du langage
Ada, larbre IDL relatif au fichier orb.idl doit tre restructur. Aprs cette modification, deux
nouveaux sous modules du module CORBA sont cres :
1. CORBA::Repository_Root qui contient toutes les forward interfaces et les entits relatives
lInterface Repository
2. CORBA::IDL_Sequences qui contient la dclaration de types squences dfinis partir des
type de base CORBA
La raison principale de cette restructuration est que les entits des deux sous-paquetages ne sont
pas utilises par la plupart des applications rparties et, tant donn que le forward dinterface
et les types sequence impliquent des instanciations de paquetages gnriques en Ada, la taille du
paquetage CORBA de lintergiciel deviendrait norme ce qui augmenterait lempreinte mmoire
de lapplication rpartie.
Lanalyse du fichier orb.idl sert dans la plupart des cas uniquement faire entrer le scope du
module CORBA dans le global scope et ne doit gnralement pas donner lieu a une gnration de
code Ada. Il se trouve que certains paquetages dont le mapping Ada [6] recommande lexistence
sont des souches et des squelettes dentits se trouvant dans le fichier orb.idl et leur intgration
dans le dpt contraint le principe disant quil ne faut pas intgrer du code gnr automatiquement
dans un dpt. Ces paquetages sont gnrs automatiquement lors de la compilation de PolyORB.
Pour plus de dtails sur lanalyse du module CORBA, voir lannexe C.

II.2.4 Validation de la conformit


La validation des diffrentes fonctionnalits ajoutes sest effectue en utilisant une suite trs riche
de tests de rgression. Les diffrentes catgories de tests pour IAC sont :
1. ada0001 ada0009 : Les tests de la bonne gnration des spcifications des paquetages
pour les souches et les squelettes. Les spcifications gnres sont compiles avec des corps
de paquetages gnrs par IDLAC. Ces tests couvrent une large partie des la gnration de
code, tels que les types, les unions, les structures, les exceptions...
2. ada0010 ada0018 : Les tests de la bonne gnration des corps des paquetages pour les
souches et les squelettes. Ce sont les mmes tests que la suite prcdente mais l, tout le
code Ada est gnr par IAC.
3. ada0019 ada0022 : Les tests pour la redfinition de types de base CORBA.
4. chicken-egg, circular et forward01 forward01 : Les tests pour les forward declarations des interfaces. Lexemple est tir de la spcification CORBA [7]. Il y a aussi les tests
pour les cas particuliers o le compilateur doit gnrer des forward declarations implicites
pour les besoins du langage Ada.
5. inherit001 inherit005 : Les tests pour lhritage des interfaces. La complexit de ces
tests augmente avec leur numro, allant du simple hritage jusqu arriver vers lhritage
multiple 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 bonne
gnration des messages derreur.

20

CHAPITRE II. CONFORMIT AU STANDARD CORBA 3.0

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


10. corba-idl : Test vrifiant que le module CORBA est bien analys.
En plus de tous les tests cits ci-dessus et qui sont passs avec succs, trois exemples dapplication
rpartie sont fournis pour tester le bon fonctionnent du code gnr par IAC :
all_functions : teste tous les modes de passages de paramtres possibles dans une opration. Ce
test vrifie aussi le bon fonctionnement de lasynchronisme (oprations oneway).
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.

Chapitre III

Vers un intergiciel optimis et


dterministe
La partie mise niveau de IAC pris un peu plus de temps que prvu (un peu plus de la moiti du
stage) cause du nombre important de fonctionnalits manquantes. Le dbut de la phase doptimisation ne pouvait se faire sans la prsence dun compilateur parfaitement oprationnel qui compile
une large varit de fichiers source IDL.
Il a fallu donc choisir les optimisations les plus importantes parmi celles que jai propos dans le
mmoire bibliographique [13] et rejeter les autres. Le deux optimisations qui ont t juges les
plus importantes sont :
1. Lapport du dterminisme dans le traitement des requtes par les squelettes en utilisant les
tables de hachage minimales parfaites.
2. Limplmentation de la SII.

III.1 Utilisation des tables de hachage minimales parfaites


Quand le squelette dune application rpartie reoit une requte traiter, il compare le nom de la
requte avec les noms de toutes les oprations de linterface jusqu trouver la bonne opration et
appeler son implmentation. Cette mthode de recherche doprations est adopte par IDLAC et a
t reprise dans IAC. Par exemple si une interface IDL contient dix oprations :
long echoLong01 (in long data) ;
long echoLong02 (in long data) ;
...
long echoLong10 (in long data) ;
La structure du squelette va avoir cette allure :
if (Operation = "echoLong01") then
<Traitement>;
21

22

CHAPITRE III. VERS UN INTERGICIEL OPTIMIS ET DTERMINISTE

elsif (Operation = "echoLong02") then


<Traitement>;
...
elsif (Operation = "echoLong10") then
<Traitement>;
else
<Erreur>;
end if;

Cette manire trs intuitive de traiter les requtes un inconvnient principal : le temps que met
le 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 quelque
soit lendroit o elle est dclare. Ceci est effectu en utilisant les tables de hachages minimales
parfaites.
Une fonction de hachage h est une fonction qui associe les lments dun ensemble de mots W
de taille m aux lments dun intervalle dentiers [0, k 1]. La fonction h(w) calcule gnralement
une adresse ou un indice dans un tableau o le mot w est stock. Ce tableau est connu aussi sous le
nom de "Table de Hachage". On dit quil y a une collision si deux ou plusieurs mots ont le mme
code de hachage. Une fonction de hachage parfaite est une fonction injective. Une fonction de
hachage minimale parfaite est une bijection de lensemble des mot W vers lintervalle [0, k 1] ce
qui implique que les tailles des deux ensembles soient gales.
Le compilateur Ada GNAT implmente un algorithme de gnration de fonctions de hachage
minimales parfaites. Cest un algorithme probabiliste crit par Czech, Havas et Majewski en
1992 [3]. La gnration statique de fonctions de hachage minimales parfaites impose la contrainte
de connatre tous les mots de lalphabet avant lexcution de lalgorithme. Il se trouve que cest
le cas des squelettes : la compilation dun fichier source IDL, on a accs aux noms de toutes les
oprations. Lalgorithme implment peut fonctionner en deux modes : un mode optimisant lempreinte mmoire des excutables et un autre mode optimisant le temps de calcul. Les deux modes
sont supports par IAC et 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_<Nom_Operation>. La fonction de hachage est gnre en mme temps que les souches et les
squelettes. Les hash codes sont des indices dans un tableau de pointeurs sur les procdures Invoke_<Nom_Operation>. Le rle de la procdure Invoke est de calculer le hash code dune opration
et, 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 sur
des procdures namliorent les performances que lorsque le nombre doprations est trs grand
(voir les rsultats des tests en III.1.2).

III.1. UTILISATION DES TABLES DE HACHAGE MINIMALES PARFAITES

III.1.1.2

23

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 ellesmmes pour des raisons de vrification. La structure conditionnelle dans la procdure Invoke est
remplace par un switch case dont les paramtres sont les hash codes (qui appartiennent un
type scalaire et peuvent donc tre utiliss dans un switch case). Cette approche fait augmenter
considrablement les performances vu que le switch case effectue des sauts directs et ne teste pas
toutes les conditions (cf III.1.2).

III.1.2 Gains obtenus


Tous les tests ont t effectus sur un PC compatible IBM qui possde les caractristiques suivantes :
Processeur : Intel(R) Pentium(R) 4 3.00 GHz
Mmoire vive : 1 Go
OS : Debian GNU Linux (unstable) avec un noyau 2.6.8
Compilateur Ada : 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) ;
...
long echoLong99 (in long data) ;
}
Le script du test automatique compile trois fois lapplication rpartie : une premire fois sans utiliser loptimisation des tables de hachage minimales parfaites, une deuxime fois en optimisant le
temps de calcul et une troisime fois en optimisant lempreinte mmoire. Aprs chaque compilation, le serveur et le client sont excuts. Le client effectue 4 types dinvocations un nombre donn
de 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
Client
Serveur

Pas doptimisation
2165
2979.55

Temps CPU
2165
2979.64

Empreinte mmoire
2165
2979.27

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

CHAPITRE III. VERS UN INTERGICIEL OPTIMIS ET DTERMINISTE

24

Fetching times (ordered)


0.00023
No_Opt
CPU_Opt
Mem_Opt

Implementation fetching time (sec)

0.000225

0.00022

0.000215

0.00021

0.000205

0.0002

0.000195

0.00019
0

10

20

30

40
50
60
Operation index

70

80

90

100

F IGURE III.1 Premire approche dutilisation des tables de hachage

Fetching times (ordered)


0.000215
No_Opt
CPU_Opt
Mem_Opt

Implementation fetching time (sec)

0.00021

0.000205

0.0002

0.000195

0.00019
0

10

20

30

40
50
60
Operation index

70

80

90

F IGURE III.2 Deuxime approche dutilisation des tables de hachage

100

III.2. LIMPLMENTATION DE LA SII

25

Les temps dexcution sont rcuprs dans des fichiers qui donnent lieu ensuite un graphique
grce un script GNU Plot. La figure III.1 montre les temps dexcution en fonction de lindice de lopration en utilisant la premire approche (celle des pointeurs). La figure III.2 montre
les mmes rsultats mais en utilisant la deuxime approche (celle du switch case). On voit bien
lamlioration de performance apporte par le seconde approche : on gagne ds lutilisation de la
premire opration. Le tableau III.1 montre 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 inchange. Quant au serveur, sa taille lors de loptimisation CPU est un peu plus grande que celle du
cas sans optimisation. Ceci est d lutilisation de tables relativement grandes pour les calcul des
hash codes. Loptimisation mmoire permet dobtenir la plus petite taille mmoire. tant donn
que les performances sont quasiment les mmes quavec loptimisation CPU (au contraire de ce
qui est affirm dans larticle [3]), cest cette optimisation quil est conseill dutiliser.

III.2 Limplmentation de la SII


Lintergiciel PolyORB traite toutes les requtes dune manire dynamique. Ce mode de traitement
sappelle la DII (Dynamic Invocation Interface). Il a lavantage de permettre le traitement dune requte mme si la signature exacte de lopration nest pas connue la compilation de lapplication
rpartie. Dans ce type de traitement, le client construit une liste des paramtres convertis au type
Any (la NVList). Cette liste est passe la couche protocolaire qui se charge de faire lempaquetage des paramtres aprs les avoir convertis une deuxime fois vers leur types dorigine. Du cot
serveur, le processus inverse est effectu : les paramtres sont dsempaquets du buffer, convertis
au type Any et mis dans une NVList par la couche protocolaire de lintergiciel. Le squelette de
lapplication rpartie se charge de convertir les paramtres vers leur type dorigine avant dappeler
limplmentation. Pour envoyer le rsultat dune requte et les diffrent paramtres out et inout,
le mme travail est effectu. La figure III.3 dcrit le fonctionnement de la DII dans PolyORB.
On voit bien daprs la figure III.3 quil existe plusieurs conversions vers et partir du type Any. Si
la signature de lopration est connue la compilation, il serait judicieux dempaqueter les paramtres directement sans les convertir vers le type Any. Cest le principe de la SII (Static Invocation
Interface). La figure III.4 dcrit le fonctionnement de la SII. Au contraire de la DII, la couche applicative du client ne remplit pas une NVList mais met jour les champ dun enregistrement. Ces
champs reprsentent les diffrents paramtres de lopration en plus du rsultat sil sagit dune
fonction. 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 fonctions
dempaquetage (marshalling) et de dsempaquetage (unmarshalling) des paramtres. Ces deux
fonctions sont gnres automatiquement par IAC dans un sous-paquetage spar, de mme niveau
que les Helpers et qui est appel CDRs pour (Common Data Represenatation). En plus de ces deux
sous programmes, le paquetage CDRs contient la dclaration du type enregistrement qui contient
les paramtres et le rsultat. Ce type hrite du type abstrait Request_Args dcrit dans le paquetage
PolyORB.Requests :
type Request_Args is abstract tagged null record;

CHAPITRE III. VERS UN INTERGICIEL OPTIMIS ET DTERMINISTE

26

Rsultat +
Paramtres
OUT et INOUT

Paramtres
IN et INOUT

Appel To_Any et
remplissage de la
NVList

NVList

Appel From_Any

Couche applicative
Couche protocolaire

Appel From_Any et
remplissage du
Buffer

Client

NVList
Vidage du Buffer, appel
To_Any et remplissage
de la NVList

Buffer

Buffer

Rseau
Buffer

Buffer

Vidage du Buffer, appel


To_Any et remplissage
de la NVList

NVList

Serveur

Appel From_Any et
remplissage du
Buffer

Couche protocolaire
Couche applicative

NVList
Appel To_Any et
remplissage de la
NVList

Appel From_Any

Paramtres
IN et INOUT

Excution de
limplmentation

F IGURE III.3 Fonctionnement de la DII

Rsultat +
Paramtres
OUT et INOUT

III.2. LIMPLMENTATION DE LA SII

27

Rsultat +
Paramtres
OUT et INOUT

Paramtres
IN et INOUT

Couche applicative

Enregistrement
de paramtres

Mise jour des


valeurs des paramtres

Remplissage dun
enregistrement

Enregistrement
de paramtres

Couche protocolaire

Remplissage
du Buffer

Client

Vidage du Buffer,et
remplissage de
lenregistrement

Buffer

Buffer

Rseau
Buffer

Buffer

Vidage du Buffer,et
remplissage de
lenregistrement

Enregistrement
de paramtres

Couche applicative

Remplissage dun
enregistrement

Mise jour des


valeurs des paramtres

Paramtres
IN et INOUT

Remplissage
du Buffer

Couche protocolaire

Enregistrement
de paramtres

Serveur

Excution de
limplmentation

F IGURE III.4 Fonctionnement de la SII

Rsultat +
Paramtres
OUT et INOUT

28

--

CHAPITRE III. VERS UN INTERGICIEL OPTIMIS ET DTERMINISTE

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 champ
qui a t ajout la structure de la requte : cest le champ Payload qui est un pointeur vers une
variable de type Request_Payload. Ce dernier type est un enregistrement qui contient un champ
de 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 protocolaire GIOP tend ce type pour ajouter deux pointeurs vers les fonctions
dempaquetage 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 client
Dans ces quatre endroits, un test est ajout. On vrifie si le champ Payload de la requte a bien
t mis jour. Si oui, on utilise la SII on appelant les fonctions gnres automatiquement. Sinon,
on utilise la DII exactement comme si aucune modification navait t apporte.

III.2.2 Gains obtenus


La gnration automatique des fonctions dempaquetage et de dsempaquetage est oprationnelle
pour les types suivants :
Les long
Les unsigned long
Les short

III.2. LIMPLMENTATION DE LA SII

29

F IGURE III.5 Comparaison de la SII et la DII pour 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 appels
vers des fonctions echo<Type> qui prennent comme paramtre une variable dun certain type et
se contentent de retourner la mme variable. Les tests sont effectus sur une plate-forme identique
celle de III.1.2.
La figure III.5 donne une comparaisons des temps dexcution de 10000 requtes pour les unsigned
long, string et squences de 10 unsigned long. Les gains en performance sont trs clairs :
Pour les unsigned long : 11%
Pour les string : 11%
Pour les squences : 33%
Test
Entit
DII
SII

Unsigned Long
Client Serveur
1811.57 2497.05
1811.46 2496.06

String
Client Serveur
1813.21 2495.85
1819.59 2501.67

Squence
Client Serveur
2050.73 2774.70
2053.74 2767.87

TABLE III.2 Taille des excutables (Kilo-Octets) en SII et DII


Le tableau III.2 donne les tailles des excutables utiliss dans le dernier test. On remarque quil
nexiste pas de rgle gnrale pour la modification de lempreinte mmoire de ces excutables en
passant de la DII la SII. Dans le cas des long, la taille mmoire du client et du serveur diminue
en 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 SII
ncessite lajout dun code supplmentaire lapplication (la structure contenant les paramtres et
les deux procdures de stockages des paramtres). Il implique aussi la non utilisation des fonctions

30

CHAPITRE III. VERS UN INTERGICIEL OPTIMIS ET DTERMINISTE

F IGURE III.6 Comparaison de la SII et la DII pour les squences (1000 itrations)
de stockage de PolyORB utilisant la DII. Toutefois, les tailles des excutables sont trs proches et
les diffrences ne dpassent jamais la dizaine de Kilo-Octets.
La figure III.6 montre lvolution des gains en performance pour lexcution de 1000 itrations
pour 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 la DII, le temps dexcution augmente
trs rapidement en fonction de la longueur de la squence tandis que dans le cas de la SII, cette
croissance est lente.

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 : le
compilateur IAC est maintenant au niveau de IDLAC. Le remplacement de IDLAC par IAC dans les
sources de PolyORB ne ncessite plus quun minime effort. IAC est un compilateur flexible et se
prte la maintenance beaucoup plus facilement que IDLAC.
Les deux optimisations qui ont t implmentes dans IAC ont beaucoup augment les performances des applications rparties gnres par ce compilateur aussi bien en ajoutant le dterminisme (tables de hachage minimales parfaites) quen diminuant considrablement le temps dexcution des requtes (SII).
Maintenant que les tests ont montr le grand apport en performance de la SII, la poursuite de la
gnration de code pour le reste des types (structures, unions, tableaux) qui est une tche facile
mais qui va prendre un temps considrable peut tre entame.

IV.2 Perspectives
Certaines fonctionnalits nont pu tre ajoutes dans IAC par manque de temps, il serait intressant de commencer par les implmenter avant de poursuivre lvolution de IAC et pour pouvoir
remplacer dfinitivement IDLAC par IAC :
1. Lachvement des imports qui va ncessiter lapport de modifications profondes dans la
structure du Parser.
2. Limplmentation de la gnration de code pour les types anonymes (cf 3.11.6 de [7]). Bien
que lutilisation de tels types soit obsolte dans CORBA 3.0, certains fichiers source IDL de
PolyORB les contiennent. Limplmentation de cette fonctionnalit devrait tre effectue
dans la partie expansion de la partie dorsale.
3. Les chanes de caractres bornes.
31

32

CHAPITRE IV. CONCLUSIONS ET PERSPECTIVES

Deux fonctionnalits qui sont trs utiles dans un compilateur IDL, et qui constitueraient des enrichissements de IAC par rapport IDLAC (avec loptimisation des squelettes et limplmentation de
la SII) seraient :
1. La gnration de code pour les forward declarations de structures et dunions. Une telle
implmentation ne serait pas aussi facile que la forward declaration des interfaces. En effet,
dans la spcification CORBA, la possibilit dune telle dclaration est prcise. Cependant,
dans les spcifications du mapping Ada [6], la marche suivre nest pas donne.
2. Limplmentation de la gnration de code pour les valuetypes dans IAC et dans PolyORB.
Une optimisation trs intressante qui pourrait aussi tre implmente dans IAC dans la continuit
de la SII, est lallocation statique des buffers en calculant lavance leur taille. Ce nest pas une
tche trs simple vu que cette taille dpend, en plus du nombre et de la nature des paramtres,
de la version du protocole GIOP. Il faudra aussi implmenter les mcanismes dallocation statique
dans le paquetage PolyORB.Buffers. On pourrait aussi envisager dutiliser les mmes procdures
dempaquetage et de dsempaquetage pour les oprations ayant les mmes signatures. Ceci apportera 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 ou
des optimisations IAC :
Pour les liaisons entre les arbres IDL et Ada, utiliser les fonctions Get_XXXX_Node dclares
dans le paquetage Backend.BE_Ada.Nutils en priorit sur les fonctions XXXX_Node du
paquetage Backend.BE_Ada.Nodes. Car les premires contiennent beaucoup de tests et
vitent la rplication de code.
Prfrer la fonction Get_Correct_Parent_Unit_Name du paquetage Backend.BE_Ada.Nutils la fonction Get_Parent_Unit_Name du paquetage Backend.BE_Ada.Nodes
quand cela est possible.
Ne pas hsiter crer ses propres liens entre les deux arbres en suivant la mme dmarche
que pour les liens dj crs.

Bibliographie
[1] Imran Ahmad and Shikharesh Majumdar. Achieving High Performance in CORBA-Based
Systems with Limited Heterogeneity. In ISORC, 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 for
Generating Minimal Perfect Hash Functions. In Information Processing Letters, pages 257
264, Oct 1992.
[4] Eric Eide, Kevin Frei, Bryan Ford, Jay Lepreau, and Gary Lindstrom. Flick : A Flexible,
Optimizing IDL Compiler. In Proceedings of the ACM SIGPLAN97 Conferance PLDI, Las
Vegas, 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. StubCode Performance is Becoming Important. In Proceedings 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++. AddisonWesley Longman Publishing Co., Inc., Boston, MA, USA, 1999.
[10] Shivakant Mishra and Nija Shi. Improving the Performance of Distributed CORBA Applications. 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 Paris
VI, December 2001.
[12] Thomas Vergnaud, Jrme Hugues, Laurent Pautet, and Fabrice Kordon. PolyORB : A Schizophrenic Middleware to Build Versatile Reliable Distributed Applications. In Ada-Europe,
pages 106119, 2004.
[13] Bechir Zalila. Optimisation Dterminisme et Asynchronisme des Souches et Squelettes
CORBA pour Systmes Rpartis Temps-rel. Mmoire bibliographique du stage de Master 2
SAR, April 2005.

33

34

BIBLIOGRAPHIE

Annexe A : Description de larbre IDL


1 Description gnrale
La partie frontale de IAC gnre un arbre syntaxique abstrait qui est une reprsentation plus labore de la squence linaire de Tokens que sont les sources IDL compiler.
Durant le dveloppement de IAC la structure de cet arbre subit des volutions, ne serait ce que
pour mettre jour le compilateur vers une version plus rcente de la spcification CORBA. Il est
donc ncessaire que cette mise jour de la structure de larbre seffectue avec le moins de peine
possible pour le dveloppeur. Pour ce faire, seuls les diffrents types de nuds sont donns par
le dveloppeurs. Ensuite un programme nomm mknodes gnre automatiquement les diffrents
sous-programmes qui contrlent lAST et qui permettent de lenregistrer en mmoire. Cette structure est dcrite dans un fichier pseudo-IDL o chaque interface reprsente une entit IDL (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 dans
le fichier dcrivant larbre correspond une rgle de la grammaire IDL [7]. Par exemple, les rgles
de la grammaire dfinissant la dclaration dune interface sont :
(5) <interface_dcl> ::= <interface_header> "{" <interface_body> "}"
(7) <interface_header> ::= [ "abstract" | "local" ] "interface" <identifier>
[ <interface_inheritance_spec> ]
(8) <interface_body> ::= <export>*
(9) <export> ::= <type_dcl> ";"
| <const_dcl> ";"
| <except_dcl> ";"
| <attr_dcl> ";"
| <op_dcl> ";"
| <type_id_dcl> ";"
| <type_prefix_dcl> ";"
Dans la description de larbre IDL on trouve une description trs similaire pour la dclaration
dinterface :
interface Interface_Body : List_Id {};
interface Interface_Declaration : Scope_Definition {
boolean
Is_Abstract_Interface;
boolean
Is_Local_Interface;
35

ANNEXE A : DESCRIPTION DE LARBRE IDL

36

List_Id
List_Id
List_Id

Interface_Spec;
Interface_Body;
Type_Prefixes;

};
Linterface Scope_Definition qui est le parent de Interface_Declaration est dclare aussi
dans le mme fichier et dcrit le nom des entits IDL. On remarque la similarit entre les deux types
de dclarations lexception de lordre car en IDL on ne peut utiliser que des entits dclares
auparavant.

Avantages par rapport lAST de IDLAC

Dans IDLAC, la construction des paquetages relatifs larbre IDL est elle aussi faite de faon automatique mais un peu plus primitive que dans IAC. Dans les deux compilateurs, le type reprsentant
un nud de larbre est un enregistrement et larbre est une table denregistrement instancie partir
du paquetage gnrique GNAT.Table. Dans le cas de IDLAC, lensemble des champs contenus dans
lenregistrement est lunion (au sens ensembliste du terme) des champs de tous les types de nuds.
Par exemple, le nud correspondant un attribute contient un champ boolen Is_Readonly et le
nud correspondant une interface contient un champ boolen Local. Dans lenregistrement
reprsentant un nud de larbre IDL, on verra :
type Node_Type is record
...
Is_Readonly
...
Local
...
end record;

: Boolean;
: Boolean;

En appliquant ce procd tous les types de nuds possibles, on obtient un enregistrement qui
contient 77 champs ce qui est trs pnalisant et trs coteux en taille mmoire.
Dans IAC, 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 types
de nuds contenant un champ de mme type mais de noms diffrents, il serait intressant de
pouvoir confondre les deux champs dans lenregistrement qui contient dsormais des tableaux
reprsentant 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 dont
trois tableaux dont les longueurs sont calcules la gnration des paquetages pour larbre IDL :
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;

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 5
fois plus petit que IDLAC. Tout ceci est bien entendu fait de faon automatique et transparente et
lutilisateur naura pas grer les index dans les tableaux : des "accesseurs" pour chaque entit
dun type de nud sont gnrs. Cest lobjet de la partie qui suit.

3 Entits gnres
Le programme mknodes Parse le fichier frontend-nodes.idl (pseudo-IDL) en utilisant le lexeur
et le parseur de IAC (cf II.1.1.1). Le rsultat est un paquetage Ada appel Frontend.Nodes qui
contient, pour chaque champ dclar dans une interface du fichier IDL, deux "accesseurs" pour
pouvoir lire et modifier la valeur de ce champ. Cest dans ces "accesseurs" quest faite la rsolution
des index des tableaux. Par exemple, pour le champ boolen Is_Abstract_Interface indiquant
si 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 IAC chaque sous programme contient un ensemble
dassertions au dbut pour vrifier si le champ auquel on veut accder existe vraiment dans le type
de 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.Nodes contient aussi des sous programmes qui servent crire chacun
des nuds si le dveloppeur dsire regarder larbre IDL gnr.

38

ANNEXE A : DESCRIPTION DE LARBRE IDL

Annexe B : Description de larbre Ada


1 Description gnrale
Avant la gnration de code Ada, et pour rendre le compilateur IAC plus flexible, il y a une phase
de transformation de larbre IDL en un arbre Ada.
La structure de larbre est fortement inspire de la structure de lAST de GNAT dcrite dans le
fichier sinfo.ads dans les sources du compilateur Ada mais seulement une partie de cette structure est utilise dans la partie dorsale de IAC (suffisamment pour pouvoir gnrer les structures de
donnes des souches et des squelettes).
Comme pour larbre IDL, la structure de larbre Ada est dcrite dans un fichier pseudo-IDL o
chaque interface reprsente une entit Ada (appel un sous-programme, dclaration dobjet, spcification dun paquetage...) et les champs dclars dans chaque interface correspondent aux entits quon peut trouver dans cette entit et aux proprits de cette entit. Les paquetages Ada qui
permettent de construire et de manipuler larbre Ada sont gnrs automatiquement par le mme
programme mknodes qui gnre les fichiers relatifs larbre IDL.
Ci-dessous, un petit exemple prsente comment est dcrite la structure conditionnelle if dans le
fichier 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 composent, 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

ANNEXE B : DESCRIPTION DE LARBRE ADA

40

Le nud retourn par cette fonction est de type K_If_Statement et il reprsente la structure
conditionnelle cre. On pourra lajouter dans larbre Ada laide des diffrentes mthodes Make_XXXX du paquetage Backend.BE_Ada.Nutils ou directement en utilisant la procdure Append_Node_To_List du mme paquetage si on sait exactement o ajouter le nud.

Liaisons entre les deux arbres

Comme il a t prcis dans II.1.1.2, la construction de larbre Ada seffectue en parcourant larbre
IDL un certain nombre de fois, et il arrive trs souvent quon utilise des nuds dj crs. Cette
utilisation est rendue possible grce des liaisons cres entre les deux arbres. Prenons lexemple
IDL suivant :
interface myInt {
typedef MyStr string;
MyStr echoString (in MyStr data);
};
Lors du parcours pour gnrer le paquetage Helper de linterface myInt, IAC gnre les fonction
To_Any et From_Any pour le type MyStr. Ces deux fonctions sont utilises dans la souche et dans
le squelette. Pour pouvoir accder ces fonctions et plusieurs autres entits, IAC cre une liaison
entre le dclarateur MyStr et les deux nuds des deux fonctions. Cette liaison est rendue possible
en ajoutant un nouveau champs BE_Node pour le nud Identifier de larbre IDL :
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 comme
champs, 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;

2. LIAISONS ENTRE LES DEUX ARBRES

Node_Id
Node_Id
Node_Id
};

41

From_CDR_Node;
To_CDR_Node;
Set_Args_Node;

Le fait de passer par un nud intermdiaire permet de simplifier la structure de larbre IDL. Le
sens 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 larbre Ada et vite dy
crer des nuds identiques. Il existe cependant des situations o on est oblig de crer des nuds
identiques dans larbre Ada ; par exemple, un mme nud ne peut tre prsent dans deux listes
diffrentes car la structure de la liste repose sur le champ Next_Node et un nud ne possde quun
seul champ Next_Node. Pour cette raison, la fonction Copy_Node est utilise pour crer des copies
identiques de certains types de nuds.

42

ANNEXE B : DESCRIPTION DE LARBRE ADA

Annexe C : Cas particulier du module


CORBA
La description du module particulier CORBA existe dans le chapitre 5 des spcifications du mapping Ada de CORBA [6]. Ce module contient les dclarations de plusieurs entits vitales pour le
fonctionnement de lintergiciel (cration de requtes, DII, Repository_Id, exceptions systme...). Il
contient aussi la dfinition de types squences pour la plupart des types de base CORBA. Toutes
ces entits sont dcrites dans un fichier particulier appel orb.idl.
Les spcifications du mapping donnent la plupart des spec Ada gnrer. La plupart du temps, le
code qui doit tre gnr est diffrent du code gnr pour un fichier IDL classique. Pour ces parties,
le code Ada a t crit manuellement (et non gnr automatiquement) lors du dveloppement de
la personnalit CORBA de PolyORB. Cependant il peut se trouver quun fichier source IDL inclue
le fichier orb.idl pour pouvoir utiliser les entits qui y sont dcrites. Il faut donc empcher le
compilateur IDL de gnrer du code Ada pour les parties crites manuellement, tout en gnrant le
bon code pour le fichier source classique. Ajoutons cela que certaines partie du modules CORBA
sont crites en pseudo-IDL et certaines autres ne respectent pas la grammaire et nous nous trouvons
devant un problme trs difficile. Dans ce qui suit, je donnerai la description de la manire dont le
module CORBA est analys et des diffrentes anomalies de syntaxe et de smantique prsentes dans
le fichier orb.idl.

1 Modification de larbre IDL


Comme il a t dit prcdemment, des types squences pour les types de bases sont dclars
dans le module CORBA. Lutilisation de ces types est trs rare par les applications rparties. Sachant que toutes les applications rparties ont besoin du module CORBA pour fonctionner (plus
prcisment du paquetage Ada CORBA), et sachant que la dclaration des types squence implique
plusieurs instanciations de paquetages gnriques, les empreintes mmoires des applications rparties vont augmenter inutilement. Pour cette raison il a t dcid lors du dveloppement de
la personnalit CORBA de PolyORB que les types squence doivent tre dplacs dans un module fils du module CORBA appel CORBA::IDL_Sequences. De cette manire, les applications qui
nutilisent pas ces types ne devront pas les inclure dans leur code. Les autres entits du module
CORBA pour lesquelles une gnration automatique de code est ncessaire contiennent essentiellement des forward declarations dinterfaces et sont aussi dplaces dans un sous-module appel
CORBA::Repository_Root.
Lors de lanalyse du fichier orb.idl, il faut modifier la branche de larbre IDL relative au module
43

ANNEXE C : CAS PARTICULIER DU MODULE CORBA

44

CORBA en supprimant les parties pour lesquelles aucune gnration de code nest demande et en
dplaant le reste conformment ce qui a t dit dans le paragraphe prcdent.

Anomalies dans orb.idl

Deux anomalies existent dans le fichier orb.idl et rendent son analyse un peu dlicate.
Lentte du fichier contient linstruction suivante qui permet de spcifier un prfixe pour toutes les
constantes de linterface Repository :
typeprefix CORBA "omg.org"
Dans la grammaire IDL [7] la rgle 2 est trs claire :
(2) <definition> ::= <type_dcl> ";"
...
| <type_prefix_dcl> ";"
...
Ce qui veut dire quil faut mettre un " ;" aprs un typeprefix. Dune part IAC doit tre rigoureux
vis--vis le respect de la grammaire par les sources IDL et dune autre part, il doit arriver parser
le fichier orb.idl. La solution adopte tait daccepter les deux types de dclarations pour les
typeprefix (et pour les typeid qui souffrent de la mme anomalie), avec " ;" et sans " ;" et dmettre
un Warning pour la seconde.
La deuxime anomalie que jai rencontr tait lutilisation dun mot-cl comme identificateur dinterface, cest le cas de linterface Object. Dans ce cas, la parade qui existait dj dans IDLAC, tait
de mettre un :
#define Object OObject
pour ne pas gnrer une erreur de syntaxe. Ceci est sans consquence majeure puisque aucun code
ne doit tre gnr automatiquement pour cette interface.