FR2797962A1

FR2797962A1 - Procede de conversion de types de variables codees dans un programme informatique et systeme de traduction de programme informatique correspondant

Info

Publication number: FR2797962A1
Application number: FR9910696A
Authority: FR
Inventors: Francois Pierre Pottier
Original assignee: Trusted Logic SAS
Current assignee: Trusted Logic SAS
Priority date: 1999-08-23
Filing date: 1999-08-23
Publication date: 2001-03-02
Anticipated expiration: 2019-08-23
Also published as: FR2797962B1

Abstract

Un procédé de conversion et un système de traduction de type de variables numériques ou littérales respectivement d'un programme informatique dans lequel on associe (100) à ces variables un type de variables spécifique, codées sur 2p bits, comportant au moins les types de variable redondante (red), dont les p bits de poids fort ont une valeur redondante vis-à-vis des bits de poids faible, variable verrouillée (lock) dont les p bits de poids fort ont une valeur déterminée non pertinente pour le programme informatique, et variable pseudo-entier (p-int), toute variable de ce dernier type étant quelconque du point de vue de sa valeur et de son utilisation par le programme informatique traduit. Ceci permet d'adapter (101), (102) le type de variable et le nombre de bits affectés aux variables numériques par suppression des bits de poids fort des variables auxquelles un type de variable spécifique redondante (red) ou verrouillée (lock) a été attribué.Application à la traduction de code objet JVM en code objet JCVM.

Description

Procédé de conversion de types de variables codées dans un programme informatique et système de traduction de programme informatique correspondant.

L'invention est relative à un procédé de conversion de types de variables codées dans un programme informatique et à un système de traduction de programme informatique basé sur un tel procédé.

A l'heure actuelle, la miniaturisation des systèmes électroniques, et, par conséquence, des systèmes informatiques incorporant de tels systèmes électroniques, pose le problème de la portabilité des programmes informatiques, en particulier des applications susceptibles d'être exécutées par ces systèmes.

Sauf à proposer une réécriture complète de ces programmes informatiques, ou applications, en fonction du type de microprocesseur utilisé, et donc du système d'exploitation associé à chacun d'eux, l'adaptation ou la traduction de ces programmes informatiques ou applications à différents types de systèmes informatiques ne peut être réalisée sans difficultés réelles.

C'est en particulier le cas pour les systèmes embarqués ou cartes électroniques munies d'un microprocesseur, encore appelées cartes à puce.

Avec l' avènement des langages de haut niveau tels que le langage JAVA, différentes versions de machines virtuelles ont ainsi vu le jour en fonction du type de système informatique hôte.

La machine virtuelle JavaCard, désignée par machine JCVM, est une variante de la machine virtuelle JAVA, désignée par JVM, cette variante étant plus

particulièrement destinée aux systèmes embarqués ou cartes à puce.

Alors que le jeu d'instructions de la machine JCVM présente de nombreux points communs avec celui de la machine JVM, la machine JCVM utilise des mots de 16 bits, au lieu de 32 bits, afin de s'adapter aux microprocesseurs de capacité plus faible.

Du point de vue du créateur du programme informatique en code source, grâce au langage de haut niveau, tel que le langage JAVA, ce programme informatique ou application peut être exécuté, ainsi qu'illustré en figure la, soit sur une machine de bureau, lorsque le code source est compilé en code objet pour une machine JVM, soit sur une carte à puce ou un système embarqué, lorsque le code source est compilé en code objet pour une machine JCVM.

Il est naturellement indispensable que le comportement de l'application exécutée par l'une ou l'autre des machines JVM ou JCVM soit identique, afin de ne pas en modifier les fonctionnalités.

Il existe actuellement sur le marché des compilateurs JVM permettant de transformer un programme code source écrit en langage JAVA en une série d'instructions JVM, exécutables par une machine JVM.

Une solution, afin de mettre en #uvre une machine JCVM, peut consister à développer un compilateur JCVM indépendant, capable d'engendrer une série d'instructions JCVM exécutables par une machine JCVM.

Cette solution présente des inconvénients parmi lesquels un risque d'absence de choix du compilateur JCVM

pour l'utilisateur, pour des raisons de compatibilité des compilateurs mis sur le marché par différents éditeurs.

Un autre inconvénient de cette solution réside dans la difficulté de la preuve de la fidélité des applications obtenues à partir de deux compilateurs distincts, compilateur JVM et compilateur JCVM. En effet, dans le cas où l'un de ces compilateurs comporte un défaut, un tel défaut n'est normalement pas réintroduit par l'autre compilateur, les applications JVM et JCVM pouvant alors être différentes.

La présente invention a pour objet de remédier aux inconvénients précités des systèmes de l'art antérieur, par la mise en #uvre d'un procédé de conversion de types de variables codées dans un programme informatique et d'un système de traduction de programme informatique, permettant d'effectuer une traduction du code objet exécutable par une machine virtuelle, telle qu'une machine JVM, en un code objet exécutable par une autre machine virtuelle, telle qu'une machine JCVM.

Un autre objet de la présente invention est en outre la mise en #uvre d'un procédé de conversion de types de variables codées dans un programme informatique et d'un système de traduction de programme informatique unique, indépendant et distinct de tout compilateur, permettant d'apporter la preuve de la fidélité de la traduction, du fait de l'identité du programme informatique ou application de départ et du programme traduit.

Un autre objet de la présente invention est en outre la mise en #uvre d'un procédé de conversion de types de variables codées dans un programme informatique et d'un système de traduction de programme informatique permettant

de préserver la sémantique du programme informatique traduit présentant, de ce fait, un comportement identique à celui du programme informatique de départ, testé sur une machine de développement.

Un autre objet de la présente invention est en outre la mise en #uvre d'un procédé de conversion de types de variables codées dans un programme informatique et d'un système de traduction de programme informatique permettant d'engendrer un code objet du programme informatique traduit de qualité optimale en termes de compromis de taille, de rapidité d'exécution et de consommation de mémoire vive.

Un autre objet de la présente invention est enfin, dans le cas de la traduction d'un programme informatique de départ, machine JVM, en un programme informatique traduit, machine JCVM, l'introduction d'un choix du nombre de bits de codage des variables numériques du programme informatique traduit, sur 2p = 32 où p = 16 bits, afin d'éviter l'appel d'instructions JCVM manipulant des entiers codés sur 2p = 32 bits, toutes les machines JCVM actuellement sur le marché n'utilisant pas ce type de variable.

Le procédé de conversion de type de variables numériques ou littérales codées dans un programme informatique, dans lequel les variables numériques sont codées sur 2p bits, conversion par entités de 2p bits respectivement p bits pour un processeur destiné à exécuter ce programme informatique, objet de la présente invention, est remarquable en ce qu'il consiste à associer à ces variables numériques un type de variables spécifique comportant au moins un type de variable redondante (red),

codée sur 2p bits, dont les p bits de poids fort ont une valeur redondante vis-à-vis d'au moins un des bits de poids faible, un type de variable verrouillée (lock) codée sur 2p bits dont les p bits de poids fort ont une valeur déterminée non pertinente pour ce programme informatique et un type de variable pseudo-entier (p-int), codée sur 2p bits, toute variable numérique de type pseudo-entier (p-int) étant quelconque, tant du point de vue de sa valeur numérique que de son utilisation par le programme informatique traduit. Ceci permet d'adapter le type de variable et le nombre de bits affectés aux variables numériques pour un processeur destiné à exécuter ce programme informatique, par suppression des bits de poids fort des variables auxquelles est affecté un type de variable spécifique de type de variable redondante ou verrrouillée.

Le système de traduction d'un programme informatique constitué par une suite d'instructions et contenant des variables numériques et littérales codées et dans lequel les variables numériques sont codées sur 2p bits, traduction par conversion de types de variables par entités de 2p bits respectivement p bits pour un processeur destiné à exécuter ce programme informatique, objet de la présente invention, est remarquable en ce qu'il comporte au moins un module analyseur du type des variables du programme informatique instruction par instruction, ce module analyseur permettant d'établir indépendamment, pour chaque instruction successive courante, un système de contraintes logiques, à chaque variable du programme informatique étant associée pour chaque instruction courante une variable de contrainte.

Le système de contraintes logiques associé à chaque instruction courante représente une dépendance entre les différents états successifs du processeur d'exécution de la suite d'instructions, cette relation de dépendance étant établie à partir des contraintes reliant les types de variables des variables numériques. Un module solveur reçoit l'ensemble des systèmes de contraintes logiques délivré par le module analyseur et permet de calculer une solution par attribution d'une valeur selon un type de variables spécifique à chaque variable de contrainte, de façon que l'ensemble des contraintes des systèmes de contraintes soit satisfait. L'existence d'une solution permet d'attribuer à chaque variable du programme informatique le type de variable attribué à la variable de contrainte correspondante.

Un module analyseur de représentation reçoit l'information de type de variable attribué à chaque variable numérique du programme informatique et permet de déterminer la représentation de chaque variable sous forme de codage sur p bits ou 2p bits, à chaque variable numérique étant attribué un choix de représentation sur p ou 2p bits. Un module émetteur permet d'engendrer à partir du programme informatique analysé instruction par instruction, de la représentation de chaque variable sous forme de codage sur p bits ou 2p bits, un programme informatique traduit.

Le procédé de conversion de type de variables numériques ou littérales codées dans un programme informatique et le système de traduction d'un programme informatique, objets de la présente invention, trouvent application à tout type d'applications, en particulier à la conversion de variables et à la traduction de

programmes informatiques sous forme de code objet exécutables par des machines JVM en programmes informatiques exécutables par des machines JCVM.

Ils seront mieux compris à la lecture de la description et à l'observation des dessins dans lesquels, outre la figure la relative à l'art antérieur : - la figure lb représente, à titre illustratif, un schéma synoptique du processus de traduction d'un programme informatique de départ en un programme informatique traduit, conformément à l'objet de la présente invention ; - la figure lc représente, à titre illustratif, un organigramme relatif à un procédé de conversion de variables numériques conforme à l'objet de la présente invention ; - la figure 2 représente, sous forme de schéma fonctionnel, un système de traduction d'un programme informatique conforme à l'objet de la présente invention ; - la figure 3a représente un organigramme du processus d'analyse de type de variable mis en #uvre par un module analyseur de type, constitutif du système de traduction d'un programme informatique objet de la présente invention, tel que représenté en figure 2 ; - la figure 3b représente la structure fonctionnelle d'un module solveur, constitutif du système de traduction d'un programme informatique objet de la présente invention, tel que représenté en figure 2 ; - la figure 3c représente un organigramme du processus de résolution des contraintes mis en #uvre par la module solveur représenté en figure 3b ;

la figure 3d représente la structure fonctionnelle d'un module analyseur de représentation constitutif du système de traduction d'un programme informatique objet de la présente invention, tel que représenté en figure 2 ; - la figure 3e représente un organigramme du processus d'analyse de représentation mis en #uvre par le module d'analyse de représentation représenté en figure 3d ; la figure 3f représente un organigramme du processus mis en #uvre par le module émetteur de code traduit constitutif du système de traduction représenté en figure 2.

