FR 2947648 A1 20110107 FR 0954549 A 20090702 Dispositif de compilation, procédé de compilation et compilateur La présente invention concerne le domaine des compilateurs, par exemple pour la programmation de cartes à puce. Dans tout le texte qui va suivre, la terminologie suivante sera utilisée. Une entité est une information enregistrée dans une zone de mémoire à laquelle il peut être fait référence depuis un programme. Une entité peut être notamment une donnée utilisée par le programme (telle qu'un nombre, une chaîne de caractères, un tableau, etc.) sous la forme d'un champ d'un objet, ou un fragment de code exécutable sous la forme d'une méthode d'une classe, ou une description de structures sous la forme d'une classe. Un appel à une entité est un accès au contenu de cette entité, par exemple l'exécution du code d'une méthode, ou la lecture ou la modification d'une donnée. Une référence directe à une entité est une donnée dans laquelle est enregistrée une adresse de l'entité. Ainsi, en suivant une référence directe, on arrive directement au code de l'entité. Une référence indirecte à une entité est une donnée dans laquelle est enregistrée une adresse d'une autre référence à l'entité, cette autre référence pouvant être directe ou bien indirecte. Le document � Developing a Java Card Applet � (Sun Microsystems, Inc., 2001) décrit un procédé de préparation d'appliquettes Java Card en deux étapes : la première étape, dite compilation, consiste à transformer un code source écrit en langage Java Card, et compris dans un fichier source Java (� *.java �), en un code compilé, compris dans un fichier d'appliquette convertie appelé fichier CAP (� *.cap �) ; la seconde étape, dite chargement, est réalisée par un � chargeur � et consiste à adapter le code compilé pour l'adapter à la carte à puce. Cette seconde étape est en général effectuée lorsque ledit code compilé est inscrit sur la carte à puce. En fait, le compilateur comprend deux modules : un compilateur stricto sensu compilant le fichier source Java en un fichier bytecode Java (� *.class �) et un convertisseur convertissant le fichier bytecode Java en un fichier CAP. Le code source dans le fichier source Java comprend généralement une ou plusieurs classes, chacune comprenant des données, appelées � champs �, et/ou des méthodes. Les méthodes d'une classe peuvent comprendre des appels à d'autres entités (ou même à elle-même). Dans le code source, un appel d'entité comprend le nom de l'entité que l'on souhaite appeler, suivi, le cas échéant pour une méthode, des paramètres à lui passer indiqués entre parenthèses. Par exemple, la ligne de code source � toto() � est un appel de méthode à la méthode � toto � avec aucun paramètre. Par ailleurs, il est possible de définir dans une classe des propriétés ou des méthodes � privées �, c'est-à-dire auxquelles on ne peut pas accéder depuis l'extérieur de la classe. Lorsque le compilateur Java Card rencontre un appel dans le code source, il est prévu qu'il inscrive une référence, directe ou indirecte, vers l'entité appelée dans un ligne d'une table, appelée table de constantes, également incluse dans le fichier CAP, et qu'il remplace l'appel du code source par une référence indirecte dans le code compilé via la table de constantes, cette référence indirecte prenant ainsi la forme du numéro de ladite ligne de la table de constantes. Il est également prévu que le compilateur inscrive l'adresse de ladite référence indirecte dans le code compilé dans une liste, appelée liste d'emplacements de référence, elle aussi incluse dans le fichier CAP. Lorsque le fichier CAP est chargé dans une mémoire d'une carte Java Card, toutes les références indirectes du code compilé, qui ont la forme d'un numéro de ligne dans la table de constantes, sont remplacées par la référence contenue à cette ligne dans la table de constantes. Le procédé de préparation précédent présente l'inconvénient qu'il n'est pas possible d'accéder à une propriété ou méthode définie dans un premier fichier CAP depuis un second fichier CAP si ladite propriété ou méthode n'est pas déclarée comme exportée dans le premier fichier CAP, car l'adresse de ladite propriété ou méthode est inaccessible au second fichier CAP. En outre, il présente également l'inconvénient qu'il n'est pas possible de prévoir un appel pour une propriété ou une méthode que l'on souhaite compiler ultérieurement, car toute référence nécessite une entrée dans la table des constantes qui ne contient que des références à des entités existantes. Ainsi, un but de l'invention est de donner une plus grande liberté de programmation. A cet effet, un objet de l'invention est un dispositif de compilation destiné à compiler un code source en un code compilé, le code source comprenant au moins un appel à une entité, le dispositif étant caractérisé en ce qu'il comprend : - des moyens de détection destinés à détecter si l'appel est un appel dit de premier type ou bien un appel dit de second type, - des moyens d'écriture dans une table destinés, en cas de détection d'un appel de premier type, à écrire, à une adresse de la table, une référence à un code compilé de l'entité - des premiers moyens de remplacement destinés, en cas de détection d'un appel de premier type, à remplacer l'appel du code source en une référence, dite de premier type, dans le code compilé, la référence de premier type ayant une adresse dans le code compilé, la référence de premier type étant une référence indirecte au code compilé de l'entité, dans laquelle est enregistrée l'adresse de la référence de la table, - des moyens d'écriture dans une liste destinés, en cas de détection d'un appel de premier type, à écrire l'adresse de la référence de premier type dans la liste, et - des seconds moyens de remplacement destinés, en cas de détection d'un appel de second type, à remplacer, l'appel du code source en une référence, dite de second type, dans le code compilé, la référence de second type étant : + soit une référence directe à un code compilé de l'entité, dans laquelle est enregistrée une adresse du code compilé de l'entité, + soit une référence indirecte au code compilé de l'entité, dans laquelle est enregistrée une adresse, hors de la table, d'une autre référence au code compilé de l'entité. Grâce à l'invention, il est donc possible, lors de la programmation, d'introduire des appels qui contourneront à la fois la table des constantes et la liste d'emplacements de référence, et donc les vérifications que le chargeur réalise lorsqu'il utilise cette table des constantes lors du chargement. D'autres caractéristiques de l'invention, combinables entre elles suivant toutes les combinaisons techniquement possibles, sont : - les moyens de détection sont destinés à détecter la présence, dans le code source, d'un label associé à l'appel, la présence du label indiquant que l'appel est de second type ; - les moyens de détection sont destinés à détecter l'absence, dans le code source, de label associé à l'appel, l'absence de label indiquant que l'appel est de premier type ; - le dispositif de compilation comprend des moyens de sortie destinés à générer, dans le cas où l'appel est du second type, des données associant un nom de l'entité avec la référence de second type à cette entité ; - le dispositif de compilation comprend en outre des moyens de lecture destinés à lire, dans le cas où l'appel est de second type, des données associant un nom de l'entité avec la référence de second type à cette entité, et en ce que les seconds moyens de remplacement sont destinés à remplacer l'appel de second type par la référence de second type lue ; et - le dispositif de compilation est destiné à compiler du code source écrit en langage Java Card en code compilé, et il comprend des moyens de sortie destinés à générer un fichier CAP comprenant le code compilé et destiné à être chargé dans une mémoire d'une carte Java Card. Un autre objet de l'invention est un procédé de compilation d'un code source en un code compilé, le code source comprenant au moins un appel à une entité, le procédé étant caractérisé en ce qu'il comprend : - détecter si l'appel est un appel dit de premier type ou bien un appel dit de second type, - en cas de détection d'un appel de premier type : + écrire, à une adresse d'une table, une référence à un code compilé de l'entité, + remplacer l'appel du code source en une référence, dite de premier type, dans le code compilé, la référence de premier type ayant une adresse dans le code compilé, la référence de premier type étant une référence indirecte au code compilé de l'entité, dans laquelle est enregistrée l'adresse de la référence de la table, + écrire l'adresse de la référence de premier type dans une liste, et - en cas de détection d'un appel de second type : + remplacer l'appel du code source en une référence, dite de second type, dans le code compilé, . la référence de second type étant : * soit une référence directe à un code compilé de l'entité, dans laquelle est enregistrée une adresse du code compilé de l'entité, * soit une référence indirecte au code compilé de l'entité, dans laquelle est enregistrée une adresse, hors de la table, d'une autre référence au code compilé de l'entité. Selon d'autres caractéristiques de l'invention, combinables entre elles suivant toutes les combinaisons techniquement possibles : - la détection du type d'appel de méthode comprend : détecter la présence, dans le code source, d'un label associé à l'appel, la présence du label indiquant que l'appel est du second type ; - la détection du type d'appel de méthode comprend : détecter l'absence, dans le code source, de label associé à l'appel, l'absence de label indiquant que l'appel est du premier type ; - le procédé comprend : générer, dans le cas où l'appel est du second type, des données associant un nom de l'entité avec la référence de second type à cette entité ; - le procédé comprend: dans le cas où l'appel est du second type, lire des données associant un nom de l'entité avec la référence de second type à cette entité, et l'étape de remplacer l'appel par une référence directe à comprend : remplacer l'appel par la référence de second type lue ; - le code source est en langage Java Card, et le procédé comprend : générer un fichier CAP comprenant le code source compilé et destiné à être chargé dans une mémoire d'une carte Java Card. Un autre objet de l'invention est un compilateur comprenant du code exécutable qui, lorsqu'exécuté par un ordinateur, met en oeuvre les étapes d'un procédé de compilation selon l'invention. Ces caractéristiques et avantages de l'invention, ainsi que d'autres, apparaîtront dans la description qui va suivre d'un mode de réalisation préféré de l'invention. La description fait référence aux figures annexées qui représentent : - sur la figure 1, un dispositif de compilation selon l'invention, ainsi que les fichiers qu'il reçoit et fournit, - sur la figure 2, les étapes d'un premier procédé de compilation mis en oeuvre par le dispositif de compilation de la figure 1, - sur la figure 3, le dispositif de compilation de la figure 1, ainsi que de nouveaux fichiers qu'il reçoit et fournit, et - sur la figure 4, les étapes d'un second procédé se compilation correspondant au cas de la figure 3. En référence à la figure 1, un dispositif de compilation Java Card 100 est destiné à recevoir un fichier source 102 comprenant un code source d'une classe Cl 104, écrit en langage Java Card. Le dispositif de compilation 100 comprend des éléments matériels et logiciels lui permettant de réaliser les fonctions qui seront décrites par la suite. Par exemple, il s'agit d'un ordinateur sur lequel est installé un compilateur (c'est-à-dire un logiciel ou programme d'ordinateur de compilation). La classe Cl comprend le code source de trois méthodes : un code source 106 d'une méthode main, un code source 108 d'une méthode M1 et un code source 110 d'une méthode M2. Le code source 106 de la méthode main comprend un appel 112 à la méthode M1 et un appel 114 à la méthode M2. Dans l'exemple décrit, un appel à une entité consiste en le nom de cette entité, suivi, le cas échéant, pour une méthode, des paramètres à lui passer, indiqués entre parenthèses. Le code source 106 de la méthode main comprend en outre un label 116 associé à l'appel 114 à la méthode M2. Dans l'exemple décrit, le label 116 est constitué du mot clé � direct � précédant l'appel 114. On remarquera que l'appel 112 à la méthode M1 est dépourvu de label. L'absence de label pour l'appel 112 indique que cet appel 112 est un appel dit de premier type et sera ainsi traité de la manière classique par le dispositif de compilation 100. Au contraire, la présence du label 116 pour l'appel 114 indique que cet appel 114 est un appel de second type et sera ainsi traité différemment par le dispositif de compilation 100, comme cela sera expliqué par la suite. Le dispositif de compilation 100 comprend des moyens de compilation 118 destinés à parcourir le code source 104 afin de le convertir en code compilé, c'est- à-dire dans l'exemple illustré, des instructions, sous forme de code compilé, pour une machine virtuelle Java. En particulier, dans l'exemple illustré, les moyens de compilation 118 sont destinés à compiler le code source 106 de la méthode main en un code compilé 134, le code source 108 de la méthode M1 en un code compilé 136 et le code source de la méthode M2 en un code compilé 138. Les moyens de compilation 118 comprennent des moyens de détection 120 destinés à détecter, lorsqu'une ligne parcourue comprend un appel, si cet appel est de premier type ou de second type. Dans l'exemple décrit, les moyens de détection 120 sont destinés à détecter la présence ou l'absence, dans le code source 104, d'un label associé à l'appel rencontré. Les moyens de compilation 118 comprennent en outre des moyens d'écriture 121 dans une table 130, dite table des constantes (� constant pool �), destiné à regrouper les références à des entités (situées soit dans le code source en train d'être compilé, soit en dehors) appelées au moyen d'une référence de premier type dans le code source en train d'être compilé. Les moyens d'écriture 121 sont destinés, en cas de détection d'un appel de premier type (par exemple, l'appel 112), à écrire, à une adresse L de la table 130, une référence 133 au code compilé 136 de l'entité M1. Dans l'exemple décrit, il s'agit d'une référence directe dans laquelle est enregistrée une adresse Ad(M1) du code compilé 136. Les moyens de compilation 118 comprennent en outre des premiers moyens de remplacement 123 destinés, en cas de détection d'un appel de premier type, à remplacer l'appel du code source en une référence (par exemple la référence 140 pour l'appel 112), dite de premier type, à une adresse Ad dans le code compilé. Les premiers moyens de remplacement sont destinés à enregistrer l'adresse L de la référence 133 de la table 130 dans la référence de premier type 140, afin que cette dernière soit une référence indirecte au code compilé 136 de l'entité M1, passant par la table des constantes 130. Les moyens de compilation 118 comprennent en outre des moyens d'écriture 125 dans une liste 131, dite liste d'emplacements de référence (� reference location component �), destinée à lister les adresses dans le code compilé de toutes les références de premier type. grâce à cette liste d'emplacements de référence 131, il est possible de distinguer, dans l'agrégat de méthodes 132, une référence de premier type par rapport à un autre type de données. Les moyens d'écriture 125 sont ainsi destinés, en cas de détection d'un appel de premier type (par exemple, l'appel 112), à écrire, dans la liste d'emplacements de référence 131, l'adresse Ad de la référence de premier type 140 qui remplace l'appel 112 dans le code compilé. Les moyens de compilation 118 comprennent en outre des seconds moyens de remplacement 127 destinés, en cas de détection d'un appel de second type (par exemple, l'appel 114), à remplacer l'appel du code source en une référence (par exemple, la référence 142 pour l'appel 114), dite de second type, dans le code compilé. Dans l'exemple illustré sur la figure 1, les seconds moyens de remplacement 127 sont destinés à enregistrer une adresse Ad(M2) du code compilé 138 de l'entité M2 dans la référence de second type 142, de sorte que cette dernière soit une référence directe au code compilé 138 de l'entité M2. En variante, les seconds moyens de compilation 127 sont destinés à enregistrer, dans la référence de second type, une adresse, hors de la table de constante 130, d'une autre référence au code compilé de l'entité M2. Ainsi, la référence de second type est alors une référence indirecte au code compilé de l'entité M2, ne passant pas par la table de constantes 130. On remarquera que les références de second type, telles que la référence 142, ne sont ainsi pas inscrites dans la liste d'emplacements de référence 131. Le dispositif de compilation 100 comprend en outre des moyens de sortie 122 destinés à fournir, à la fin de la compilation, un fichier CAP 124, un fichier d'export 126 et un fichier supplémentaire, appelé fichier de symboles 128. Le fichier CAP 124 comprend la table de constantes 130, un agrégat de méthodes 132 (� method component �) (comprenant le code compilé 134 de la méthode main, le code compilé 136 de la méthode M1 et le code compilé 138 de la méthode M2), et la liste d'emplacements de référence 131. Ainsi, les références de second type permettent de contourner l'effet au chargement de la liste d'emplacements de référence 131, et ce, sans modification du procédé de chargement. Le code compilé 132 du fichier CAP 124 est destiné à être chargé dans une mémoire 144 d'une carte Java Card 146 comportant une machine virtuelle Java. Dans l'exemple décrit, après chargement, cette mémoire 144 comporte un code chargé 148 de la méthode main, un code chargé 150 de la méthode M1 et un code chargé 152 de la méthode M2. Le code chargé se distingue du code compilé notamment en ce que, lors du chargement, les références de premier type repérées par la liste d'emplacements de référence 131 sont transformées en références directes à l'aide de la table des constantes 130. Le fichier d'export 126 comprend des données associant les noms des entités appelées par un appel de premier type (c'est-à-dire destiné à être converti en une référence indirecte via la table des constantes 130) à une référence de premier type les remplaçant dans le code compilé. Le fichier de symboles 128 comprend des données associant les noms des entités appelées par un appel de second type (c'est-à-dire destiné à être converti en une référence directe ou une référence indirecte ne passant pas par la table des constantes 130) à une référence de second type les remplaçant dans le code compilé. Une utilisation de ce fichier de symboles 128 sera décrite plus loin, en référence à la figure 3. En référence à la figure 2, le dispositif de compilation 100 en fonctionnement met en oeuvre le procédé de compilation suivant. Le dispositif de compilation 100 reçoit le fichier source 102 (étape 200). Au cours d'une étape 202, les moyens de compilation 118 parcourent les lignes du code source 106, 108 et 110 et les compilent en code compilé 134, 136 et 138 dans l'agrégat de méthode 132. Au cours de la réalisation de l'étape 202, les moyens de compilation 118 rencontrent l'appel 112 à la méthode M1 (étape 204). Les moyens de détection 120 détectent que l'appel 112 est du premier type, en détectant l'absence de label associé à l'appel 112 (étape 206). En conséquence, les moyens d'écriture 121 inscrivent, à la ligne (adresse) L de la table des constantes 130, la référence 133 (directe dans l'exemple décrit) à la méthode M1 (étape 208). Les premiers moyens de remplacement 123 compilent alors l'appel 114 en le remplaçant par la référence de premier type 140, de sorte que la méthode M1 soit identifiée au moyen de l'adresse L de la référence 133 de la table des constantes 130, dans le code compilé (étape 210). Les moyens d'écriture 125 inscrivent dans la liste d'emplacements de référence 131 l'adresse Ad de la référence indirecte 140 dans l'agrégat de méthodes 132 (étape 212). Au cours de la réalisation de l'étape 202, les moyens de compilation 118 rencontrent l'appel 114 à la méthode M2 (étape 214). Les moyens de détection 120 détectent que l'appel 114 est du second type, en détectant la présence du label 116 associé à l'appel 114 (étape 216). En conséquence, les second moyens de remplacement 127 compilent l'appel 114 en le remplaçant par la référence de second type 142 dans le code compilé (étape 218). On remarquera que, pour l'appel 114, les seconds moyens de remplacement 118 laissent inchangée la liste d'emplacements de référence 131 ainsi que la table de constantes 130. Lorsque la compilation est terminée, les moyens de sortie 122 fournissent le fichier CAP 124, le fichier d'export 126 et le fichier de symboles 128 (étape 220). En référence à la figure 3, le compilateur 100 est également destiné à recevoir un nouveau fichier source 300 comprenant un code source d'une classe C2 302, écrit en langage Java Card. La classe C2 comprend un code source 304 d'une méthode main. comprenant un appel 306 à la méthode M2 de la classe Cl 104. Le code source 304 comprend en outre un label 308 (identique au label 116) associé à l'appel 306 et indiquant que l'appel 306 est du second type. Afin de permettre aux moyens de compilation 118 de remplacer l'appel 306 par une référence directe à la méthode M2, alors que cette dernière a été préalablement compilée, le compilateur 100 comprend en outre des moyens de lecture 310 destinés à lire le fichier de symboles 128. En outre, les second moyens de remplacement 127 sont destinés à remplacer l'appel 306 par la référence de second type 142 lue dans le fichier de symboles. En référence à la figure 4, le procédé de compilation du fichier source 300 est similaire à celui de la figure 2, si ce n'est que l'étape 218 au cours de laquelle l'appel du second type, ici 306, est remplacé par une référence directe, comprend une étape 400 au cours de laquelle les moyens de lecture 310 lisent le fichier de symboles 128 et une étape 402 au cours de laquelle les seconds moyens de remplacement 127 remplacent l'appel de second type par la référence de second type 142 lue depuis le fichier de symboles 128. L'invention n'est pas limitée à l'exemple précédent. En particulier, la distinction entre appels de premier type et appels de second type pourrait être réalisée sans utiliser de label. Par exemple, le dispositif de compilation pourrait avoir accès à une liste de noms d'entités dont les appels devraient à chaque fois être du second type. De plus, les mêmes principes jouent pour des appels à d'autres types d'entités que des méthodes, par exemple des champs d'objets ou des classes. En outre, l'invention n'est pas limitée au langage Java ni Java Card. REVENDICATIONS1. Dispositif de compilation destiné à compiler un code source (104 ; 302) en un code compilé, le code source (104 ; 302) comprenant au moins un appel (112, 114 ; 306) à une entité (Ml, M2), le dispositif étant caractérisé en ce qu'il comprend : - des moyens de détection (120) destinés à détecter si l'appel (114 ; 306) est un appel dit de premier type ou bien un appel dit de second type, - des moyens d'écriture dans une table (130) destinés, en cas de détection d'un appel (112) de premier type, à écrire, à une adresse (L) de la table (130), une référence (133) à un code compilé de l'entité (Ml) - des premiers moyens de remplacement destinés, en cas de détection d'un appel (112) de premier type, à remplacer l'appel (112) du code source en une référence (140), dite de premier type, dans le code compilé, la référence de premier type ayant une adresse (Ad) dans le code compilé (1 32), la référence de premier type étant une référence indirecte au code compilé de l'entité (M1), dans laquelle est enregistrée l'adresse (L) de la référence (133) de la table (130), - des moyens d'écriture dans une liste destinés, en cas de détection d'un appel (112) de premier type, à écrire l'adresse de la référence de premier type dans la liste, et - des seconds moyens de remplacement destinés, en cas de détection d'un appel (114 ; 306) de second type, à remplacer, l'appel (114 ; 306) du code source en une référence, dite de second type (142), dans le code compilé, la référence de second type (142) étant : + soit une référence directe (142) à un code compilé de l'entité (M2), dans laquelle est enregistrée une adresse (Ad(M2)) du code compilé de l'entité (M2), + soit une référence indirecte au code compilé de l'entité (M2), dans laquelle est enregistrée une adresse, hors de la table (130), d'une autre référence au code compilé de l'entité (M2). 2. Dispositif de compilation selon la revendication 1, caractérisé en outre en ce que les moyens de détection (120) sont destinés à détecter la présence, dans le code source (104 ; 302), d'un label (116 ; 308) associé à l'appel (114 ; 306), la présence du label (116 ; 308) indiquant que l'appel (114 ; 306) est de second type. 3. Dispositif de compilation selon la revendication 2, caractérisé en outre en ce que les moyens de détection (120) sont destinés à détecter l'absence, dans le code source (104), de label associé à l'appel (112), l'absence de label indiquant que l'appel (112) est de premier type. 4. Dispositif de compilation selon l'une quelconque des revendications 1 à 3, caractérisé en outre en ce qu'il comprend des moyens de sortie (122) destinés à générer, dans le cas où l'appel (114) est du second type, des données (128) associant un nom de l'entité (M2) avec la référence de second type (142) à cette entité. 5. Dispositif de compilation selon l'une quelconque des revendications 1 à 4, caractérisé en ce qu'il comprend en outre des moyens de lecture (310) destinés à lire, dans le cas où l'appel (306) est de second type, des données (128) associant un nom de l'entité (M2) avec la référence de second type (142) à cette entité, et en ce que les seconds moyens de remplacement (127) sont destinés à remplacer l'appel de second type (306) par la référence de second type (142) lue. 6. Dispositif de compilation selon l'une quelconque des revendications 1 à 5, caractérisé en outre en ce qu'il est destiné à compiler du code source écrit en langage Java Card en code compilé, et en ce qu'il comprend des moyens de sortie (122) destinés à générer un fichier CAP comprenant le code compilé et destiné à être chargé dans une mémoire (144) d'une carte Java Card (146). 7. Procédé de compilation d'un code source (104 ; 302) en un code compilé (132), le code source (104 ; 302) comprenant au moins un appel (112, 114 ; 306) à une entité (M1, M2), le procédé étant caractérisé en ce qu'il comprend : - détecter (206, 216) si l'appel est un appel dit de premier type ou bien un appel dit de second type, - en cas de détection (206) d'un appel de premier type : + écrire, à une adresse (L) d'une table (130), une référence à un code compilé de l'entité (Ml),+ remplacer (210) l'appel (112) du code source en une référence, dite de premier type (140), dans le code compilé, la référence de premier type ayant une adresse (Ad) dans le code compilé (132), la référence de premier type (140) étant une référence indirecte au code compilé de l'entité (M1), dans laquelle est enregistrée l'adresse (L) de la référence (133) de la table (130), + écrire l'adresse (Ad) de la référence de premier type (140) dans une liste (131), et - en cas de détection (216) d'un appel de second type : + remplacer (218) l'appel (114 ; 306) du code source en une référence, dite de second type (142), dans le code compilé, la référence de second type (142) étant : * soit une référence directe (142) à un code compilé de l'entité (M2), dans laquelle est enregistrée une adresse (Ad(M2)) du code compilé de l'entité (M2), * soit une référence indirecte au code compilé de l'entité (M2), dans laquelle est enregistrée une adresse, hors de la table (130), d'une autre référence au code compilé de l'entité (M2). 8. Procédé selon la revendication 7, caractérisé en outre en ce que la détection du type d'appel de méthode comprend : - détecter la présence, dans le code source, d'un label associé à l'appel, la présence du label indiquant que l'appel est du second type. 9. Procédé selon la revendication 7 ou 8, caractérisé en outre en ce que la détection du type d'appel de méthode comprend : - détecter l'absence, dans le code source, de label associé à l'appel, l'absence de label indiquant que l'appel est du premier type. 10. Procédé selon l'une quelconque des revendications 7 à 9, caractérisé en outre en ce qu'il comprend : - générer, dans le cas où l'appel est du second type, des données (128) associant un nom de l'entité (M2) avec la référence de second type (142) à cette entité (M2). 11. Procédé selon l'une quelconque des revendications 7 à 10, caractérisé en ce qu'il comprend en outre : - dans le cas où l'appel (306) est du second type, lire (400) des données (128) associant un nom de l'entité avec la référence de second type à cette entité, et en ce que l'étape (218) de remplacer l'appel par une référence directe à comprend : - remplacer (402) l'appel par la référence de second type lue. 12. Procédé selon l'une quelconque des revendications 7 à 10, caractérisé en outre en ce le code source est en langage Java Card, et en ce qu'il comprend : - générer un fichier CAP comprenant le code source compilé et destiné à être chargé dans une mémoire d'une carte Java Card. 13. Compilateur comprenant du code exécutable qui, lorsqu'exécuté par un ordinateur, met en oeuvre les étapes d'un procédé de compilation selon l'une quelconque des revendications 7 à 12.15