FR2841014A1 - Procede et dispositif d'optimisation d'un programme informatique - Google Patents

Abstract

Ce procédé d'optimisation d'un programme informatique susceptible d'effectuer, en réponse à un événement appartenant à un groupe d'événements, une transition entre un premier état prédéterminé et un deuxième état prédéterminé, ces états prédéterminés étant mémorisés dans des registres, et la transition étant modélisée sous forme d'un premier graphe de décision utilisant ces registres, comporte les étapes suivantes :- lecture (E520) d'un sous-groupe d'événements choisis parmi le groupe d'événements;- modélisation (E540) d'un deuxième graphe de décision utilisant les registres et équivalent au premier graphe de décision, lorsque les événements du groupe d'événements n'appartenant pas à ce sous-groupe d'événements ne se produisent pas; et- génération, dans un langage de programmation, d'une fonction logicielle mettant en oeuvre les transitions modélisées par le deuxième graphe de décision.Utilisation dans un compilateur.

Description

memoire RAM double port.

La presente invention concerne un procede et un dispositif

d'optimisation d'un programme informatique.

L'invention se situe plus particulierement dans le domaine de I'optimisation de programmes informatiques temps reels susceptibles de traiter

un grand nombre d'evenements.

Wile trouve une application particuliere mais non limitative dans les equipements de bureautique multifonction capables de realiser diverges taches concurrentes telles que la copie, i'impression, la numerisation, etc. Dans un tel systeme, en effet, de nombreux evenements vent

susceptibles de se produire.

On peut par exemple citer: - des evenements declenches par une commande d'un utilisateur (appui sur une touche du clavier numerique de l'appareil de fonction); - des evenements declenches par des capteurs de l'appareil de bureautique (reserve d'encre epuisee, bourrage papier); et - des evenements declenches pas le systeme d'exploitation de la

machine (memoire saturee, frame re,cue erronee,...).

De fa,con connue, la modelisation d'un programme informatique pour la gestion de ces evenements peut etre effectuee au moyen d'automates

dans un diagramme d'etats.

Une telle modelisation est particulierement interessante car elle offre une representation conceptuelle de haut niveau du programme informatique mais aussi parce qu'elle permet d'effectuer un certain nombre de

tests des la conception du programme.

2 2841014

De nombreuses methodes ont ete proposees pour generer le code informatique a integrer dans la machine cible a partir de cette modelisation sous

forme d'automates.

Une approche recense passe par la generation d'un code intermediaire dans le langage Esterel tel que defini par G. Berry et G. Gonthier dans le document "Esterel synchronous programming language: design semantics, implementation" Science of Computer Programming 19(2), 87-152,

1 992.

Avantageusement, le langage Esterel offre une syntaxe textuelle

permettant aisement une traduction du diagramme d'etats dans ce langage.

Une telle traduction est connue de l'homme du metier.

Malheureusement, le langage Esterel ne peut pas etre directement implante dans un programme informatique ecrit dans un langage

classique, de type C par exemple.

Le programme modelise en langage Esterel doit done etre traduit au moyen d'un compilateur, par exemple en utilisant la version 5 du compilateur Esterel telle que specifiee dans la documentation de reference du compilateur Esterel v5.91, disponible aux adresses Internet http://www sop.inria.fr/meije/esterel/esterel-enq.html et http://www.esterel

technolopies.com/ et commercialisb par la societe Esterel Technologies.

Des informations complementaires sur le compilateur Esterel vent disponibles dans la these de Xavier Fornari, "Optimisation du controle et implantation en circuits de programmes Esterel", these de l'Ecole des Mines de

Paris, Mars 1995.

De fa,con connue de l'homme du metier de la programmation temps reel, il est indispensable, pour obtenir un code informatique capable de gerer efficacement differents types d'evenements, de prevoir des traitements

adaptes a la nature des evenements a traiter.

Malheureusement les compilateurs connus a ce jour ne permettent pas d'operer une telle distinction. Ils produisent alors un code informatique qui ne permet pas d'obtenir des performances satisfaisantes pour les programmes complexes et susceptibles de reagir a un grand nombre d'evenements.

La presente invention vise a resoubre le probleme precise.

Plus precisement, la presente invention concerne un procede d'optimisation d'un programme informatique susceptible d'effectuer, en reponse a un evenement appartenant a un groupe d'evenements, au moins une transition entre un premier etat predetermine et un deuxieme etat predetermine, ces etats predetermines etant memorises dans des registres, et la transition etant modelisee sous forme d'un premier graphe de decision utilisant ces registres. Le procede comporte les etapes suivantes: - lecture d'au moins un sous-groupe d'evenements choisis parmi le groupe d'evenements; - model isatio n d 'a u moin s u n de uxiem e g rap he de decis ion utilisant ces registres et equivalent au premier graphe de decision lorsque les evenements du groupe d'evenements n'appartenant pas au sous-groupe d'evenements ne se produisent pas; et - generation, dans un langage de programmation, d'au moins une fonction logicielle mettant en oeuvre les transitions modelisees par le