Préalablement à une description proprement dite du procédé de conversion de types de variables numériques ou littérales codées dans un programme informatique, objet de la présente invention, une approche de la problématique soulevée par la mise en #uvre d'un tel procédé et d'un système de traduction correspondant, sera donnée ci-après en liaison avec la figure lb.

En référence à la figure précitée, le procédé de conversion de types de variables numériques ou littérales et le système de traduction correspondant, objets de l'invention, ont pour but, à partir du code objet d'un programme informatique constitué par exemple par la série d'instructions exécutables par une machine JVM, de mettre en #uvre une conversion de type des variables manipulées dans ce programme informatique et une traduction de ce dernier en un code objet, tel que celui exécutable par une machine JCVM, dans lequel les variables numériques sont traduites par codage sur 2p = 32 ou lp =16 bits.

En raison du fait que le code objet fourni au processus de conversion de types de variables et au système de traduction est déjà compilé, un certain nombre d'informations relatives aux variables contenues dans ce programme informatique sont manquantes. En particulier, il n'existe plus aucune distinction entre variables dites de type short codées sur p = 16 bits et variables de type entier int codées nécessairement sur 32 bits. La raison de cette absence d'information réside dans le fait que toutes les variables nécessitent exactement un mot, ce mot, c'est-à-dire l'entité de stockage de base, correspondant à 2p = 32 bits dans le cas de la machine JVM.

Alors que cette information de type est absente d'une machine JVM, la machine JVM permettant d'exécuter une série d'instructions constitutives du code objet précité, cette information est essentielle lors de la traduction vers la machine JCVM, pour laquelle les variables numériques sont codées par entités de 16 ou 32 bits, l'entité de stockage dans ce cas-là étant égale à p = 16 bits. Dans ces conditions, une entité de type short n'occupe toujours qu'un mot, alors qu'une entité de type int nécessite le codage sur deux mots, c'est-à-dire 2p bits.

Afin d'assurer la mise en #uvre du procédé de conversion de types de variables numériques et du système de traduction d'un programme informatique, objet de la présente invention, il est donc nécessaire de restituer l'information perdue.

A priori, il existe plusieurs approches afin de restituer une telle information :

une première approche, désignée par approche naïve optimiste, consiste à supposer que toutes les variables entières manipulées par le programme informatique sont de type short. Une telle approche conduit à un code objet de bonne qualité permettant d'atteindre les objectifs de qualité optimale du code objet traduit et d'éviter d'avoir recours aux instructions manipulant des entiers de 32 bits, en particulier dans le cas de la traduction d'une machine JVM vers une machine JCVM, ainsi que mentionné précédemment dans la description. Toutefois, une telle supposition n'est pas toujours justifiée et il apparaît difficile de déterminer si un programme informatique donné permet ou non une telle approche. Cette approche, minimaliste, apparaît donc incomplète et dangereuse.

- une deuxième approche, désignée par approche naive pessimiste, consiste à supposer que toutes les entités entières manipulées par le programme informatique traduit sont cette fois de type int. Une telle approche apparaît sûre car elle permet d'atteindre l'objectif visant à préserver la sémantique du programme fourni du fait de la traduction, ainsi que mentionné précédemment dans la description. Toutefois, une telle approche donne de très mauvais résultats en termes de taille du code objet traduit.

- enfin, une troisième approche, dite approche intelligente, consiste à ignorer tout présupposé et à effectuer une analyse du programme informatique à traduire pour restituer les informations perdues et en déduire une traduction adaptée. Dans ces conditions, du fait que l'information de type restituée est correcte, la

traduction l'est également. L'ensemble des objectifs précités précédemment mentionnés dans la description est atteint, l'opération d'analyse fine du type des variables ayant pour effet de permettre la production d'un code objet traduit de très bonne qualité satisfaisant à l'ensemble des critères précédemment mentionnés dans la description.

Des exemples de mise en #uvre de traduction de codes objets illustrés par les codes sources écrits en langage JAVA pour deux programmes désignés par Hybrid et Tricky, seront maintenant donnés en liaison avec les tableaux Tl à T5 joints en annexe.

Le programme informatique Hybrid selon le tableau Tl correspond à une application telle qu'un porte-monnaie électronique par exemple et utilise des variables de 16 bits comme de 32 bits, ce qui justifie le nom mnémotechnique de Hybrid attribué à ce dernier.

Le programme correspondant au tableau Tl précité ne peut être exécuté qu'à la condition que la machine JCVM utilisée soit capable de gérer les entiers de 32 bits.

Le programme Tricky contenu dans le tableau T2 est au contraire destiné à être utilisé sur toutes les machines JCVM et ne comporte, dans ce but, aucune variable de type de variable entier int.

Le programme introduit au tableau T2 comporte toutefois l'erreur ci-après : pour effectuer l'addition ofs+size, il faut d'abord étendre les types de ces variables qui occupent 16 bits chacune à des entiers codés sur 2p = 32 bits, puis additionner ces dernières.

L'opérateur de comparaison d'infériorité obéit à la même règle et, en conséquence, la variable index est également

étendue à 32 bits puis comparée au résultat de l'addition.

Afin de préserver la sémantique du programme Tricky donné au tableau T2, lors d'une traduction en machine JCVM, il est nécessaire de conserver la comparaison précitée. Il est donc nécessaire d'utiliser les opérations sur 32 bits des machines JCVM. Le programme précité ne fonctionne alors que sur des systèmes embarqués ou cartes à puce capables de gérer les entiers codés sur 32 bits.

Pour arriver à utiliser un tel programme sur des cartes à puce ou systèmes embarqués gérant uniquement les entiers codés sur 16 bits, il est nécessaire de modifier le programme Tricky donné au tableau T2 en modifiant l'instruction for ainsi que représenté au tableau T3 joint en annexe.

Alors que pour cette instruction modifiée représentée au tableau T3 l'addition est effectuée sur 32 bits, le résultat est aussitôt converti en une valeur de type short codée sur p = 16 bits et la comparaison s'effectue sur les entités codées sur p = 16 bits. Il est alors possible d'effectuer l'addition de même que la comparaison sur p = 16 bits seulement, sans toutefois modifier la sémantique du programme. Il apparaît ainsi qu'une solution simple existe à la traduction d'un programme de type code objet d'une machine JVM vers une machine JCVM. Toutefois, il est indispensable de faire appel aux notions les plus subtiles manipulées par l'homme de l'art.

En référence aux exemples fournis aux tableau Tl à T3 précités, il apparaît que l'approche naïve optimiste souffre des désavantages ci-après. Hypothèse de codage sur p = 16 bits quelque soit le type de variables non toujours

vérifiée : dans un tel cas, le code objet Tricky représenté au tableau T2 ne peut être directement transporté vers une carte à puce. Il n'est alors pas aisé pour l' homme de l' art de s'assurer qu'une telle hypothèse est satisfaite. En particulier, la mise en #uvre d'un traducteur naïf optimiste visant à effectuer la traduction d'un programme Tricky représenté au tableau T2 ne permet pas de préserver la sémantique du programme et le programme informatique traduit risque de présenter un comportement différent sur la carte à puce de celui qu'il présentait sur la machine de développement.

Une approche naïve pessimiste, ainsi que mentionné précédemment, permet d'espérer préserver la sémantique du programme d'origine lors de la traduction. Alors que le code objet produit du fait de la traduction ne pourra pas fonctionner sur toutes les cartes à puce, puisque le jeu d'instructions des machines JCVM à 32 bits sera utilisé de façon intensive, en outre, l'espace mémoire requis par le programme traduit sera dans le pire cas doublé car chaque variable numérique de type entier int nécessitera 2p = 32 bits au lieu de p = 16 bits de codage. Ce dernier inconvénient est particulièrement gênant sur les cartes à puce actuelles, lesquelles ne disposent que d'une quantité limitée de mémoire vive. En outre, le code objet engendré du fait d'une telle traduction se révèle de très mauvaise qualité car il contient un très grand nombre d'opérations de conversion. On indique en effet que bien que toutes les variables numériques soient codées sur 2p = 32 bits, certaines conversions sont rendues nécessaires par le jeu d'instructions JCVM lui-même, car un certain nombre

d'instructions exigent des opérandes ou produisent des résultats exprimés et codés sur p = 16 bits.

Différents exemples des résultats produits par l'approche naïve pessimiste seront maintenant donnés en référence au tableau T4 et au tableau TS joints en annexe.

Dans les tableaux T4 et T5, la colonne de gauche donne le code objet correspondant au code source JAVA original et la colonne de droite donne le code objet traduit pour chaque instruction.

A l'observation du tableau T4 précité, lequel correspond à l'instruction mTransactionCounter++ du code objet Hybrid donné au tableau Tl, on remarque que l'instruction getfield #5 est traduite par deux instructions selon les instructions JCVM, les instructions getfield s #5 et s2i.

Alors que l'instruction JCVM getfield s #5 accède au champ mTransactionCounter et place la valeur sur la pile sous forme d'un mot de 16 bits, un traducteur naïf procède instruction par instruction et se ramène à l'hypothèse que toute entité est codée sur 32 bits. Ainsi, une fois l'accès au champ effectué, il est donc nécessaire que sa valeur apparaisse sur la pile sous forme d'un mot de 32 bits. Dans ce but, l'instruction supplémentaire s2i est engendrée. La même problématique peut être observée lors de la traduction des instructions i2s et putfield #5 du code objet JVM. Un tel phénomène est d'autant plus regrettable que la série d'instructions précitée aurait pu être traduite à l'aide d'instructions JCVM 16 bits uniquement. Ainsi, l'hypothèse pessimiste s'applique à l'ensemble du programme, même si les calculs sur 32 bits dans ce dernier sont rares.

Un autre exemple est donné dans le tableau T5 joint en annexe relativement au programme Tricky pour la traduction d'instructions vector[index] = 0.

En référence au tableau T5 précité, la problématique est sensiblement la même que précédemment mais apparaît de manière encore plus nette dans le cas de l'instruction sastore. Une telle instruction attend deux opérandes codés sur 16 bits chacun. Toutefois, les instructions précédentes ont placé sur la pile deux quantités de 32 bits chacune. Il est donc nécessaire d'effectuer deux opérations de conversion, ce qui nécessite l'utilisation de l'instruction swap~x. En outre, on remarque que l'espace occupé par les variables locales ou variables contenues dans chaque instruction a doublé.

Ainsi, la variable index qui occupait précédemment l'emplacement n 3 occupe à présent l'emplacement n 7.

Le code objet ainsi obtenu après traduction, code objet JCVM, est de très mauvaise qualité. Des solutions consistant à ajouter un optimiseur à fenêtre, connu sous le vocable anglo-saxon de Peephole, ne permettent de porter remède que partiellement à la mauvaise qualité du code obtenu.

Le procédé de conversion de types de variables numériques ou littérales codées dans un programme informatique, objet de la présente invention, sera maintenant décrit en liaison avec les figures lb et le.

D'une manière générale, le procédé, objet de la présente invention, consiste à analyser le code objet du programme informatique à traduire pour distinguer les quantités qui peuvent être stockées sur p = 16 bits de celles qui impliquent nécessairement un stockage sur 2p =

32 bits. Lorsqu'une telle analyse a été effectuée, cette analyse sert de guide à la traduction proprement dite, ce qui permet ainsi d'obtenir un résultat équivalent à ce qu'aurait proposé un traducteur humain expérimenté.

Ainsi, en référence à la figure le, le procédé objet de la présente invention consiste à associer aux variables numériques du programme informatique à traduire, c'est-à-dire, dans l'exemple de réalisation donné, du code objet exécutable par la machine JVM, un type de variables spécifique comportant au moins un type de variable redondante, désignée par red, codé sur 2p bits dont les p bits de poids fort ont une valeur redondante vis-à-vis d'au moins un des bits de poids faible. Par valeur redondante vis-à-vis d'au moins un des bits de poids faible, on indique que tous les bits de poids fort d'une variable redondante red ont par exemple la même valeur qui correspond à celle de l'un des bits de poids faible. Dans un mode de réalisation non limitatif, la valeur choisie du bit de poids faible est la valeur du bit de signe de la variable de type short représentée par les bits de poids faible précités. D'autres types de redondance peuvent être envisagés.

En outre, le type des variables spécifique comporte également au moins un type de variable verrouillée lock codées sur 2p bits, dont les p bits de poids fort ont une valeur déterminée non pertinente pour le programme informatique traduit. Le caractère de nonpertinence des bits de poids fort précités s'entend de l'absence d'utilisation de ces derniers par le programme traduit, ce programme étant néanmoins en mesure d'exécuter

son calcul même dans le cas où ces bits auraient été rendus inaccessibles par un verrou.

Enfin, le type des variables spécifique comporte également un type de variable pseudo-entier p-int, codée sur 2p bits. Toute variable numérique à laquelle le type pseudo-entier (p-int) est susceptible d'être affecté est quelconque, tant du point de vue de la valeur numérique de cette variable que de son utilisation par le programme informatique traduit.

L'introduction des types de variables spécifiques précités, variables redondantes, variables verrouillées et variables pseudo-entier, permet d'adapter le type de variables et le nombre de bits affectés aux variables numériques précitées pour un processeur destiné à exécuter le programme informatique traduit, par suppression des bits de poids fort des variables auxquelles est affecté un type de variable spécifique, de type de variable redondante ou verrouillée.

Ainsi, en référence à la figure lc, pour un code objet correspondant à une machine JVM par exemple, on considère les variables numériques de ce code objet codées sur 2p bits, cette machine JVM permettant d'exécuter une
K-1 suite d'instructions notée Ii . i = 0
Avec la notation précédente, le code objet machine JVM constitutif du programme informatique à traduire est réputé comporter K instructions successives manipulant, au niveau de chaque instruction, des variables numériques locales, i désignant un indice d'instruction.

Sur la figure lc, l'association aux variables numériques d'un type de variable spécifique comportant au

moins le type de variable redondante red, le type de variable verrouillée lock et le type de variable pseudoentier p-int est représentée à l'étape 100.

L'étape 100 est elle-même suivie d'une étape 101 consistant à introduire pour les variables spécifiques précitées, une relation d'ordre dite relation de soustypage s'écrivant sous la forme : red p-int lock
La relation d'ordre ou de sous-typage précitée s'exprime de la façon ci-après : - toute variable de type de variable redondante red admet a fortiori comme type de variable le type de variable pseudo-entier p-int ; - toute variable de type pseudo-entier p-int admet a fortiori comme type de variable le type de variable verrouillée lock.

L'étape 101 est alors suivie d'une étape 102 consistant par exemple, pour une instruction I de rang i donné, et finalement pour toutes les instructions de rang i=l à i=K, à établir des contraintes symboliques sur le type des variables locales numériques manipulées par chaque instruction, vis-à-vis de la relation d'ordre ou relation de sous-typage explicitée à l'étape 101, ce qui permet de discriminer les variables numériques entre entités représentables sur p bits et entités représentables sur 2p bits.

L'ensemble des contraintes s'écrit :

L'ensemble des étapes 100,101 et 102 représentées en figure le permet, par appel à ces définitions de types de variables et à la relation de sous-typage, d'obtenir la traduction pour au moins une instruction, et finalement pour toutes les instructions, du code objet de départ, exécutable par une machine JVM, en code objet traduit, exécutable par une machine JCVM.

Deux exemples de mise en #uvre du procédé objet de la présente invention sur les programmes informatiques de départ Hybrid.Transaction, respectivement Tricky. blitVector seront donnés en liaison avec les tableaux T6 et T7 joints en annexe.

Pour les tableaux T6 et T7, de même que pour les tableaux précédents, la colonne de gauche représente le code objet exécutable par une machine JVM et la colonne de droite représente le code objet exécutable par une machine JCVM après traduction.

En référence au tableau T6, on constate que le jeu d'instructions JCVM 32 bits n'a été utilisé que là ou cela était indispensable.

Le reste du code produit qui manipule des entités codées sur p = 16 bits n'a pas été affecté.

Il en est de même relativement au code objet Tricky.blitVector représenté au tableau T7.

En référence au tableau T7 précité, on observe que les seules opérations de conversion sont celles nécessitées par l'addition et la comparaison sur 32 bits.

Enfin, on remarquera que l'instruction index++ qui demandait cinq instructions machine JVM a été traduite par une seule instruction machine JCVM, à savoir l'instruction sine.

Ainsi, et dans le cadre de la mise en #uvre du procédé et du système objets de la présente invention, les valeurs numériques admettent les types ci-après : - une valeur entière admet le type de variable redondante red si cette valeur est suffisamment petite pour être représentée sur 16 bits. De manière plus précise, un mot de 32 bits présente le type de variable redondante red si ses bits 16 à 31 sont égaux au bit 15, c'est-à- dire si dans ce cas-là, ils forment une extension de signe, d'où la désignation du type de variable red.

- Toute valeur entière admet le type pseudo-entier p-int.

- Une valeur entière admet le type de variable verrouillée, lock, si l'on interdit l'utilisation de ses bits 16 à 31 dans tout calcul ou, de manière plus précise, si l'on exige qu'en cas d'utilisation dans un calcul le résultat final de ce calcul ne dépende pas des bits 16 à 31 de poids fort.

Ainsi, dans le cas d'un processus de traduction de programme informatique mis en #uvre par le système objet de la présente invention, une valeur de type pseudo-entier p-int est a priori entièrement quelconque et le programme traduit devra coder une telle valeur sur 2p = 32 bits comme le programme original pour la représenter.

- Une valeur à laquelle le type de variable redondante red a été attribué présente un contenu particulier, puisque ses bits de poids fort ont une valeur redondante.

- Une valeur de variable de type variable verrouillée, lock, est destinée à une utilisation future particulière au cours de laquelle la valeur de ses bits de poids fort est non pertinente.

Dans les deux derniers cas précités, type de variable redondante et type de variable verrouillée, le programme traduit peut se contenter de représenter la valeur de la variable correspondante sur p = 16 bits au lieu de 2p =32 bits. En effet, dans ces cas-là, il n'est pas nécessaire de garder trace des bits de poids fort car ils sont, soit connus, soit inutiles.

Ainsi, l'abandon des bits de poids fort est justifié dans deux cas. Le premier cas concerne leur redondance, ce cas pouvant être rapproché de la distinction qui existe entre les types de variables entier, int, et court, short, du langage JAVA en code source. Le second motif de leur suppression est leur nonpertinence, cette notion étant absente du système à deux types de variables entier, int et short, l'introduction du type de variable verrouillée, lock, permet ainsi d'exprimer cette notion de non-pertinence et d'assurer le processus de conversion de type de variables et de traduction de programme informatique tel que défini dans la présente demande.

Bien entendu, la relation d'ordre ou relation de sous-typage entre types de variables spécifiques conformément au procédé objet de la présente invention,

est essentielle car cette relation d'ordre permet en fait de transformer le problème de l'identification des bits redondants ou non pertinents en un problème de satisfaction de contraintes symboliques, cette reformulation du problème en permettant la résolution par l'intermédiaire d'un module solveur de contraintes, ainsi qu'il sera décrit ultérieurement dans la description.

D'une manière générale, on indique que les types de variables fournis par le langage JAVA en code source, à savoir les types de variables int et short, ne permettent pas en tant que tels la mise en #uvre d'un processus de conversion de type et corrélativement de traduction d'un programme informatique compilé en code objet.

L'adoption des types de variables proposés par le langage en code source JAVA pour les variables numériques, type entier int et type court, short, implique l'utilisation de ces types de variables afin de classifier chaque entité numérique manipulée par le programme. Pour un programme comportant les deux lignes de code suivantes : short x, y, z; z=(short) (x+y) ; l'entité (x+y) est de type entier, int, et non pas short.

En effet, une addition est susceptible de provoquer un débordement, la somme de eux entiers représentables sur 16 bits n'étant pas forcément représentable sur cette même quantité de bits. Toutefois, sachant que le résultat de l'addition sera ensuite tronqué à 16 bits par conversion par l'instruction (short), il est souhaitable, dans la version de machine JCVM du programme, d'effectuer directement une addition sur 16 bits à l'aide de

l'instruction sadd. Dans ce but, il est nécessaire d'attribuer le type short à l'entité (x+y) puisque c'est le typage du résultat qui guide la traduction des instructions correspondantes. Une telle attribution n'est pas possible dans le langage JAVA de code source. Un tel système de typage de variable est donc trop grossier pour permettre une traduction satisfaisante.

Ainsi, afin de résoudre un tel problème, le procédé de conversion de types de variables, objet de la présente invention, adopte non pas deux, mais trois types de variables numériques désignées par variables de type redondant, red, variables de type entier int, et variables de type verrouillée, lock.

La notion de sous-typage sera maintenant introduite en référence à un exemple spécifique.

Pour un programme de type code source JAVA de la forme ci-après : short x ; int y; y = x + 1; la variable numérique x est déclarée comme appartenant au type short. Lors de l'exécution du programme correspondant, sa valeur est un mot de 32 bits dont les 16 bits supérieurs sont une extension de signe.

Conformément au procédé de conversion de types de variables, objet de la présente invention, la variable x peut être déclarée comme appartenant au type de variable redondante red. Or, la variable x précitée participe à une addition dont le résultat est stocké dans la variable y déclarée comme de type entier int . L'opération d' addition est donc une addition sur 32 bits. Pour que la variable x

soit un opérande valide d'une telle addition, il est nécessaire de pouvoir considérer cette variable comme une valeur de 32 bits à part entière. Il faut donc que la variable x puisse être considérée comme admettant le type pseudo-entier p-int.

Pour rendre compte de cet état de fait, la règle ci-après peut alors être adoptée dans le cadre de la mise en #uvre du procédé de conversion de types de variables, objet de la présente invention : - toute valeur de type de variable redondante red admet également le type de variable pseudo-entier p-int. En d'autres termes, le type de variable redondante red est un sous-type du type de variable pseudo-entier p-int.