deuxieme graphe de decision.

La fonction logicielle ainsi obtenue est particulierement avantageuse, car elle produit les memes effets que le programme informatique en reponse aux evenements du sous-groupe d'evenements, mais de fa,con optimisee car elle ne prend pas en compte les evenements n'appartenant pas a

ce sous-groupe.

Selon une caracteristique preferee, le programme informatique est adapte, au cours d'au moins une des transitions, a generer un signal

d'execution d'un traitement predetermine.

Le temps de traitement consecutif a ['apparition d'un evenement predetermine etant optimise, le temps de traitement necessaire pour traiter un evenement d'un sous-groupe optimise est systematiquement raccourci, car les instructions d'origine correspondent aux tests realises pour le traitement des

evenements n'appartenant pas a ce sous-groupe ne vent pas executees.

4 2841014

Selon un premier mode prefere de realisation, le procede comporte en outre une etape d'implantation de la fonction logicielle conditionnant son execution a ['apparition d'un evenement du sous-groupe d'evenements. Dans ce premier mode prefere de realisation, la fonction de traitement d'un evenement est declenchee directement par ['apparition de l'evenement. Une telle implantation cite "implantation evenementielle" est particulierement adaptee au traitement des evenements necessitant un temps

de reponse tres court.

Selon un deuxieme mode prefere de realisation, le procede comporte une etape d'impiantation de la fonction logicielle permettant son

execution suivant des intervalles de temps predetermines.

Dans ce deuxieme mode de realisation, le calcul des reactions de ['automate est declenche par une horloge, selon des intervalles predetermines,

par exemple cycliquement. On parle alors "d'implantation temporelle".

11 est ainsi possible de prevoir, pour chaque sous-groupe d'evenements, un cycle de surveillance plus ou moins long, en fonction des

contraintes de temps de traitement des evenements du sous-groupe.

Selon une autre caracteristique particuliere, on lit au moins deux

sous-groupes d'evenements constituent une partition du groupe d'evenements.

Cette partition est particulierement adaptee dans le cas d'une implantation temporelle, dans laquelle on constitue des sous-groupes disjoints

en fonction de leur exigence en temps de reponse.

En variante, au cours de i'etape de lecture, on lit au moins deux

sous-groupes d'evenements non disjoints.

Cette caracteristique autorise a placer un evenement critique dans plusieurs sous-groupes, ce qui permet, en particulier dans une implantation evenementielle, a considerer cet evenement critique a chaque fois qu'un

evenement appartenant a l'un de ces sous-g roupes se prod u it.

Selon une autre caracteristique preferee du procede d'optimisation selon ['invention, le sous-groupe d'evenements est cree automatiquement en

2841014

fonction de la frequence de traitement souhaitee pour les evenements audit

groupe d'evenements.

Cette caracteristique permet de creer les differents sous-groupes automatiquement a partir d'informations sur la frequence de traitement des differents evenements, ces frequences etant par exemple saisies par un utilisateur. Cette caracteristique est particulibrement avantageuse pour l'optimisation d'un programme informatique susceptible de reagir a un nombre

important d'evenements.

Selon une autre caracteristique avantageuse, le procede d'optimisation comporte en outre une etape prealable de generation du premier

graphe de decision a partir d'un diagramme d'etats.

Cette etape de generation est particulierement adaptee a la modelisation de programmes informatiques complexes, notamment aux programmes informatiques susceptibles de repondre a un nombre

particulierement important d'evenements.

Correlativement, I'invention concerne un dispositif d'optimisation d'un programme informatique susceptible d'effectuer, en reponse a au moins un evenement appartenant a un groupe d'evenements, au moins une transition entre un premier etat predetermine et un deuxieme etat predetermine, ces etats predetermines etant memorises dans des registres, et la transition etant

modelisee sous forme d'un premier graphe de decision utilisant ces registres.

Le dispositif comporte: - des moyens de lecture d'au moins un sous-groupe d'evenements choisis parmi le groupe d'evenements; - des moyens de modelisation d'au moins un deuxieme graphe de decision utilisant les registres et equivalent au premier graphe de decision, lorsque les evenements du groupe d'evenements n'appartenant pas au sous groupe d'evenements ne se produisent pas; et - des moyens de generation, dans un langage de programmation, d'au moins une fonction logicielle mettant en couvre les

transitions modelisees par le deuxieme graphe de decision.

6 2841014

L'invention vise aussi un systeme informatique et un compilateur comportant des moyens adaptes a mettre en osuvre un procede d'optimisation

tel que decrit brievement ci-dessus.

L'invention vise aussi un systeme informatique comportant un dispositif d'optimisation tel que decrit brievement ci-dessus. L'invention vise aussi un support d'informations risible par un systeme informatique, eventuellement totalement ou partiellement amovible, notamment CD-ROM ou support magnetique, tel un disque dur ou une disquette, ou support transmissible, tel un signal electrique ou optique, et comportant des instructions d'un programme d'ordinateur permettant la mise en ceuvre d'un procede d'optimisation tel que decrit brievement ci-dessus, lorsque

ce programme est charge et execute par un systeme informatique.

L'invention vise aussi un programme d'ordinateur stocke sur un support d'informations, et comportant des instructions permettant la mise en couvre d'un procede d'optimisation tel que decrit brievement ci-dessus, lorsque

ce programme est charge et execute par un systeme informatique.

Les avantages et caracteristiques particulieres propres au dispositif d'optimisation, aux systemes informatiques, au compilateur, au support d'informations et au programme d'ordinateur etant les memes que ceux exposes ci-dessus concernant le procede d'optimisation selon ['invention, ils ne

seront pas rappeles ici.

D'autres aspects et avantages de la presente invention

appara^tront plus clairement a la lecture de la description de modes particuliers

de realisation qui va suivre, cette description etant donnee uniquement a titre

d'exemple non limitatif et faite en reference aux dessins annexes sur lesquels: - la figure 1 est un diagramme d'etats associe a un programme informatique; - la figure 2 est un premier graphe de decision equivalent au diagramme d'etats de la figure 1; - les figures 3 et 4 representent la modelisation de deux graphes de decision simplifies equivalents au premier graphe de decision lorsque certains evenements ne se produisent pas;

7 2841014

- la figure 5 est un organigramme illustrant les principales etapes d'un procede d'optimisation conforme a la presente invention dans un mode prefere de realisation; et - la figure 6 represente schematiquement un dispositif adapte a mettre un oeuvre un procede d'optimisation conforme a la presente invention,

dans un mode preferb de realisation.

Par ailleurs la description est accompagnee des annexes

suivantes: - annexe A: code source d'un programme informatique associe au diagramme d'etats de la figure 1; - annexe B: code source d'une fonction logicielle obtenue a partir du graphe de decision de la figure 3; - annexe C: code source d'une fonction logicielle obtenue a partir du graphe de decision de la figure 4; - annexe D: code source d'un exemple d'une fonction logicielle pour ['implantation evenementielle des fonctions logicielles des annexes B et C et - annexe E: code source d'un exemple d'une fonction logicielle pour ['implantation temporelle des fonctions logicielles des annexes B et C. La figure 1 represente un diagramme d'etats DE associe a un programme informatique P. Le diagramme d'etats DE comporte trots evenements d'entree 11,

12 et 13 et une commande O de controle d'un dispositif.

Le programme informatique P comporte deux sous-programmes SP1 et SP2, ces sous-programmes pouvant respectivement etre representes

par des automates A1 et A2 du diagramme d'etats DE.

Les automates A1 et A2 vent synchronises par un signal local S. Le sousprogramme SP1, est susceptible d'occuper deux etats predetermines A et B. A l'etat initial, le sous-programme SP1 est dans l'etat A. Conformement au diagramme de ia figure 1, lorsque le sous programme SP1 est dans l'etat A, ce sous-programme est susceptible

8 2841014

d'effectuer, en reponse a l'evenement 11, une transition entre cet etat A et un etat B. De meme, lorsque le sous-programme SP1 est dans l'etat B. ce sous-programme est susceptible d'effectuer une transition entre cet etat B et I'etat A en reponse a l'evenement 12. Au cours de la transition 12 faisant passer le sous-programme SP1 de l'etat B a l'etat A, le sousprogramme SP1 emet le signal S de synchronisation. Le sous-programme SP2 est. a l'etat initial dans un etat C. En reponse au signal de synchronisation S. le sous-programme SP2 effectue une transition entre l'etat C et un etat D. Quand le sous-programme SP2 est dans l'etat D, ce sous programme est susceptible d'effectuer, en reponse au signal S de synchronisation, une transition entre cet etat D et ltetat initial C. D'autre part, lorsque le sous-programme SP2 est dans 1'etat D, ce sousprogramme est susceptible de generer un signal O d'execution d'un

traitement predetermine en reponse a l'evenement 13.

La figure 2 est un premier graphe de decision GD equivalent au

diagramme d'etats DE de la figure 1.

Dans cette figure, les notations suivantes, telles que definies par S. Edwards dans le document "An Esterel compiler for large control-dominated systems". IEEE Transactions on Computer-Aided Design of Integrated Circuits and Sysfems 21(2), February 2002, vent utilisees: - Decision: decision sur la valeur d'une variable (1, 2) ou sur la presence d'un signal (Present, Absent); - Fork: creation de deux processus s'executant en parallele; - Join: fin du parallelisme cree par le "Fork"; - Action: Modification de la valeur d'une variable; - Emit: generation d'un signal entre les processus s'executant en parallele; et

- Terminator: fin du programme.

9 2841014

Ce premier graphe de decision GD comporte deux branches GD1 et GD2 respectivement equivalentes aux automates A1 et A2 decrits

precedemment en reference a la figure 1.

La generation d'un tel graphe est connue de l'homme du metier, et decrite dans le document cite ci-dessus. L'etat des sous-programmes SP1 et SP2 est respectivement memorise dans des registres e1 et e2. Plus prbcisement: lorsque le sous-programme SP1 est dans l'etat A, le registre e1 memorise la valeur 1; - lorsque le sous-programme SP1 est dans l'etat B. le registre e1 memorise la valeur 2; - lorsque le sous- programme SP2 est dans l'etat C, le registre e2 memorise la valeur 1; et - lorsque le sous-programme SP2 est dans l'etat D, le registre e2

memorise la valeur 2.

Le code source en langage C d'un programme informatique P associe au diagramme d'etats DE decrit precedemment en reference a la figure 1 est donne a l'annexe A. La ligne d'instruction L1, est une ligne de declaration des variables globales e1 et e2 memorisees dans les registres e1 et e2 d'une memoire vive 604 decrite ulterieurement en reference a la figure 6. Ces variables vent initialisees avec la valeur 1, afin de representer le fait que les sous-programmes

SP1 et SP2 vent respectivement dans les etats A et C a l'initialisation.

Les evenements 11, 12, et 13 et le signal de synchronisation S vent

associes a une variable informatique du meme nom.

Par convention on supposera qu'une variable representative d'un evenement ou du signal de synchronisation a pour valeur: - O lorsque ltevenement associe a cette variable est absent; et

- 1 lorsque l'evenement associe a cette variable est present.

Les variables 11, 12 et 13 vent initialisees a zero.

2841014

Dans l'exemple decrit ici, le code source du programme informatique P contient deux soul-parties SP 1 et SP2 correspondent

respectivement aux instructions des sous-programmes SP1 et SP2.

Ce code source peut etre obtenu a partir du graphe de decision GD de la figure 2 au moyen de 1'algorithme de generation decrit dans le document "An Esterel compiler for large control-dominated systems". IEEE Transactions on Computer-Aided Design of Integrated Circuifs and Systems

21 (2), February 2002.

Dans la suite de la description nous allons supposer que les

evenements 11 et 12 constituent un premier sous-groupe d'evenements, ces

evenements etant choisis parmi le groupe d'evenements {11, 12, 13}.

Dans une premiere variante preferee de realisation, chaque evenement est associe a une frequence maximale predeterminee a laquelle cet evenement est susceptible d'etre pris en compte par le systeme, les sous groupes d'evenements etant crees automatiquement pour regrouper les

evenements ayant sensiblement la meme frequence predeterminee.

Dans une deuxieme variante de realisation, les groupes d'evenements vent crees de fa,con a regrouper des evenements pouvant etre

traites simultanement par le systeme.

Ce sous-groupe d'evenements peut par exemple etre cree automatiquement en fonction du temps de reponse souhaite pour le traitement

des evenements.

La figure 3 represente la modelisation d'un deuxieme graphe de decision GD_i3 equivalent au premier graphe de decision GD lorsque les

evenements 11 et 12 vent absents.

Le deuxieme graphe de decision GD_13 est obtenu a partir du graphe de decision initial GD par application des quatre regles de simplification suivantes: Regle 1: Tout nceud "Decision" dont la valeur testee est connue est supprime. Seu le la b ranche correspondent a la valeu r con nue est conservee;

11 2841014

Regle 2: S'il n'existe aucune gbneration "Emit" sur un signal local, ce signal local est necessairement absent; Regle 3: Une branche d'un "fork" ne contenant ni modification de la valeur d'une variable ("action"), ni generation d'un signal ("Emit") peut etre supprimee; et Regle 4: Lorsque un "fork" ne comporte qu'une seule branche, ce

"fork" et le "join" correspondent peuvent etre supprimes.

Par application de ces regles de simplification: - les evenements 11 et 12 etant absents par hypothese, les nceuds "Decision" correspondents vent supprimes, seules les branches correspondent a ['absence du signal vent conservees, ceci par application de la regle 1; - la branche correspondent a la presence du signal 12 etant supprimee, il n'existe plus de generation du signal S (Emit). Par application de la regle 2, le signal s est necessairement absent; - en consequence, et par application de la regle 1, les nceuds "Decision" associes au signal S vent supprimes, seules les branches correspondent a ['absence de ce signal etant conservees; - la branche GD1 du "Fork" ne contenant plus ni "Action", ni "Emit" peut etre supprimee par application de la regle 3; et - le "fork" n'ayant plus qu'une seule branche, ce "fork" et le "join"

correspondent vent supprimes en application de la regle 4.

On obtient ainsi le deuxieme graphe de decision GD_13 de la figure 3.

De la meme fa,con que l'on a obtenu precedemment le code source du programme P a partir du graphe de decision GD, on obtient un code source d'une fonction logicielle P_i3 a partir du graphe de decision GD_13. Le code source du programme P_13 est donne a 1'annexe B. Bien entendu, cette fonction logicielle P_13 met en ceuvre les

transitions modelisees par le deuxieme graphe de decision GD_13.

La figure 4 represente la modelisation d'un troisieme graphe de decision GD_11_12 equivalent au graphe de decision GD de la figure 2 lorsque

l'evenement 13 est absent.

12 2841014

Un code source d'une fonction logicielle P_11_12 obtenu a partir du graphe de decision GD_11_12 est donne a 1'annexe C. On obtient ainsi deux fonctions logicielles P_13 et P_11_12 fonctionnellement equivalentes au programme informatique P respectivement lorsque les evenements 11 et 12 vent absents et lorsque 1'evenement 13 est absent. Ces fonctions peuvent etre implantees de fa,con "evenementielle" ou "temporelle", comme decrit ci-dessous en reference aux annexes D et E. L'annexe D donne un exemple d'une fonction logicielle event_P pour 1'impiantation evenementielle des fonctions logicielles P_11_12 et P13 dans une machine cible, ce qui signifie que ['execution des fonctions logicielles P_11 12 et P 13 est conditionnee a 1'apparition d'un evenement respectivement_

des sous-groupes d'evenements {11, 12} et {13}.

On suppose dans cet exemple que lorsqu'un evenement se produit, une fonction logicielle, non decrite ici, posse un message representatif

de ['occurrence de cet evenement dans une bo^te a lettres MBX.

La fonction logicielle event_P est une boucle sans fin de

traitement de ces evenements.

De fa,con connue de l'homme du metier de la programmation temps reel, lorsqutaucun evenement ne se produit, la fonction event_P reste bloquee dans l'appel, a la ligne d'instruction L2, de la fonction "get" de lecture

d'un message dans la bo^te aux lettres MBX.

En revanche, des qutun evenement se produit, la fonction "get" lit

cet evenement et le renvole, dans un registre 1.

Si l'evenement 11 ou 1'evenement 12 s'est produit, la fonction

P_11_12 est ensuite executee a la ligne d'instruction L3.

De meme, si l'evenement 13 s'est produit la fonction P_13 est executee. Quoi qutil en soit, a la suite de ['execution de ces fonctions, la fonction event_P execute a nouveau la fonction "get" dans l'attente de

ltevenement suivant.

13 2341014

Avantageusement, et conformement a la presente invention, lorsque l'evenement 13 se produit, seules les instructions du programme P_13 vent executees, ce qui represente une optimisation par rapport a ['execution de

la totalite du code du programme P d'origine.

De la meme fa,con, lorsque l'evenement 11 ou 12 se produit, seules

les instructions du programme P_11_12 vent executees.

Dans le cas d'une implantation evenementielle, il est done particulierement opportun de definir les sous-groupes constituent une partition de ['ensemble des evenements, les evenements d'un meme sousgroupe etant

susceptibles de se produire sensiblement simultanement.

L'annexe E donne un exemple d'une fonction logicielle tick_P d'implantation temporelle des fonctions logicielles P_11_12 et P13 dans une machine cible, ce qui signifie que ['execution de ces fonctions est effectuee

suivant des intervalles de temps predetermines, par exemple de fa,con cyclique.

De fa,con connue, la fonction logicielle tick_P est declenchee a

['expiration d'un compteur d'une horloge temps reel de la machine cible.

A cheque execution de cette fonction, le contenu d'un registre de

memoire TICK est incremente d'une unite.

Lorsque le contenu du registre de memoire TICK depasse une valeur predeterminee, 10 dans 1'exemple de 1'annexe E, la fonction logicielle

P_11_12 est executee et le contenu du registre est TICK reinitialise a zero.

D'autre part, a chaque execution de la fonction logicielle tick_P, la

fonction logicielle P_13 est executee.

Cette implementation permet de ne pas verifier systematiquement,

a chaque expiration du compteur, si chaque evenement s'est produit.

Une telle implantation est par exemple avantageuse pour le traitement des evenements en provenance d'un utilisateur de la machine cible, ces evenements ayant un delai de traitement moins critique que certains

evenements lies au systeme d'exploitation de cette machine.

Dans ce mode de realisation, il pourra etre interessant de placer un evenement critique dans des sous-groupes non disjoints. Par exemple, on

14 2841014

pourra choisir de former un sous-groupe regroupant tous les evenements, et

d'executer la fonction generee associee selon un cycle relativement lent.

On s'assure ainsi que tous les evenements vent traites regulierement. La figure 5 represente les principales etapes E500 a E560 d'un

procede d'optimisation conforme a la presente invention.

Au cours d'une premiere etape E500, le programmeur modelise sous forme d'un diagramme d'etats DE, le programme informatique P a optimiser. Au cours de cette etape de modelisation, le programmeur definit: - un groupe d'evenements 11, 12, 13 susceptibles de se produire au sein de la machine cible et affectant ['execution du programme P; - les transitions entre des etats A, C predetermines et, respectivement des etats B. D predetermines, effectuees par le programme P

en reponse a ces evenements.

L'etape E500 est suivie par une etape E510 de generation d'un premier graphe de decision GD a partir du diagramme d'etats DE defini a

l'etape E500.

L'etape E510 est suivie par une etape E520 au cours de laquelle on lit des sous-groupes d'evenements choisis parmi les evenements definis au

cours de l'etape de modelisation E500.

Le choix de ces sous-groupes d'evenements est effectue par le programmeur en fonction de certaines contraintes, a savoir par exemple le temps de reponse souhaite pour traiter un evenement ou la frequence probable

d'apparition d'un evenement.

D'autre part, le programmeur peut grouper avantageusement des evenements susceptibles de se produire simultanement dans un meme sous groupe. L'etape E520 est suivie par une boucle constituee par les etapes

E530 a E550 de traitement de chacun des sous-groupes lus a l'etape E520.

Plus precisement, l'etape E530 est une etape au cours de laquelle

on verifie si chacun des sous-groupes lus a l'etape E520 a ete traite.

2341014

Si tel n'est pas le cas, l'etape E530 est suivie par une etape E540 de modelisation d'un deuxieme graphe de decision equivalent au premier graphe de decision genere a l'etape E510 lorsque les evenements du groupe defini a l'etape E500 n'appartenant pas au sous-groupe en cours de traitement ne se produisent pas. De tels graphes de decision ont ete decrits precedemment en

reference aux figures 3 et 4.

L'etape E540 est suivie par une etape E550 de generation, dans un langage de programmation, par exemple le langage C, d'une fonction logicielle mettant en ceuvre les transitions du deuxieme graphe de decision

modelise a l'etape E540.

Dans un mode prefere de realisation, une fonction logicielle

unique est generee pour chaque deuxieme graphe de decision.

L'etape E550 est suivie par l'etape E530 deja decrite.

Lorsque tous les sous-groupes lus a l'etape E520 ont ete traites, I'etape E530 est suivie par une etape E560 d'implantation, dans la machine

cible, des fonctions logicieiles generees a l'etape E550.

Comme decrit precedemment, cette implantation peut se faire de facon evenementielle, de fagon temporelle, ou par toute combinaison de ces implantations. L'etape E560 term i ne le p rocede d'optim isation se lo n la p rese nte invention. La figure 6 represente schematiquement undispositif adapte a mettre un ceuvre un procede d'optimisation d'un programme informatique

conforme a la presente invention, dans un mode prefere de realisation.

Dans le mode prefere de realisation decrit ici, ce programme informatique est adapte, au cours d'au moins une desdites transitions, a generer un signal d'execution d'un traitement predetermine, par exemple un

signal de controle d'un equipement numerique.

Ce dispositif peut notamment etre constitue par un ordinateur.

16 2841014

Dans l'exemple de realisation decrit ici, le dispositif d'optimisation comporte un clavier 610, un ecran 609, relies a un port d'entrees-sorties 603

d'une carte de traitement 601.

La carte de traitement 601 comporte, relies entre eux par un bus d'adresses et de donnees 602: - une unite centrale de traitement 600; une memoire vive RAM 604; - une memoire morte ROM 605; - une memoire non volatile DISK 606 et

- le port d'entrees-sorties 603.

Chacun des elements illustres en figure 6 est bien connu de l'homme du metier des micro-ordinateurs et, plus generalement, des systemes de traitement de ['information. Ces elements commune ne vent done pas decrits ici. La memoire non volatile DISK 606, par exemple constituee par un disque cur, comporte notamment des registres pour memoriser: - le diagramme d'etats DE de modelisation du programme informatique P; - les sous-groupes d'evenements definis par le programmeur; - le premier graphe de decision GD et les graphes de decision simplifies GD_11_12 et GD_13; et - les codes sources des fonctions logicielles optimisees P_11_12 et P_13. La memoire vive 604 comporte notamment des registres e1, e2 pour memoriser les etats predbtermines A, B. C, D. La memoire morte 605 est adaptee a conserver le programme de fonctionnement de ['unite centrale de traitement 600. Wile comporte notamment un registre "Program" pour memoriser les instructions d'un programme mettant en oeuvre un procede de traitement conforme a ['invention, tel que decrit

precedemment en reference a 1'organigramme de la figure 5.

Dans un mode prefere de realisation, le dispositif d'optimisation comporte des moyens de generation d'un premier graphe de decision a partir

d'un diagramme d'etats.

Ces moyens de generation d'un graphe de decision vent par exemple constitues par un compilateur utilisant un langage graphique a base d'automates hierarchiques et de parallelisme tel que decrit dans le document "Representation and Analysis of Reactive Behavior: A synchronous Approach", Computationai Engineering in systems Applications, IEEE-SMC, Lille (France),

July 1996.

Le dispositif d'optimisation comporte des moyens de lecture des sousgroupes d'evenements determines par le programmeur. Dans le mode prefere de realisation decrit ici, ces sous-groupes d'evenements vent saisis au moyen du clavier 610, et les moyens de lecture vent constitues par les pilotes logiciels de ce clavier, adaptes a memoriser ces sous-groupes dans la memoire

non volatile DISK 606.

Dans un autre mode de realisation, les moyens de lecture vent adaptes a creer automatiquement les sous-groupe d'evenements en fonction de

la frequence de traitement souhaitee pour les evenements.

Le dispositif d'optimisation comporte egalement des moyens de modelisation d'un deuxieme graphe de decision utilisant les registres e1, e2 de la memoire vive 604, ce deuxieme graphe de decision etant equivalent au premier graphe de decision memorise dans la memoire non volatile DISK 606

lorsque certains evenements ne se produisent pas.

Le dispositif d'optimisation comporte egalement des moyens de generation, dans un langage de programmation, d'une fonction logicielle mettant en couvre les transitions modelisees par le deuxieme graphe de decision. Dans le mode prefere de realisation decrit ici ces moyens de modelisation et de generation vent constitues par le compilateur Esterel de S.

Edwards cite precedemment.

Le dispositif d'optimisation comporte aussi des moyens d/implantation d'une fonction logicielle dans la machine cible. Ces moyens

18 2841014

d/implantation vent en particuliers adaptes a realiser une implantation evenementielle ou une implantation temporelle de ces fonctions logicielles, au

sens de la presente invention.

Ces moyens d'implantation peuvent en particulier etre constitues des outils de generation automatique "Rapsody in C" commercialises par la societe l-Log ix, et q ui permettent de generer du code informatique d irectement implantable sur differents systemes d'exploitation, a savoir notamment les

produits VxWorks et Tornado de la societe Windriver.

19 2841014

ANNEXES

ANNEXE A

int el=l, e2=l; /* Ligne Ll */ P() { boolean S = 0; switch (el) { case l: if (Il) el = 2; goto Ll; case 2: SP1 if (I2) { S = l; el = l; } goto Ll; _}; Ll: - switch (e2) { case l: if (S) e2 = 2; break; SP2 case 2: if (S) e2 = l; else if (I3) output_O(); _ break; } }

ANNEXE B

PITS () {

if (e2 == 2) if (I3) output_O () }

2841014

ANNEXE C

P_I1_I2() {

boolean S = 0; switch (el) { case 1: if (I1) el = 2; goto L1; case 2: if (I2) { S = 1; el = 1; } goto L1; }; L1: switch (e2) { case 1: if (S) e2 = 2; break; case 2: if (S) e2 = 1; break; } }

ANNEXE D

event_P () { for (;;) { I = get (event, MBX); /* Ligne L2 */ switch(I) { case I1, I2: P_I1 I2(); /* Ligne L3 */ break; case I3:

P I3();

} }

*21 2841014

ANNEXE E

t i ck_P () { tick++; if (tick > 10) {

P_I1_I2 ();

tick = 0; } p_13 (); }

22 2841014

Claims (19)

REVENDICATIONS

1. Procede d'optimisation d'un programme informatique (P) susceptible d'effectuer, en reponse a au moins un evenement (11, 12, 13) appartenant a un groupe d'evenements ({11, 12, 13}), au moins une transition entre un premier etat (A, C) predetermine et un deuxieme etat (B. D) predetermine, lesdits etats predetermines (A, B. C, D) etant memorises dans des registres (e1, e2), ladite au moins une transition etant modelisee sous forme d'un premier graphe de decision (GD) utilisant lesdits registres (e1, e2), ledit procede etant caracterise en ce qu'il comporte les etapes suivantes: - lecture (E520) d'au moins un sous-groupe d'evenements ({11, 12}) choisis parmi ledit groupe d'evenements ({11, 12, 13}); modelisation (E540) d'au moins un deuxieme graphe de decision (GD_11_12) utilisant lesdits registres (e1, e2) et equivalent au premier graphe de decision (GD), lorsque les evenements (13) audit groupe d'evenements ({11, 12, 13}) n'appartenant pas audit sous-groupe d'evenements ({11, 12}) ne se produisent pas; et - generation (E550), dans un langage de programmation, d'au moins une fonction logicielle (P_11_12) mettant en oeuvre les transitions

modelisees par le deuxieme graphe de decision (GD_11_12).

2. Procede d'optimisation selon la revendication 1, caracterise en ce que ledit programme informatique est adapte, au cours d'au moins une desdites transitions, a generer un signal d'execution d'un traitement predetermine.

3. Procede d'optimisation selon la revendication 1 ou 2, caracterise en ce qutil comporte en outre une etape (E560) d'implantation de ladite au moins une fonction logicielle (P_11_12) conditionnant son execution a

I'apparition d'un evenement audit sous-groupe d'evenements ({11, 12}).

23 2841014

4. Procede d'optimisation selon la revendication 1 ou 2, caracterise en ce qu'il comporte en outre une etape d'implantation (E560) de ladite au moins une fonction logicielle (P_11_12) permettant son execution

suivant des intervalles de temps predetermines.

5. Procede d'optimisation selon l'une quelconque des

revendications 1 a 4, caracterise en ce que, au cours de ladite etape de lecture

(E520), on lit au moins deux sous-groupes d'evenements ({11, 12}, {13})

constituent une partition audit groupe d'evenements ({11, 12, 13}).

6. Procede d'optimisation selon l'une quelconque des

revendications 1 a 5, caracterise en ce que, au cours de ladite etape de lecture

(E520), on lit au moins deux sous-groupes d'evenements ({11, 12}, {12, 13} ) non disjoints.

7. Procede d'optimisation selon l'une quelconque des

revendications 1 a 6, caracterise en ce que ledit sous-groupe d'evenements

({11, 12}) est cree automatiquement en fonction de la frequence de traitement

souhaitee pour les evenements audit groupe d'evenements ({11, 12, 13}).

8. Procede d'optimisation selon l'une quelconque des

revendications 1 a 7, caracterise en ce qu'il comporte en outre une etape

prealable de generation (E510) audit premier graphe de decision (GD) a partir

d'un diagramme d'etats (DE).

9. Dispositif d'optimisation d'un programme informatique (P) susceptible d'effectuer, en reponse a au moins un evenement (11, 12, 13) appartenant a un groupe d'evenements ({11, 12, 13}), au moins une transition entre un premier etat (A, C) predetermine et un deuxieme etat (B. D) predetermine, lesdits etats predetermines (A, B. C, D) etant memorises dans des registres (e1, e2), ladite au moins une transition etant modelisee sous

24 2841014

forme d'un premier graphe de decision (GD) utilisant lesdits registres (e1, e2), ledit dispositif etant caracterise en ce qu'il comporte: - des moyens de lecture d'au moins un sous-groupe d'evenements ({11, 12}) choisis parmi ledit groupe d'evenements ({11, 12, 13}); - des moyens de modelisation d'au moins un deuxieme graphe de decision (GD_11_12) utilisant lesdits registres (e1, e2) et equivalent au premier graphe de decision (GD), lorsque les evenements (13) audit groupe d'evenements ({11, 12, 13}) n'appartenant pas audit sous-groupe d'evenements ({11, 12}) ne se produisent pas; et - des moyens de generation, dans un langage de programmation, d'au moins une fonction logicielle (P_11_12) mettant en oeuvre

les transitions modelisees par le deuxieme graphe de decision (GD_11_12).

10. Dispositif d'optimisation selon la revendication 9, caracterise en ce que ledit programme informatique est adapte, au cours d'au moins une desdites transitions, a generer un signal d'execution d'un traitement predetermine.

11. Dispositif d'optimisation selon la revendication 9 ou 10, caracterise en ce qutil comporte en outre, des moyens d'implantation de ladite au moins une fonction logicielle (P_11_12) conditionnant son execution a

['apparition d'un evenement audit sous-groupe d'evenements ({11, 12}).

12. Dispositif d'optimisation selon la revendication 9 ou 10, caracterise en ce qutil comporte en outre des moyens d'implantation de ladite au moins une fonction logicielle (P_11_12) permettant son execution suivant des

intervalles de temps predetermines.

13. Dispositif d'optimisation selon l'une quelconque des

revendications 9 a 12, caracterise en ce que lesdits moyens de lecture vent

adaptes a creer automatiquement ledit sous-groupe d'evenements ({11, 12}) en

284101 4

fonction de la frequence de traitement souhaitee pour les evenements audit

groupe d'evenements ({11, 12, 13}).

14. Dispositif d'optimisation selon l'une quelconque des

revendications 9 a 13, caracterise en ce qu'ii comporte en outre des moyens de

generation audit premier graphe de decision (GD) a partir d'un diagramme

d'etats (DE).

15. Systeme informatique caracterise en ce qu'il comporte des moyens adaptes a mettre en aeuvre un procede d'optimisation selon l'une

quelconque des revendications 1 a 8.

16. Systeme informatique caracterise en ce qu'il comporte un

dispositif d'optimisation selon l'une quelconque des revendications 9 a 14.

17. Compilateur caracterise en ce qu'il comporte des moyens adaptes a mettre en ceuvre un procede d'optimisation selon l'une quelconque

des revendications 1 a 8.

18. Support d'informations risible par un systeme informatique, eventuellement totalement ou partiellement amovible, notamment CD-ROM ou support magnetique, tel un disque dur ou une disquette, ou support transmissible, tel un signal electrique ou optique, caracterise en ce qu'il comporte des instructions d'un programme d'ordinateur permettant la mise en

ceuvre d'un procede d'optimisation selon l'une quelconque des revendications 1

a 8, lorsque ce programme est charge et execute par un systeme informatique.

19. Programme d'ordinateur stocke sur un support d'informations, ledit program me comportant des instructions permettant la mise en aeuvre d'un

procede d'optimisation selon l'une quelconque des revendications 1 a 8, lorsque