Une telle règle est cohérente car, lorsqu'on prétend que x est de type de variable pseudo-entier p-int alors qu'en fait x présente le type de variable redondante red, on omet une information concernant le contenu de ses bits de poids fort. L'information restante est moins précise mais toujours correcte.

Il existe en outre une relation similaire entre le type de variable pseudo-entier p-int et le type de variable verrouillée lock. Ainsi : - toute valeur de type pseudo-entier p-int peut a fortiori présenter le type de variable verrouillée lock. Par une telle relation de sous-typage, on interdit l'utilisation des bits de poids fort de cette variable dans un calcul, alors qu'elle était auparavant autorisée. On introduit ainsi une restriction a priori gratuite mais sans danger.

Grâce aux relations de sous-typage précitées, il est alors possible de typer l'exemple précédemment

mentionné dans la description relatif à l'addition de deux entiers dont le type de variable correspond au type court, short, mentionné précédemment dans la description.

En référence à l'exemple précédent précité, l'expression (x+y) est de type de variable pseudo-entier p-int. Cette expression, d'après la règle de sous-typage précédente, présente également le type de variable verrouillée lock. La conversion (short) qui a pour objet de tronquer une valeur entière à 16 bits n'en utilise pas les bits de poids fort. En fournissant un argument de type de variable verrouillée lock, on n'apporte ainsi aucune violation à l'interdiction associée à ce type de variable.

En conséquence, la relation de sous-typage précitée permet d'attribuer un type cohérent à chaque élément du fragment de programme donné dans l'exemple précédent. En outre, l'expression (x+y) a ainsi reçu le type de variable verrouillée lock, lequel peut être traduit en instruction machine JCVM par un seul mot de p = 16 bits. Une telle addition pourra ainsi être traduite par une instruction sadd opérant sur des entités codées sur 16 bits.

Les trois types de variables précités, type de variable redondante red, pseudo-entier p-int et verrouillée lock permettent d'effectuer une distinction fine entre quantités représentables sur un mot et quantités exigeant deux mots.

En outre, il est possible de conserver le type byte représentant les valeurs entières dont les 24 bits de poids fort sont redondants, de façon que toute variable de type de variable byte admette a fortiori comme type de variable le type de variable redondante red.

Enfin, toutes les valeurs manipulées par un programme n'étant pas des valeurs numériques entières, il est opportun d'attribuer un type aux valeurs non numériques, à savoir aux objets et aux tableaux. Dans le but d'introduire une relation d'ordre total dans la relation de sous-typage, il est avantageux, conformément au procédé objet de la présente invention, d'introduire un type T contenant toutes les valeurs, numériques ou non. Ce type de variable est ainsi un supertype de tous les types précédemment introduits et l'on obtient ainsi cinq types de variables vérifiant la relation de sous-typage suivante :

Alors que la conversion de type de variables numériques codées dans un programme informatique est mise en #uvre par exemple instruction par instruction, ainsi que représenté en figure le, puis en définitive pour l'ensemble des instructions constitutives du programme informatique à traduire, un système de traduction d'un programme informatique constitué par une suite d'instructions et manipulant des variables numériques et littérales codées, ces variables numériques étant codées sur 2p = 32 bits, sera maintenant décrit en liaison avec la figure 2 et les figures suivantes.

En référence à la figure 2 précitée, le système de traduction d'un programme informatique objet de la présente invention, comprend au moins un module 1 analyseur du type des variables du programme informatique instruction par instruction. Le module 1 analyseur de type reçoit, à partir du code objet constitutif du programme

informatique à traduire, exécutable par la machine JVM, chaque instruction successivement de l'ensemble des
K-1 instructions, noté Ii Le module 1 analyseur de type i=0 permet, à partir des instructions successives et pour toute instruction courante, d'établir indépendamment un système de contraintes logiques. Le système de contraintes
K-1 logiques ou symboliques est noté Ci . Ainsi, pour chaque i=0 instruction de rang i compris entre 0 et K-l, on obtient un ensemble de contraintes selon la notation précédente.

Le système de contraintes relatif à chaque instruction courante est obtenu en associant à chaque variable du programme informatique et en particulier à chaque variable locale numérique de l'instruction correspondante, une variable de contrainte déterminée.

Ainsi, le système de contraintes logiques associé à chaque instruction courante représente une relation de dépendance entre les différents états successifs de la machine JVM, c'est-à-dire du processeur d'exécution de la succession d'instructions représentative du programme informatique à traduire. Cette relation de dépendance est établie à partir des contraintes reliant les types de variables des variables numériques locales, ces types de variables constituant les variables de contrainte précédemment mentionnés.

En outre, le système de traduction objet de l'invention tel que représenté en figure 2, comprend un module 2 solveur recevant l'ensemble des systèmes de

K-1 1 contraintes logiques Ci , lesquels ont été délivrés par i=0 le module 1 analyseur. Le module 2 solveur permet de calculer une solution optimale SK par attribution d'une valeur selon un type de variables spécifique à chaque variable de contrainte, de façon que l'ensemble des contraintes des différents systèmes de contraintes obtenus pour chaque instruction courante successive soit satisfait. On indique que l'existence d'une solution SK permet d'attribuer à chaque variable numérique du programme informatique le type de variable attribué à la variable de contrainte correspondante.

En outre, un module 3 analyseur de représentation est prévu, lequel reçoit l'information de type de variable attribué à chaque variable numérique du programme informatique par l'intermédiaire de la solution SK, le module 3 analyseur de représentation permettant de déterminer la représentation de chaque variable sous forme de codage sur p = 16 bits ou 2p = 32 bits. Ainsi, à chaque variable numérique locale de chaque instruction, et donc à chaque variable numérique du programme informatique à traduire, est attribué un choix de représentation sur p = 16 ou 2p = 32 bits correspondant.

Enfin, un module 4 émetteur est prévu, lequel reçoit, de même que le module 3 analyseur de représentation, chacune des instructions constitutives du code objet à traduire, exécutable par la machine JVM. Le module 4 émetteur reçoit également le choix de la représentation de chaque variable sous forme de codage sur p = 16 bits ou 2p = 32 bits pour engendrer le programme informatique traduit, constitué par le code objet JCVM

codé sur 2p ou p bits en fonction des choix retenus au niveau de l'analyseur de représentation 3.

Bien entendu, le système de traduction objet de la présente invention tel que représenté en figure 2, utilise, notamment au niveau de l'analyseur de type 1, les types de variables spécifiques permettant la conversion de types selon le procédé objet de la présente invention précédemment décrit en liaison avec la figure le.

Une description plus détaillée des modules constitutifs du dispositif de traduction de programme informatique objet de la présente invention tel que représentés et décrit précédemment en figure 2 sera maintenant donnée en liaison avec les figures 3a, 3b, 3c et 3d.

En ce qui concerne l'analyseur 1 de type, ce module a pour fonction d'engendrer de façon statique, c'est-à-dire en l'absence d'exécution du programme code
K-l objet à traduire, un ensemble de contraintes noté Ci , i=0 lequel, après résolution, permet de déterminer l'état de la machine virtuelle autorisant l'exécution du code objet à traduire en chaque point ou instruction du programme. L'état de la machine virtuelle est déterminé par le nombre et par le type des quantités, numériques ou non, situées sur la pile ou dans l'un des registres de la machine virtuelle, lorsque celle-ci est équipée d'une pile, respectivement de registres.

En raison du fait que le calcul conduit est statique, l'analyse de type constitue en fait une approximation instruction par instruction de la machine virtuelle permettant l'exécution de l'ensemble des

instructions compilées selon le code objet représentatif du programme informatique à traduire. Cette approximation n'est autre qu'une approximation de l'état réel de la machine virtuelle lorsque le programme est exécuté par cette dernière.

Dans le cadre de la mise en #uvre du système objet de la présente invention, on indique que les variables de contrainte dénotent, d'une part, le type de chaque variable locale pour chaque instruction successive et, d'autre part, le type de chaque valeur ou entité située sur la pile.

Ainsi, au niveau du module 1 analyseur de type, on cherche à recouvrer des informations de typage, c'est-àdire de type de variable attribué aux variables numériques correspondantes, concernant un programme exécutable par une machine JVM dans lequel toutes les valeurs manipulées sont codées sur 2p = 32 bits.

Le module 1 analyseur de type n'a donc pas pour fonction de distinguer valeurs de 16 bits et valeurs de 32 bits. Toute valeur de variable occupe 32 bits mais peut présenter un contenu ou une utilisation particuliers dans le cadre de l'utilisation du programme.

Le mode opératoire du module 1 analyseur de type sera maintenant décrit en liaison avec la figure 3a, en référence à un exemple de code objet exécutable par une machine JVM donné ci-après.

Dans l'exemple précité, le code source est réputé exprimé au moyen du langage JavaCard, lequel est, de manière connue en tant que telle, un sous-ensemble du langage JAVA. Dans cet exemple, le code objet est celui correspondant au code source suivant :

static short f (int x) { return (short) (x + 1) }
Le programme informatique ou code objet correspondant est réputé manipuler une variable numérique x dont le type de variable est un entier int de 32 bits .

Le résultat produit par ce code objet est la somme x + 1 exprimée sur p = 16 bits.

L'exécution du programme informatique représenté par le code source précité nécessite une compilation effectuée par un compilateur JAVA, lequel permet de transformer le code source précité en une série d'instructions, le code objet exécutable par la machine JVM, ce code objet étant représenté au tableau T8 introduit en annexe.

Dans le tableau précité, la colonne de gauche
K-1 désigne les instructions successives, notée Ii ces i=0 instructions étant notées de 0 à 4. La colonne de droite correspond à un commentaire désignant l'opération effectuée par l'instruction correspondante.

Dans le code objet représenté au tableau T8 précité, on indique que ce code objet dispose d'une unique variable locale, variable numérique portant le numéro 0 et contenant initialement la valeur de x, et d'une pile de données, laquelle est considérée comme initialement vide, le processeur destiné à exécuter un tel code objet étant réputé équipé d'une pile de manière non limitative.

Le module 1 analyseur de type procède à la recherche et à la restitution des informations des types

de variables manipulées dans chaque instruction courante successive du code objet à traduire.

Ainsi, pour chaque instruction courante successive de rang i, i variant de 0 à 4 inclus, le module 1 analyseur de type de variables a pour objet la détermination du type de la variable sur la pile pour l'instruction de rang i considéré, ce type de variable de pile étant noté par convention #1, ainsi que la détermination du type de la variable locale numérique pour l'instruction de rang i correspondant. Le type de la variable locale est par convention noté [alpha]1.

Afin de déterminer ces informations de type de variables, le module 1 analyseur engendre un ensemble de contraintes symboliques noté pour chaque instruction courante successive Ci.

Chaque ensemble de contraintes de rang i associé à l'instruction courante de même rang fait apparaître non seulement les variables #1 et [alpha]1 précédemment mentionnées, relatives au type de variable de la pile et au type de la variable locale, mais aussi des variables auxiliaires, l'ensemble de ces variables intervenant dans chaque ensemble de contraintes étant par définition appelé variables de contraintes ainsi que mentionné précédemment dans la description.

Par convention, le symboles représente le type de variable d'une pile vide.

La notation #:[alpha] représente le type d'une pile obtenu par l'adjonction d'une donnée de type a, donnée correspondant à l'un des types de variable précédemment mentionné dans la description conformément à la mise en

#uvre du procédé objet de la présente invention, au sommet d'une pile de type #, # désignant le type de la variable de pile immédiatement antérieure à la variable ajoutée de type a précitée.

Chaque ensemble de contraintes est engendré par un processus d'analyse au cours duquel l'état initial puis chaque instruction sont considérés séparément, ainsi qu'il sera illustré ci-après, en relation avec le code objet introduit dans le tableau T8 mentionné précédemment.

Etat initial Dans l'état initial, la pile est vide et la variable locale numérique contient la valeur de l'opérande x, soit une valeur codée selon un type de variable pseudo-entier p-int sur 2p = 32 bits a priori totalement quelconque. Ces deux informations permettent d'écrire l'ensemble de contraintes initiales dénotées Cinit vérifiant la relation : Cinit = {# # #0 p-int # [alpha]0} Etape 0 correspondant à l'instruction Io L'instruction précitée iload~0 ajoute à la pile la valeur actuelle de la variable locale x, cette opération permettant d'écrire l'ensemble de contraintes Co : Co = {#0 : [alpha]0 # #1} {[alpha]0 # [alpha]1} Dans cet ensemble de contraintes, la valeur de la variable locale ne change pas, ce qui est indiqué symboliquement par la relation d'ordre reliant les deux types successifs de cette variable ao et [alpha]1.

Etape 1 correspondant à l'instruction Il L'instruction correspondante iconst~l ajoute à la pile la valeur constante 1. Une telle valeur est représentable sur p/2 =8 bits. Ses 24 bits de poids fort sont redondants et elle admet ainsi le type byte précédemment mentionné dans la description. L'ensemble de contraintes correspondant à l'étape précitée Ci vérifie la relation :

Etape 2 correspondant à l'instruction I2 L'instruction correspondante iadd retire les deux variables situées au-dessus de la pile, c'est-à-dire la valeur de la constante et la valeur de x, et en calcule la somme, puis place à nouveau la valeur de cette somme sur la pile.

Les conditions de contraintes précitées prérequises s'expriment par l'ensemble de contraintes C2 précité :

Dans l'ensemble de contraintes C2 précité, on indique que la pile doit contenir au moins deux valeurs numériques.

Cette contrainte prérequise s'exprime par la relation de la première ligne de l'ensemble de contraintes C2 dans laquelle les variables auxiliaires P et ss'2 représentent le type de chacune des variables de pile précitées. La

variable auxiliaire ss"2 est introduite pour représenter le type de la somme des deux variables numériques de pile précédemment mentionnées.

Les valeurs des variables auxiliaires ss2, ss'2 et ss"2, variables de type, sont reliées par la contrainte exprimée à la ligne 2 de l'ensemble de contraintes C2.

Dans la deuxième ligne de l'ensemble de contraintes C2, les deux premières contraintes liant (32 et ss"2, respectivement ss'2 et P"2, expriment essentiellement le fait que le résultat de la somme des deux opérandes, ou variables de pile, ne peut pas être connu avec plus de précision que chacun des deux opérandes. La troisième contrainte de la deuxième ligne précitée indique que la somme est un entier quelconque, même si par exemple les deux opérandes, la valeur numérique x et la constante 1, sont des entiers représentables sur p = 16 bits.

Lorsque l'addition est effectuée, le résultat de cette addition est à nouveau placé au sommet de la pile, ce qui permet d'écrire la contrainte exprimée par la troisième ligne de l'ensemble de contraintes C2.

Enfin, en raison du fait que la variable locale numérique n'est pas modifiée, la contrainte sur le type de cette variable pour l'opération suivante est représentée par la quatrième ligne de l'ensemble de contraintes C2.

Etape 3 correspondant à l'instruction 13 L'instruction correspondante i2s a pour effet de tronquer la variable entière placée au sommet de la pile. En d'autres termes, cette instruction procède d'abord au retrait de la valeur numérique placée au sommet de la pile. Suite à la troncature de cette variable numérique,

la version tronquée est alors placée au sommet de la pile, cette valeur tronquée étant donc représentée par un entier de 32 bits dont les 16 bits de poids fort sont redondants. Enfin, et en raison de l'absence de modification de la variable locale ou numérique, la contrainte sur le type de la variable locale pour l'opération suivante est définie de la même manière que précédemment.

L'ensemble de contraintes C3 relatif à l'instruction 13 est alors le suivant :

Dans l'ensemble de contraintes précité, chaque ligne correspond aux contraintes exprimées précédemment relativement au retrait de la variable située au sommet de la pile, laquelle doit bien entendu être de nature numérique, puis à la troncature et à la mise en place pour mémorisation dans la pile de cette valeur tronquée selon une valeur codée sur p = 16 bits à la ligne 2, et enfin, à la condition relative à l'absence de changement de la valeur locale numérique à la ligne 3.

Etape 4 correspondant à l'instruction I4 Cette instruction correspond à l'instruction ireturn de l'exemple, laquelle a pour effet d'instancier le résultat du code objet constitutif du programme informatique donné en exemple au tableau T8 à la valeur de l'entier situé au sommet de la pile, cette instruction provoquant l'arrêt de l'exécution du programme informatique précité.

Compte tenu du fait que la déclaration relative au code source du programme correspondant au code objet du tableau

T8 déclare renvoyer un entier de 16 bits, car le résultat déclaré est de type short, confer 1ère ligne du code source précité, la variable numérique entière située au sommet de la pile doit satisfaire l'ensemble de contraintes C4 vérifiant la relation :
C4 = {#4 # #4:red}
On dispose ainsi d'une pluralité d'ensembles de contraintes notés Cinit, Co à C4 sur la figure 3a, délivrés par le module 1 analyseur de type précédemment mentionné dans la description.

Alors que dans l'exemple précédemment cité relatif au code objet introduit dans le tableau T8 la notion de contrainte a été explicitée vis-à-vis d'un exemple relativement simple, le processus de génération des contraintes par le module 1 analyseur de type du système objet de la présente invention, peut être généralisé à des cas plus complexes, en particulier dans le cas de toute instruction courante d'opérations sur une pluralité d'opérandes, limitée, à titre d'exemple non limitatif, à deux opérandes de type a et ss et sur au moins un résultat y de cette opération. Aux opérandes de type a, ss constitutifs des variables de contraintes pour cette instruction courante peut être attribué l'un des types de variables redondante, pseudo-entier ou verrouillée, et à la variable de contrainte formée par le résultat de type y est attribué un type de variable déterminé à partir d'un système de contraintes conditionnelles établi en fonction du type de variables attribué aux opérandes précités.

La notion de contrainte conditionnelle sera maintenant explicitée en liaison avec un exemple relatif à une instruction d'addition.

D'une manière générale, on rappelle que l'opération d'addition fournie par une machine JVM calcule la somme de deux valeurs numériques entières quelconques auxquelles peuvent donc être attribué l'un des types de variable byte, red, p-int ou lock.

Le type de variable qui doit être attribué au résultat de cette opération en fonction des types a et (3 des arguments ou opérandes peut être déterminé conformément au processus et au procédé objet de la présente invention de la manière ci-après. Par convention a, (3 et y désignent le type des opérandes et du résultat de l'opération d'addition respectivement.

Une première relation de contraintes consiste à tenir compte du fait que le type y du résultat ne peut pas être plus précis que la connaissance du type a et ss des opérandes.

Si par exemple le type de variable a ou (3 des opérandes précités correspond à un type pseudo-entier pint, alors, il est nécessaire de forcer le type du résultat y à être supérieur ou égal au type pseudo-entier.

Cette contrainte s'exprime par la relation symbolique : [alpha]# [gamma], ss # [gamma]
La contrainte précédente exprime le fait que si une somme met en jeu au moins un entier quelconque, alors, son résultat n'est pas a priori représentable sur 8 ou 16 bits.

Si à titre d' exemple les opérandes de type a ou 5 désignent des variables numériques de type de variable verrouillée lock, alors, il est nécessaire d'attribuer au résultat y au moins le même type lock. Une telle attribution est nécessaire car attribuer au résultat un type inférieur autoriserait par la suite une utilisation arbitraire des bits de poids fort de ce dernier. Or, les bits de poids fort du résultat dépendent des bits de poids fort des deux arguments ou opérandes, lesquels seraient ainsi indirectement utilisés. Une telle opération irait à l'encontre de l'interdiction inhérente du type de variable, variable verrouillée lock.

Toutefois, les contraintes exprimées entre chaque opérande de résultat ne sont pas suffisantes car les seules contraintes exprimées précédemment autorisent par exemple le cas [alpha]=ss=[gamma]=red dans lequel, à chaque opérande et au résultat de l'opération sur ces opérandes, est attribué le même type de variable red. Or, la somme de deux quantités représentables sur 16 bits n'est pas nécessairement représentable sur un même nombre de bits.

Il est donc nécessaire, lorsqu'à l'un des deux opérandes de type a ou (3 est attribué le type de variable redondant red, de garantir que le type y du résultat est d'un type de variable supérieur ou égal à un pseudo-entier p-int.

Dans ce but, il est possible d'imposer la relation d'ordre p-int # y.

Toutefois, une telle contrainte n'est pas satisfaisante car dans ces conditions, au résultat de type y est toujours attribué au moins le type de variable

p-int. Dans ces conditions, il n'est donc pas possible d'exprimer le fait que la somme de deux octets peut être représentée sur 16 bits.

En fait, la contrainte précitée p-int # y ne doit être activée que lorsqu'à l'un des opérandes au moins, de type a ou ss, est attribué un type de variable supérieur ou égal au type de variable redondante red.

Conformément au processus de traduction objet de la présente invention, il est donc opportun d'introduire un type de contrainte conditionnelle, laquelle ne sera prise en compte que si une autre contrainte particulière est satisfaite.

Les contraintes conditionnelles permettent alors de formuler le type de variable attribué au résultat de l'opération d'addition de la manière ci-après, selon la relation définissant l'ensemble de contraintes, C, ci- après : [alpha] # lock ss # lock a < y ss # y red < y red a?p-int < y red ss?p-int # y
Les contraintes de l'ensemble C de contraintes, [alpha] # lock et 5 :9 lock obligent les types de variables a et ss à représenter un type numérique et non une variable de type tableau ou pointeur T. Enfin, dans l'ensemble de contrainte C, les trois dernières lignes de contrainte remplacent la contrainte p-int # y trop grossière, ainsi

que mentionné précédemment. Parmi ces trois dernières lignes, on observe deux contraintes conditionnelles, lesquelles obligent le résultat à présenter le type de variable y valant au moins le type de variable pseudoentier p-int lorsque l'un des arguments ou opérandes présente un type de variable valant au moins le type de variable redondante red. Le caractère conditionnel de ces contraintes est représenté par le signe ?.

Les contraintes conditionnelles précitées sont strictement plus expressives que les contraintes simples précédemment mentionnées dans la description. En effet, alors qu'une contrainte simple ne permet d'exprimer qu'un flot de données d'un point à un autre du programme, le calcul sur les types de variables qui en résulte s'apparentant à une simple propagation de constante, une contrainte conditionnelle offre une plus grande finesse, puisque ce type de contrainte permet de ne faire apparaître un flot de données que sous une certaine condition. Une contrainte conditionnelle permet ainsi de subordonner l'analyse du flot de données à ses propres résultats et autorise ainsi une forme de calcul sur les types de variables attribués.

Une description plus détaillée du module solveur 2 sera maintenant donnée en liaison avec les figures 3b et 3c.

L'ensemble de contraintes obtenu grâce à la mise en #uvre du module 1 analyseur de type est soumis au module solveur 2, lequel permet de vérifier que l'ensemble des contraintes admet une solution. En outre, le module solveur 2 peut permettre d'en calculer une solution optimale.

En référence à la figure 3b, on indique que le module solveur 2 peut comprendre, pour l'ensemble des instructions constitutives du programme informatique et ,pour un microprocesseur muni d'une pile, un module MG générateur d'une pluralité de séquences de variables de types de variables, une de ces séquences étant notée {t1,t2,...,tn} sur la figure 3d. On note, en particulier, qu'une séquence est engendrée pour chaque variable de contrainte sur la pile. La longueur de chaque séquence est déterminée en fonction du nombre d'éléments présents sur la pile pour l'instruction courante considérée.

En outre, un module d'instanciation MI est prévu, lequel permet d'effectuer l'instanciation de chaque variable de contrainte de la pile par une séquence de variables de type de variables. A titre d'exemple non limitatif, sur la figure 3b, le processus d'instanciation, connu en tant que tel, est représenté par la relation ##{t1,...,tn}, à chaque variable de pile étant attribuées les valeurs de type ti à tn précitées.

Le module solveur 2 comporte également un module MD de décomposition des contraintes portant sur les variables de contrainte sur la pile en contraintes portant sur les variables de type de variables constituant chaque séquence par lesquelles les variables de contrainte sur la pile ont été instanciées. En référence à la figure 3b
K-l précitée, pour un ensemble de contraintes Ci i=0 conformément à la notation précédente, le module de décomposition MD permet de transformer l'ensemble de systèmes de contraintes précité portant sur les variables de contrainte sur la pile en contraintes portant sur les

variables de type de variables constituant chaque séquence de variables de type de variables précitée. Sur la figure 3b, cette opération est notée :

On dispose en fait, suite à l'opération réalisée par le module de discrimination MD, d'un nouvel ensemble de contraintes dans lequel les types de variables de pile ont été supprimés.

En outre, le module solveur 2 comprend un module de calcul MCG d'un graphe orienté comportant un ensemble de n#uds formé par les types de variables spécifiques et par les variables de contraintes. Les n#uds du graphe orienté sont reliés par des arcs orientés, chaque arc orienté étant défini par une contrainte entre un n#ud amont et un n#ud aval, chaque n#ud du graphe, noté s0 à sN- 1 correspondant à un type de variable spécifique ou à une variable de contrainte respectivement. A titre d'exemple, la contrainte relative à l' arc s0, Si est notée C01 compte tenu de l'orientation de l'arc correspondant sur la figure 3b.

Le parcours du graphe selon un processus de type classique, lequel, pour cette raison, ne sera pas décrit dans la description, ce mode de parcours pouvant être réalisé de manière logicielle, permet de déterminer la valeur de la borne inférieure notée Bsginf et la valeur de la borne supérieure notée Bsgsup attribuée à chaque variable de contrainte par parcours du graphe orienté

précité. Dans la notation précédente, sg désigne un n#ud ou sommet du graphe orienté avec g variant de 0 à N-l.

Enfin, un module MV de vérification de la relation d'ordre entre borne inférieure et borne supérieure du type de variable susceptible d'être attribué à chaque variable de contrainte est prévu, cette vérification s'entendant au sens de la vérification de la relation d'ordre total de sous-typage, cette relation s'écrivant de ce fait :

Ainsi, l'ensemble des contraintes d'origine admet une solution lorsque la relation d'ordre entre borne inférieure et borne supérieure est vérifiée pour l'ensemble des sommets ou n#uds du graphe établi par le module MCG. L'ensemble des contraintes n'admet aucune solution sinon.

Un exemple spécifique de mode opératoire du module solveur 2 dans le cas d'un programme informatique code objet à traduire tel que représenté au tableau T8 précité sera maintenant donné en liaison avec la figure 3c.

A partir de l'ensemble des contraintes précédentes, Cinit, Co, Ci, C2, C3 et C4 tel que représenté en figure 3c, le module solveur 1 procède à l'élimination de toutes les variables représentant le type d'une pile, de façon à se ramener à un ensemble de contraintes dans lequel ne figurent que des variables représentant le type d'une variable déterminée. Cette opération peut être réalisée à partir du calcul de la hauteur de chaque variable de pile.

Dans l'exemple du code objet du tableau T8, le module solveur 2 constate nécessairement que : #0 ainsi que les variables auxiliaires #2, #3 et #4 représentent une pile vide ; #1, 3 et #4 représentent une pile à une variable sur la pile ; # #2 représente une pile comportant deux variables sur la pile.

En conséquence, le module solveur 2 procède au remplacement de : # #0, #2, #3 et #4 par # ; # #1, 3 et #4 par #:[gamma]11, #:[gamma]31, et #:[gamma]41 respectivement ; 3 #2 par #:[gamma]21:[gamma]22.

Dans les relations précédentes, [gamma]11, [gamma]31, [gamma]41, Y21 et [gamma]22 sont de nouvelles variables auxiliaires.

Lorsque ce remplacement a été effectué, ce remplacement correspondant à l'opération d'instanciation précédemment mentionné dans la description, le module solveur 2 peut alors procéder à la simplification des contraintes par l'intermédiaire du module MD. Cette opération permet de faire disparaître tous les types de pile et l'on obtient, après réduction, les contraintes suivantes :

L'ensemble des contraintes mentionnées précédemment correspond à l'ensemble des contraintes notées :

Le module solveur 2 procède alors au calcul de la solution des contraintes grâce au module de calcul des graphes MCG et au module de vérification MV précédemment mentionnés. Cette solution, si elle existe, doit minimiser le nombre de variables qui reçoivent le type de variable pseudo-entier p-int.

Dans l'exemple précédemment mentionné de code objet introduit au tableau T8, cette solution peut correspondre aux attributions de type de variable ci-après selon la relation :

Dans la solution mentionnée précédemment, on peut constater qu'il existe une solution des contraintes SK qui n'attribue le type de valeur pseudo-entier p-int à aucune des variables.

Une description plus détaillée du module 3 analyseur de représentation, sera maintenant donnée en liaison avec les figures 3d et 3e.

En référence à la figure 3d, on indique que le module 3 analyseur de représentation permet de choisir,

pour chaque variable locale numérique manipulée par chaque instruction courante du code objet à traduire, le mode de représentation et de codage de cette variable numérique sur p = 16 bits ou 2p = 32 bits dans le programme informatique traduit. Le module 3 analyseur de représentation permet donc d'effectuer un ensemble de choix, ces choix devant nécessairement être corrélés afin de produire un code objet traduit de bonne qualité.

Dans ce but, ainsi que représenté en figure 3d, le module 3 analyseur de représentation peut comprendre un module, noté MD1, de discrimination d'un premier groupe de variables de contrainte auxquelles le type de variable pseudo-entier p-int a été attribué, à ce premier groupe de variables de contrainte étant attribué un codage sur 2p bits, et d'un deuxième groupe de variables de contrainte de type redondant ou verrouillée red respectivement lock, sous-ensemble de l'ensemble des variables de contrainte à l'exclusion du premier groupe des variables de contrainte.

En outre, un module MD2 de discrimination du type de codage sur p bits ou 2p bits, type de codage attribué aux variables de contraintes du deuxième groupe, est prévu.

D'une manière générale, on indique que le module MD1 de discrimination du premier groupe de variables et du deuxième groupe de variables peut être constitué par un module logiciel de tri de types de variables du premier groupe auxquelles est nécessairement attribué le type de variable pseudo-entier p-int, l'ensemble des autres variables auxquelles ce type de variable n'a pas été attribué constituant nécessairement les variables du deuxième groupe.

De même, le module MD2 de discrimination du type de codage sur p bits ou 2p bits peut comprendre un module logiciel d'émission d'un ensemble d'équations symboliques portant sur les variables logiques de représentation. Ces équations sont établies à partir de l'analyse du programme informatique instruction par instruction. Ainsi, l'analyse de l'instruction courante donne lieu à zéro, une ou plusieurs équations symboliques reliant les variables logiques de représentation associées aux opérandes et aux résultats de l'instruction courante. En outre, un module logiciel de résolution de ces équations symboliques est prévu, lequel permet d'attribuer à chaque variable logique de représentation et à chaque variable de contrainte du deuxième groupe un choix de codage sur p ou 2p bits.

Le mode opératoire du module de discrimination du type de codage MD2 sera maintenant décrit en référence à l'exemple de code objet introduit au tableau T8 précité en liaison avec la figure 3e.

Selon un mode de réalisation avantageux du module de discrimination de type MD2, le choix du code de représentation, p = 16 bits ou 2p = 32 bits, est représenté par une variable de représentation pouvant prendre arbitrairement la valeur simple ou double. Les corrélations souhaitées entre les choix sont alors exprimées à l'aide d'équations entre ces variables. Ces variables et ces équations sont similaires aux variables et aux contraintes manipulées par le module 1 analyseur de type.

Par souci d'homogénéité avec la description précédente, des notations similaires sont utilisées, la représentation de la pile pour l'instruction courante de

rang i est notée #i et la représentation de la variable locale est notée a. On rappelle que la représentation d'une variable locale ne peut dépendre du rang i de l'instruction courante car cette représentation ne doit aucunement changer au cours du temps, c'est-à-dire au cours du passage d'une instruction courante à l'instruction suivante, pour assurer l'homogénéité de représentation de toutes les variables dans l'ensemble du code objet.

Dans le cas du code objet introduit au tableau T8 précité, aucune variable numérique ne s'est vue, dans cet exemple non limitatif, attribuer le type de variable pseudo-entière p-int. En conséquence, dans l'exemple précité, il est possible de représenter et de coder chaque variable numérique sur p = 16 ou 2p = 32 bits.

D'une manière générale, dans le cas où l'analyse de type indique qu'une certaine variable locale s'est vue attribuer le type de variable pseudo-entière p-int, alors, il est possible d'engendrer une relation symbolique forçant sa représentation à être double.

Les étapes successives de mode opératoire du module 3 analyseur de représentation seront décrites en liaison aux instructions Iinit, Io à I4 et à l' ensemble des contraintes Cinit, Co, Ci, C2, C3 et C4 précédemment mentionnées dans la description et représentées sur la figure 3e.

Etape initiale correspondant à l'état initial Dans l'état initial, la pile est vide et la variable locale contient la valeur de x. Une variable numérique de type de variable pseudo-entier p-int occupe toujours deux mots conformément à la convention d'appel des variables de

la machine JCVM. A l'étape initiale précitée, il est donc possible d'écrire la contrainte de représentation initiale CRinit : CRmit = {#=#0 doublera} Etape 0 correspondant à l'instruction Io L'instruction correspondante, iload~0, ajoute à la pile la valeur actuelle de la variable locale. Il n'est pas nécessaire que la représentation de la valeur ajoutée à la pile coïncide avec la représentation de la variable locale. Si celle-ci diffère, il suffit le cas échéant, d'ajouter une instruction de conversion i2s ou s2i. Dans ces conditions, la représentation de la variable numérique ajoutée à la pile est représentée ici par une nouvelle variable ss0 sur laquelle ne porte pour l'instant aucune contrainte. Ceci permet d'écrire la contrainte de représentation CRo :

Etape 1 correspondant à l'instruction Il L'instruction correspondante iconst~l ajoute à la pile la valeur de constante 1. Il est possible de produire celleci sous forme d'un ou deux mots. Par conséquent, aucune contrainte sur la représentation de cette constante n'est en réalité nécessaire. La contrainte globale de représentation CR1 pour l'étape 1 s'écrit:

Etape 2 correspondant à l'instruction I2 L'instruction correspondante iadd retire les deux éléments situés au-dessus de la pile, calcule la somme de ces

derniers et place à nouveau le résultat de cette somme sur la pile. Afin de faciliter le processus de traduction, il est possible d'imposer que les deux opérandes ainsi que le résultat aient la même représentation. La contrainte de représentation de l'étape 2 CR2 s'écrit :

Etape 3 correspondant à l'instruction 13 L'instruction correspondante i2s se traduit facilement quelles que soient les représentations de l'argument de cette instruction et du résultat de cette dernière. En conséquence, la contrainte de représentation CR3 s'écrit :

Etape 4 correspondant à l'instruction I4 Dans ce cas, pour l'instruction ireturn, la représentation de l'argument, c'est-à-dire de la variable numérique de retour, n'est pas spécifiée. La contrainte de représentation CR4 s'écrit alors : CR4 = {#4 = #4:ss4}
La résolution d'un tel système d'équations est un processus classique et il n'est pas nécessaire de mettre en #uvre un solveur dédié, les module logiciel d'émission et module logiciel de résolution constitutifs du module MD2 de discrimination de type n'étant pour cette raison pas décrits en détail.

Dans l'exemple du code objet correspondant au tableau T8 tel que représenté en figure 3e, le choix, c'est-à-dire la solution obtenue pour la représentation des variables précitées, s'écrit :

En référence à la solution mentionnée précédemment, la seule variable numérique qui doit être représentée sur 2p bits et à laquelle la représentation attribuée est la valeur double est la variable a. Pour les autres variables, il est possible ainsi de choisir la solution la plus économique, notamment en espace mémoire consommé, qui consiste à leur attribuer la valeur simple de codage sur p = 16 bits.

Une description plus détaillée du module 4 émetteur du programme informatique ou code objet traduit sera maintenant donnée en liaison avec la figure 3f.

Le module émetteur 4 permet en fait, à partir de chaque instruction successive Ii d'engendrer le code objet, en particulier pour la représentation de la machine JCVM ainsi que mentionné dans la description.

Une description du mode opératoire du module 4 émetteur sera donnée en référence à la traduction du code objet introduit au tableau T8 précité et de la figure 3f.

En référence au mode de représentation obtenu et décrit en liaison avec les figures 3d et 3e pour l'exemple précité, à la seule variable a étant attribuée la variable de représentation double, toutes les autres variables numériques manipulées étant représentées et codées sur p = 16 bits, il en découle la série d'instructions JCVM introduite au tableau T9 en annexe.

Il est alors possible de comparer les codes objet exécutables par la machine JVM, respectivement par la

machine JCVM, ces codes objet étant introduits aux tableaux T8 et T9 précités.

On remarque en particulier que l'instruction JVM iload~0, c'est-à-dire l'instruction Io, est traduite par la série de deux instructions JCVM, iload~0;i2s. En effet, la variable locale occupant deux mots, a = double, il est nécessaire d'utiliser l'instruction iload 0 pour en lire le contenu. Ce faisant, on ajoute deux mots à la pile.

Toutefois, les choix effectués dans la phase précédente exigent que la valeur ajoutée à la pile soit stockée sur p = 16 bits. L'instruction de chargement iload~0 du code objet JCVM doit donc être suivie de l'instruction i2s, laquelle élimine les p = 16 bits de poids fort superflus.

On remarque en outre que l'instruction JVM i2s n'est pas traduite. En effet, d'après les choix retenus précédemment en liaison avec la figure 3e, l'argument d'une telle instruction est déjà stocké sur p = 16 bits. Il n'est donc nécessaire d'effectuer aucune troncature. Les exemples précités montrent ainsi que le nombre d'instructions du programme traduit peut être inférieur ou supérieur au nombre d'instructions du programme original.

A titre d'exemple non limitatif, une comparaison entre le code objet traduit représentatif de la machine JCVM introduit au tableau T9 avec un pseudo-programme traduit grâce à la mise en #uvre d'un traducteur naïf selon l'hypothèse précédemment mentionnée dans la description selon laquelle toute quantité entière occupe 2p = 32 bits et produisant un code objet introduit au tableau T10 en annexe, permet d'effectuer les remarques ci-après.

Alors que le programme représenté par le tableau T10 est correct, on peut toutefois remarquer qu'il nécessite une pile suffisamment grande pour obtenir quatre entités codées sur p = 16 bits, tandis que le programme informatique traduit conformément à la mise en #uvre du système de traduction objet de la présente invention et tel que représenté au tableau T9 n'en exige que deux. La consommation de mémoire est donc nettement inférieure dans le cas de la mise en #uvre du système de traduction objet de la présente invention.

On a ainsi décrit un procédé de conversion de types de variables codées dans un programme informatique et un système de traduction de programme informatique correspondant particulièrement performants en raison des nombreux avantages remarquables que ces derniers présentent vis-à-vis de l'état de la technique.

Parmi ces avantages, on peut citer le caractère de correction du processus de traduction, lequel sera décrit et défini ci-après.

L'analyse des types engendre une description de l'ensemble des comportements du programme d'origine, sous la forme d'un système de contraintes de sous-typage dont le module solveur calcule une solution particulière. La correction de ces deux composants garantit que cette solution donne une vision correcte du fonctionnement du programme. En d'autres termes, si cette solution déclare qu'une certaine entité peut être représentée à l'aide d'un seul mot, alors cela est vrai : le programme traduit d'après cette indication aura nécessairement un comportement identique à celui du programme d'origine.

On notera en outre que cette propriété de correction dépend uniquement de la première phase identifiée précédemment, c'est-à-dire de la détermination de l'espace des traductions autorisées. Les phases du processus de traduction suivantes n'interviennent pas dans la preuve de cette propriété, à condition bien entendu que le code produit par ces dernières corresponde bien à un point de cet espace. Le caractère de modularité de la preuve de correction engendre ainsi une fiabilité accrue.

Une autre caractéristique essentielle du processus de traduction, objet de l'invention, concerne le caractère de complétude du module de traduction. Les contraintes produites par la détermination des types admettent nécessairement une solution pourvu que le programme d'origine analysé soit correct et déterministe au sens de la spécification de la machine virtuelle JVM, et pourvu qu'il respecte les restrictions supplémentaires imposées par la spécification du langage' JavaCard. Ces deux conditions sont vérifiées en particulier par tout programme JavaCard correct compilé à l'aide d'un compilateur Java correct. Le procédé et le système de traduction objets de la présente invention sont donc à même de traiter n'importe quel programme JavaCard. Cette propriété est particulièrement remarquable car si certains programmes étaient rejetés, leur auteur n'aurait pas nécessairement le souhait ou la possibilité de les modifier pour les rendre acceptables par le module de traduction.

Le procédé de conversion de variables et de traduction et les systèmes correspondants, objets de la

présente invention, permettent également de réaliser une économie de moyens.

Si le programme d'origine à traduire n'utilise aucunement le type entier int fourni par le langage Java, et si le résultat de chaque calcul arithmétique est tronqué au type short avant d'être utilisé, alors le programme sera traduit sans utiliser les instructions arithmétiques sur 2p = 32 bits offertes par certaines machines JCVM. Il peut en conséquence être exécuté par n'importe quelle carte à puce JavaCard. Cette propriété est importante car elle permet d'indiquer au programmeur d'applications un sous-ensemble précis du langage JavaCard auquel le fait de se restreindre garantit la portabilité universelle de l'application. Ainsi, bien que le processus et le système de traduction, objets de la présente invention, utilisent parfois plus d'instructions 2p = 32 bits qu'il n'est strictement nécessaire, cette latitude n'est utilisée que dans des cas où l'usage de ces instructions est de toute façon inévitable. Le processus de traduction mis en #uvre allie ainsi flexibilité et économie de moyens.

Un autre avantage majeur du procédé de conversion de types de variables et de traduction d'un programme informatique et des systèmes correspondants, objets de la présente invention, réside dans le choix du codage sur p = 16 bits ou 2p = 32 bits des entités ou opérandes constitutifs des valeurs numériques appelées par les instructions. Les choix précités ne sont pas indépendants les uns des autres. En effet, s'il existe un flot de données entre deux quantités et si le choix effectué pour celles-ci n'est pas le même, alors le code traduit devra

contenir une ou plusieurs instructions de conversion.

Lorsque cette séquence d'instructions est trop longue, la qualité du code produit est compromise. Il est ainsi essentiel, dans un tel cas, d'interdire la conversion en introduisant une corrélation entre les deux choix, c'est- à-dire en exigeant que le choix effectué pour les deux quantités soit le même.

Ainsi, pour corréler de manière intelligente la multitude de choix à effectuer, le procédé et le système de traduction d'un programme informatique objets de la présente invention proposent d'effectuer une nouvelle analyse à base de contraintes appelée analyse de représentation. Cette fois cependant, l'existence d'un possible flot de données donne lieu, non à une contrainte de sous-typage, mais à une contrainte d'égalité entre choix, dans le cas où une conversion serait difficile.

Typiquement, une conversion est difficile lorsque la quantité à convertir est située à une profondeur non nulle dans la pile de la machine virtuelle. Une conversion est au contraire typiquement facile lorsque la quantité à convertir est située au sommet de la pile.

L'avantage du processus d'analyse de représentation est ainsi double : d'une part, la qualité du code est garantie puisque les choix sont a présent corrélés de façon à interdire toute conversion malaisée, et, d'autre part, la phase du processus de traduction consistant en l'émission de code est sensiblement simplifiée puisque le nombre de cas de figures devant être traité par celle-ci est ainsi réduit. La fiabilité de cette dernière est ainsi accrue.

ANNEXES TABLEAU Tl public class Hybrid { short mTransactionCounter; int mAccountBalance ; public void Transaction (int inCredit) mTransactionCounter++ ; mAccountBalance +=inCredit; TABLEAU T2 public class Tricky{ public static void blitVector (short[]vector,short ofs, short size) for (short index = ofs ; < ofs + size ; vector [index] 0; } }

TABLEAU T3 for (short index = ofs; index < (short) (ofs + size); index++) vector[index] = 0; TABLEAU T4 getfield #5 getfield #5 s2i iconst~l iconst~l iadd iadd i2s i2s s2i putfield #5 i2s putfield~s #5 TABLEAU T5 aload~0 aload~0 iload~3 iload 7 iconst~0 iconst~0 sastore swap~x 2,2 i2s swap~x 1,2 i2s sastore

TABLEAU T6 aload~0 dup getfield #5 getfield~s~this #5 iconst~l sconst~l iadd sadd i2s putfield #5 putfield~s~this #5 aload~0 dup getfield #4 getfield~i~this #4 iload~l iload 1 iadd iadd putfield #4 putfield~s~this #4 return return TABLEAU T7 iload ~1 sload~l istore~3 sstore~3 goto M goto M
L : aload~0 aload~0 iload sload~3 iconst 0 sconst~0 sastore sastore iload sinc 3 1 iconst~l iadd i2s istore~3
M: iload sload~3 s2i iload~1 sload~l s2i iload~2 sload~2 s2i iadd iadd if icmplt L icmp iflt L return return

TABLEAU T8
0 : iload~0 ; charge la valeur de x sur la pile
1: iconst~l ; charge la constante 1 sur la pile
2 : iadd ; calcule leur somme
3: i2s ; tronque celle-ci à 16 bits
4 : ireturn ; renvoie cette valeur.

TABLEAU T9
0 : iload~0 ; charge la valeur de x, sous forme de deux mots i2s ; la réduit à un mot
1: sconst~l ; charge la constante 1, sous forme d'un mot
2 : sadd ; calcule leur somme, sous forme d'un mot
3: ; (aucune troncature n'est nécessaire)
4 : sreturn ; renvoie cette valeur.

TABLEAU T10
0 : iload~0 ; charge la valeur de x, sous forme de deux mots
1: iconst~1 ; charge la constante 1, sous forme de deux mots
2 : iadd ; calcule leur somme, sous forme de deux mots
3: i2s ; effectue la troncature àun mot
4 : sreturn ; renvoie cette valeur.

Claims

REVENDICATIONS

1. Procédé de conversion de type de variables numériques ou littérales codées dans un programme informatique dans lequel les variables numériques sont codées sur 2p bits, conversion par entités de 2p bits respectivement p bits pour un processeur destiné à exécuter ce programme informatique, caractérisé en ce que ce procédé consiste à associer à ces variables numériques un type de variables spécifique comportant au moins : - un type de variable redondante (red), codée sur 2p bits, dont les p bits de poids fort ont une valeur redondante vis-à-vis des bits de poids faible ; - un type de variable verrouillée (lock) codée sur 2p bits dont les p bits de poids fort ont une valeur déterminée non pertinente pour le programme informatique, - un type de variable pseudo-entier (p-int), codée sur 2p bits, toute variable numérique de type pseudo-entier (p-int) étant quelconque, tant du point de vue de sa valeur numérique que de son utilisation par le programme informatique traduit ; ce qui permet d'adapter le type de variable et le nombre de bits affectés auxdites variables numériques pour un processeur destiné à exécuter ledit programme informatique, par suppression des bits de poids fort desdites variables auxquelles est affecté un type de variable spécifique de type de variable redondante ou verrouillée.

2. Procédé selon la revendication 1, caractérisé en ce que lesdits types de variables spécifiques sont

agencés selon une relation d'ordre de sous-typage selon laquelle : - toute variable de type de variable redondante (red) admet a fortiori comme type de variable le type de variable pseudo-entier (p-int) ; - toute variable de type de variable pseudo-entier (p-int) admet a fortiori comme type de variable le type de variable verrouillée (lock), ce qui permet, à partir de contraintes symboliques établies sur le type de variables numériques, vis-à-vis de cette relation d'ordre, de discriminer lesdites variables numériques entre entités représentables sur p bits et entités représentables sur 2p bits.

3. Système de traduction d'un programme informatique constitué par une suite d'instructions et contenant des variables numériques et littérales codées et dans lequel les variables numériques sont codées sur 2p bits, traduction par conversion de type de variables par entités de 2p bits respectivement p bits pour un processeur destiné à exécuter ce programme informatique, caractérisé en ce qu'il comporte au moins : - des moyens de mémorisation, sous forme de mémoire de pile respectivement de registres, de l'état de la machine virtuelle autorisant l'exécution du code objet à traduire en chaque point ou instruction du programme, ledit état étant déterminé par le nombre et par le type des quantités situées sur la mémoire de pile respectivement dans l'un de ces registres ; - des moyens analyseurs du type des variables dudit programme informatique instruction par instruction, lesdits moyens analyseurs permettant d'établir

indépendamment, pour chaque instruction successive courante, un système de contraintes logiques, à chaque variable dudit programme informatique étant associé pour chaque instruction courante une variable de contrainte, ledit système de contraintes logiques associé à chaque instruction courante représentant une relation de dépendance entre les différents états successifs du processeur d'exécution de cette suite d'instructions, cette relation de dépendance étant établie à partir des contraintes reliant les types de variables spécifiques des variables numériques ; - des moyens solveurs recevant l'ensemble des systèmes de contraintes logiques délivré par lesdits moyens analyseurs et permettant de calculer une solution par attribution d'une valeur selon un type de variables spécifique à chaque variable de contrainte, de façon que l'ensemble des contraintes des systèmes de contraintes soit satisfait, l'existence d'une solution permettant d'attribuer à chaque variable numérique du programme informatique le type de variable attribué à la variable de contrainte correspondante ; des moyens analyseurs de représentation recevant l'information de type de variable attribué à chaque variable numérique du programme informatique et permettant de déterminer la représentation de chaque variable sous forme de codage sur p bits, ou 2p bits, à chaque variable numérique étant attribué un choix de représentation sur p ou sur 2p bits ; des moyens émetteurs permettant d'engendrer, à partir dudit programme informatique analysé instruction par instruction, de la représentation de chaque variable

sous forme de codage sur p bits, ou 2p bits, un programme informatique traduit.

4. Système selon la revendication 3, caractérisé en ce que le type de variables spécifique comporte au moins : - un type de variable redondante (red), codée sur 2p bits, dont les p bits de poids fort ont une valeur redondante vis-à-vis des bits de poids faible ; - un type de variable verrouillée (lock), codée sur 2p bits, dont les p bits de poids fort ont une valeur déterminée non pertinente pour le programme informatique, - un type de variable pseudo-entier (p-int), codée sur 2p bits, toute variable numérique de type pseudo-entier (p-int) étant quelconque, tant du point de vue de sa valeur numérique que de son utilisation par le programme informatique traduit ; ledit type de variables spécifique permettant d'adapter le type de variable et le nombre de bits affectés auxdites variables pour un processeur destiné à exécuter ledit programme informatique, par suppression des bits de poids fort desdites variables auxquelles est affecté un type de variable spécifique de type de variable redondante ou verrouillée.

5. Système selon la revendication 3, caractérisé en ce que pour toute instruction courante d'opération sur au moins un opérande de type de variable a, et sur au moins un résultat de type de variable y de cette opération, à l'opérande de type de variable a étant attribué l'un des types de variables redondante, pseudo-

entier ou verrouillée, à ladite variable de contrainte formée par ledit au moins un résultat de type de variable y est attribué un type de variable déterminé à partir d'un système de contraintes conditionnelles établies en fonction du type de variable attribué audit opérande.

6. Système selon la revendication 3, caractérisé en ce que lesdits moyens solveurs comportent au moins pour l'ensemble des instructions constitutives dudit programme informatique et pour un microprocesseur muni d'une pile : - des moyens générateurs, pour chaque variable de contrainte sur la pile, d'une séquence de variables de type de variables, ladite séquence étant déterminée en fonction du nombre d'éléments sur la pile pour l'instruction courante du programme auquel ladite variable de contrainte sur la pile est associée ; - des moyens d'instanciation de chaque variable de contrainte sur la pile par ladite séquence de variables de types de variables ; - des moyens de décomposition des contraintes portant sur les variables de contrainte sur la pile en contraintes portant sur les variables de type de variables constituant chaque séquence par lesquelles lesdites variables de contrainte sur la pile ont été instanciées ; - des moyens de calcul d'un graphe orienté comportant un ensemble de n#uds formés par lesdits types de variables spécifiques et par lesdites variables de contrainte, lesdits n#uds étant reliés par des arcs orientés, chaque arc orienté étant défini par une contrainte entre un n#ud amont et un n#ud aval, selon le sens d'orientation de l'arc considéré ;

des moyens de calcul de la borne inférieure et de la borne supérieure du type de variable susceptible d'être attribué à chaque variable de contrainte, par parcours du graphe orienté ; des moyens de vérification de la relation d'ordre entre borne inférieure et borne supérieure du type de variable susceptible d'être attribué à chaque variable de contrainte, au sens de la relation d'ordre total de sous-typage, l'ensemble des contraintes admettant une solution lorsque ladite relation d'ordre entre borne inférieure et borne supérieure est vérifiée et n'admettant pas de solution sinon.

7. Système selon la revendication 3, caractérisé en ce que lesdits moyens analyseurs de représentation comprennent au moins, à partir du type de variables spécifique attribué à chaque variable de contrainte : - des moyens de discrimination d'un premier groupe de variables de contrainte auxquelles le type de variable pseudo-entier (p-int) a été attribué, à ce premier groupe de variables de contrainte étant attribué un codage sur 2p bits et d'un deuxième groupe de variables de contrainte, de type redondante ou verrouillée, sous- ensemble de l'ensemble des variables de contrainte à l'exclusion du premier groupe de variables de contrainte ; des moyens de discrimination du type de codage sur p bits, ou 2p bits, attribué aux variables de contrainte dudit deuxième groupe.

8. Système selon la revendication 7, caractérisé en ce que lesdits moyens de discrimination du type de

2p bits en fonction de cette valeur.

codage p bits, ou 2p bits, attribué aux variables de contrainte dudit deuxième groupe comprennent : - des moyens de calcul pour chaque variable de contrainte d'une variable logique de représentation, - des moyens d'attribution à chaque groupe de variables de contrainte présentant une variable logique de représentation de même valeur, un codage sur p bits ou

9. Système selon la revendication 8, caractérisé en ce que lesdits moyens d'attribution comportent : - des moyens d'émission d'un ensemble d'équations symboliques portant sur lesdites variables logiques de représentation, lesdites équations symboliques étant établies à partir de l'analyse du programme informatique instruction par instruction, l'analyse de l'instruction courante donnant lieu à zéro, une ou plusieurs équations symboliques reliant les variables logiques de représentation associées aux opérandes d'une part, et aux résultats, d'autre part, de l'instruction courante ; - des moyens de résolution desdites équations symboliques permettant d'attribuer à chaque variable logique de représentation et à chaque variable de contrainte du deuxième groupe un choix de codage sur p ou 2p bits.