WO2006048378A1 - Procede de chargement d'un code logiciel en langage intermediaire oriente objet dans un appareil portatif - Google Patents
Procede de chargement d'un code logiciel en langage intermediaire oriente objet dans un appareil portatif Download PDFInfo
- Publication number
- WO2006048378A1 WO2006048378A1 PCT/EP2005/055405 EP2005055405W WO2006048378A1 WO 2006048378 A1 WO2006048378 A1 WO 2006048378A1 EP 2005055405 W EP2005055405 W EP 2005055405W WO 2006048378 A1 WO2006048378 A1 WO 2006048378A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- code
- destination
- instruction
- source
- jump
- Prior art date
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/445—Program loading or initiating
Definitions
- the present invention relates to software and operating environments embedded in a portable device and in particular the processes for converting such software when loaded into the portable device for execution.
- a portable device will designate thereafter any portable digital device with a microcontroller uniting a processor and memories, such as a smart card for example.
- a microcontroller unit comprising a processor and memories, such as a smart card for example.
- the desire to create interoperable applications has led to the development of intermediate object-oriented programming languages.
- the main purpose of these languages is to make their software independent of the hardware on which they must be executed.
- the software is then designed to run as an intermediate code independent of the underlying architecture.
- the intermediate code therefore conventionally corresponds to a compiled form of the software.
- These intermediate codes can not be executed as such by the processor of the device on which it is desired to run a program compiled as an intermediate code.
- This software layer is called "virtual machine".
- the JAVA virtual machine allows the execution of Java software on a given platform on which it is implemented. To do this, the virtual machine has its own set of instructions, each instruction being coded on one or more bytes.
- the instruction set of the virtual machine includes for example a number of conventional instructions such as arithmetic operations, logic and jumps.
- the virtual machine has an execution stack. Indeed, it does not include any user registry, which the programmer of the software could use directly. Instead, we use local variables numbered from zero.
- FIG. 1 illustrates an example of the means implemented for loading compiled software 10 in the form of a source intermediate code into a smart card 20, which constitutes in this case the portable device.
- the smart card is provided with a virtual machine for the execution of such software.
- Part of the virtual machine, more particularly named charger 30, is designed to load into working memory of the smart card 20, from a source apparatus 40, for example a server to which the card is connected by any means not shown, the software code 10 compiled in an object-oriented intermediate language.
- the charger 30 is an application that is for example stored in a non-volatile memory of the portable device.
- the source intermediate code 10 When loading a method for example of the source intermediate code 10 on the card by the virtual machine, it is converted into an internal code 50, said destination code thereafter.
- the information of the intermediate code 10 is converted into machine code instructions 50 directly executable by the processor of the system in question, in this case the smart card.
- the destination code may also be in the form of a converted intermediate code.
- the MSIL intermediate code is intended to be translated into machine code by a "just in time” compiler ("Jit compiler” in English terminology).
- Jit compiler in English terminology.
- a conversion of the source intermediate code 10 into an internal intermediate code to make the execution of the method more efficient can be implemented.
- the instruction code "Add” for the addition is likely to act on whole numbers, floating or otherwise.
- the source intermediate code is not modified, it will be necessary to keep typing information to be able to determine at runtime what type of number the software is handling when an "Add" statement is encountered. .
- the transformation of the instruction code "Add” in the source intermediate code into an instruction code in the destination code directly indicating the typing information associated with the addition operation, for example "Add Float”, will then allow to perform the execution without the need to retain the typing information.
- the corresponding instructions of the destination code constituted either by the machine code executable by the processor of the card, or by a code intermediate, will not necessarily keep the same size as the instructions in the source code.
- an instruction code can for example be converted into several instruction sequences.
- the destination addresses of the jump instructions are expressed in positive or negative displacements in terms of bytes relative to the beginning of the method, to indicate the instruction to the targeted target address.
- a jump instruction may consist of telling the program to jump to the instruction that is 5 bytes forward relative to the beginning of the method in the data structure in working memory in which the instruction is loaded. method of the source intermediate code.
- the size of the instructions is changed in the destination code during the step of loading (and conversion) of the source intermediate code, it is necessary in this case to readjust the parameters of the jump instructions describing the addresses of the source code. jump destination. It is thus necessary to be able to recalculate the expected displacements in bytes in the destination code taking into account the size of the new converted instructions, so as to indicate in the destination code the good hop destination addresses corresponding to the parameters of the jump instructions.
- a solution of the prior art typically consists, during the loading of the code, in developing and storing conversion tables in memory, making it possible to associate, for each method loaded, the old hop target destination addresses in the source intermediate code. to the corresponding new hop destination addresses in the destination code. It is then necessary to provide an entry in the table for each jump destination address.
- this solution presents disadvantages. It involves monopolizing a certain amount of RAM, used as working memory, to store the conversion tables and the amount of memory required is more proportional to the number of different jump destination addresses in the code.
- a smart card typically comprises between 1 and 4 kilobytes of random access memory (used as working memory), between 32 and 64 kilobytes of non-volatile memory rewritable (used as working memory and as memory mass) and approximately 256 kilobytes of ROM (used to store the code of the runtime environment).
- working memory used as working memory
- non-volatile memory rewritable used as working memory and as memory mass
- ROM used to store the code of the runtime environment
- Another solution for such a system then consists in using a destination code format that does not modify the object movements of the jump instructions with respect to the source intermediate code that is loaded.
- a converted internal code format is typically used where the instructions of the destination code are the same size as those of the source intermediate code, so as not to have to recalculate the object movements of the hops through conversion tables.
- the present invention aims to solve the aforementioned drawbacks.
- the subject of the invention is thus a method for loading a source software code compiled into an object-oriented intermediate language into a portable digital apparatus provided with a virtual execution machine, comprising a step of converting the sequence of instructions of said source code for generating a destination code formed from said converted instruction sequence, and a destination code updating step comprising determining, for each converted hop instruction, the new hop destination address in the corresponding destination code at the jump destination address of the corresponding jump instruction in the source code, characterized in that the determination of the new hop destination address in the destination code comprises a simultaneous analysis of the source and destination codes taking into account the size of the instructions of the source code and that corresponding converted instructions of the destination code.
- the simultaneous analysis of the source and destination codes for the determination of the new destination hop address in the destination code comprises the following steps:
- the addition of the size of the corresponding converted instruction in the destination code to the destination index comprises a preliminary step of reading said instruction in the destination code.
- the destination code is a code in intermediate language.
- the destination code is a machine code executable by the portable device.
- the invention also relates to a loader of source software code compiled into an object-oriented intermediate language intended to be loaded into a portable digital apparatus, characterized in that it is capable of being stored in a non-volatile memory of the apparatus for the implementation of the process according to the invention.
- the invention also relates to a portable digital device comprising a non-volatile memory storing the charger as just described.
- this device is a smart card.
- FIG. 1 illustrates an example of means implemented for loading compiled software code in the form of an intermediate code, said source code, in a smart card and has already been described;
- FIG. 2 is a flowchart summarizing the main steps of the method of the invention according to a preferred embodiment.
- MSIL for its loading on a smart card, although the invention also applies to software compiled in other object-oriented intermediate languages, such as Java.
- the numbers on the left in hexadecimal notation correspond to the address of the corresponding instruction.
- Each instruction address is more particularly defined as a displacement or a position ("offset" according to the English terminology) with respect to the beginning of the method.
- the first instruction of the method is thus at the address 0000, then follows a list of instructions, among which jump instructions, with their address, or position relative to the beginning of the associated method.
- the instruction addresses in bold and italic correspond to hop instruction destination addresses.
- jump destination addresses will therefore have to be updated after conversion of the intermediate code to a destination code by the loader.
- the method is converted to the following destination code: example .nParams 0 .nLocals 1 .maxStack 2
- RET_0 Table 3 converted code before updating jump destination addresses
- the converted jump instruction "BRNZ" at address 000c which is a conversion of the corresponding jump instruction "brtrue.s” from the source code, should not target the jump destination address 0010 , but rather the jump destination address 0015, where the "CALL" statement, which is the instruction to be targeted by this jump instruction, is now coded.
- the next step is for the loader to rewrite the jump destination addresses in the destination code, so that they point to the appropriate instruction in the destination code.
- the loader can browse the source code or destination code until a hop instruction that needs to be updated is identified. In this case, the loader must convert the jump destination address of the jump instruction in the source code to a new appropriate jump destination address in the destination code.
- the jump instruction of the destination code at address 0004 needs to be updated, as well as the instructions at addresses 000c, 0012 and 0023.
- the determination of the new destination hop addresses in the destination code for these jump instructions will be done on the fly, in that it is performed dynamically and no intermediary such as a conversion table is necessary. . In particular, it will be based on a simultaneous analysis of the source and destination codes, taking into account the size of the instructions of the source code and that of the corresponding converted instructions of the destination code.
- the loader is intended to examine each instruction in the source code by maintaining a source index and a destination index previously initialized to zero.
- the size of the source instruction is added to the source index and the size of the corresponding converted instruction is added to the destination index.
- the value of the source index indicates the address of the current instruction in the source code while the value of the destination index indicates the address of the corresponding instruction in the source code. destination code.
- the problem is to determine the new destination hop address in the destination code corresponding to the jump destination address 0010 of the corresponding hop instruction in the source code.
- the source and destination indexes being initialized to zero, one reads the first instruction "ldc.i4.0" in the source code and one updates the value of the index of source with the size of this instruction , in this case 1 byte.
- Such an instruction is always converted into a 2-byte instruction, in this case "LDC 1 param”.
- the size of this corresponding converted statement is then added to the destination index for its update, which then takes the value 2.
- the second instruction read in the source code "stloc.O”
- its size is 1 byte and the source index is then updated by adding the size of the instruction and takes the value 2.
- the instruction "stloc.O" can be converted into instructions of different size depending on the type of variable being accessed.
- the size of the converted instruction can thus vary from 2 to 3 bytes.
- the destination index is updated by adding the size of this statement and takes the value 4. In this way, we know that the next current statement at address 0002 of the source code has a corresponding converted statement to the address 0004 in the destination code.
- the destination index contains the value indicating the new destination address of corresponding jump in the destination code, in this case 0015, which can then be updated in the jump instruction at the address 000c in the destination code.
- FIG. 2 depicts a flowchart summarizing the main steps of the method of the invention as just described with reference to the example.
- Figure 2 illustrates the two alternatives that arise for updating the index of destination.
- an instruction in the source code can be converted into another instruction in the destination code of a predefined and known size.
- it is necessary, in order to update the destination index, to read the corresponding converted instruction in the destination code to know the size of the converted instruction see the example with the statement "stloc.O" above.
- the invention makes it possible to perform such an update without the need to develop and store in memory address conversion tables, which often consume memory space.
- This solution therefore makes it possible to free up space in RAM memory when loading a program in intermediate language and is therefore particularly advantageous for portable devices constrained in memory.
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Devices For Executing Special Programs (AREA)
Abstract
L'invention concerne un procédé de chargement d'un code logiciel source (10) compilé en langage intermédiaire orienté objet dans un appareil numérique portatif (20) muni d'une machine virtuelle d'exécution, comprenant une étape de conversion de la suite d'instructions dudit code source pour générer un code destination (50) formé de ladite suite d'instructions converties, et une étape de mise à jour du code destination comprenant la détermination, pour chaque instruction de saut convertie, de la nouvelle adresse de destination de saut dans le code destination correspondant à l'adresse de destination de saut de l'instruction de saut correspondante dans le code source, caractérisé en ce que la détermination de la nouvelle adresse de destination de saut dans le code destination comprend une analyse simultanée des codes source et destination prenant en compte la taille des instructions du code source et celle des instructions converties correspondantes du code destination.
Description
PROCEDE DE CHARGEMENT D'UN CODE LOGICIEL EN LANGAGE INTERMEDIAIRE ORIENTE OBJET DANS UN APPAREIL PORTATIF
La présente invention concerne les logiciels et environnements d'exécution embarqués dans un appareil portatif et en particulier les procédés de conversion de tels logiciels lors de leur chargement dans l'appareil portatif pour exécution.
Un appareil portatif désignera par la suite tout appareil numérique portatif doté d'un microcontrôleur réunissant un processeur et des mémoires, tel qu'une carte à puce par exemple. La volonté de créer des applications inter opérables a conduit au développement des langages intermédiaires de programmation orientée objet. Le but principal de ces langages est ainsi de rendre leurs logiciels indépendants du matériel sur lequel ils doivent être exécutés. Les logiciels sont alors prévus pour s'exécuter sous la forme d'un code intermédiaire indépendant de l'architecture sous-jacente.
Les programmeurs sont ainsi globalement dégagés des contraintes liées à des matériels spécifiques. La diffusion d'une même version de logiciel pour différents matériels est également possible. Les langages intermédiaires orientés objet tels que le pseudo-code Java (désigné par bytecode en langue anglaise) , obtenu après compilation du langage source Java, ont ainsi connu un essor conséquent. On peut également citer le langage intermédiaire MSIL (acronyme anglo-saxon pour « Microsoft intermediate langage »)
déployé dans le cadre de l'environnement .net ou DotNet (marque déposée) , obtenu après compilation de divers langages sources possibles tels que C++ ou C#.
Le code intermédiaire correspond donc classiquement à une forme compilée du logiciel. Ces codes intermédiaires ne peuvent pas être exécutés tel quels par le processeur de l'appareil sur lequel on désire lancer un programme compilé sous forme de code intermédiaire. Il est nécessaire d'introduire une couche logicielle ayant pour principale fonction d' interpréter le code intermédiaire en instructions exécutables par le processeur de l'appareil hôte. Cette couche logicielle est appelée « machine virtuelle ». Par exemple, la machine virtuelle JAVA permet l'exécution d'un logiciel Java sur une plate-forme donnée sur laquelle elle est implémentée. Pour ce faire, la machine virtuelle dispose d'un jeu d'instructions propre, chaque instruction étant codée sur un ou plusieurs octets. Le jeu d'instructions de la machine virtuelle comporte par exemple un certain nombre d'instructions classiques comme les opérations arithmétiques, logiques et les sauts. Par ailleurs, la machine virtuelle dispose d'une pile d'exécution. En effet, elle ne comprend aucun registre utilisateur, que le programmeur du logiciel pourrait utiliser directement. A la place, on utilise des variables locales numérotées à partir de zéro.
La figure 1 illustre un exemple de moyens mis en œuvre pour charger un logiciel compilé 10 sous forme d'un code intermédiaire source dans une carte à puce 20, qui constitue en l'occurrence l'appareil portatif.
La carte à puce est munie d'une machine virtuelle pour l'exécution de tels logiciels. Une partie de la machine virtuelle, plus particulièrement nommée chargeur 30, est prévue pour charger en mémoire de travail de la carte à puce 20, à partir d'un appareil source 40, par exemple un serveur auquel la carte est connectée par des moyens quelconques non représentés, le code logiciel 10 compilé en langage intermédiaire orienté objet. Le chargeur 30 est une application qui est par exemple stockée dans une mémoire non volatile de l'appareil portatif.
Lors du chargement d'une méthode par exemple du code intermédiaire source 10 sur la carte par la machine virtuelle, celle-ci est convertie en un code interne 50, dit code destination par la suite. Typiquement, les informations du code intermédiaire 10 sont converties en des instructions en code machine 50 directement exécutables par le processeur du système considéré, en l'occurrence la carte à puce. Le code destination peut également être sous forme d'un code intermédiaire converti.
En effet, dans certains environnements tels que l'environnement .net, le code intermédiaire MSIL est destiné à être traduit en code machine par un compilateur « Juste à temps » (« Jit compiler » en terminologie anglo-saxonne) . Pendant le chargement d'une méthode, une conversion du code intermédiaire source 10 en un code intermédiaire interne visant à rendre l'exécution de la méthode plus efficace peut être mis en oeuvre.
Par exemple, dans le cas d'un logiciel compilé en langage MSIL, le code d'instruction « Add » pour l'addition est susceptible d'agir sur des nombres entiers, flottants ou autres. Ainsi, si le code intermédiaire source n'est pas modifié, il sera nécessaire de conserver des informations de typage pour pouvoir déterminer lors de l'exécution quel type de nombre le logiciel est en train de manipuler lorsqu'une instruction « Add » est rencontrée. La transformation du code d' instruction « Add » dans le code intermédiaire source en un code d' instruction dans le code destination indiquant directement l'information de typage associée à l'opération d'addition, par exemple « Add Float », permettra alors de faire l'exécution sans qu'il soit nécessaire de conserver l'information de typage.
Toutefois, du fait de la conversion opérée lors du chargement sur la carte des instructions d'une méthode du code intermédiaire source, les instructions correspondantes du code destination, constitué soit par le code machine exécutable par le processeur de la carte, soit par un code intermédiaire converti, ne vont plus nécessairement conserver la même taille que les instructions dans le code source. En effet, un code d' instruction peut par exemple être converti en plusieurs séquences d'instructions.
Un problème se pose alors dans le cas de la présence d' instructions de saut dans une méthode du code intermédiaire source destiné à être converti. En effet, dans le code intermédiaire, les adresses de destination des instructions de saut sont exprimées en
déplacements positifs ou négatifs en termes d'octets par rapport au début de la méthode, pour indiquer l'instruction à l'adresse cible visée. Par exemple, une instruction de saut peut consister à indiquer au programme qu'il faut sauter à l'instruction qui se trouve 5 octets en avant par rapport au début de la méthode dans la structure de données en mémoire de travail dans laquelle est chargée la méthode du code intermédiaire source. Aussi, comme la taille des instructions est amenée à changer dans le code destination lors de l'étape de chargement (et de conversion) du code intermédiaire source, il est nécessaire dans ce cas de réajuster les paramètres des instructions de saut décrivant les adresses de destination de saut. Il faut ainsi pouvoir recalculer les déplacements prévus en octets dans le code destination compte-tenu de la taille des nouvelles instructions converties, de façon à indiquer dans le code destination les bonnes adresses de destination de saut correspondant aux paramètres des instructions de saut.
Une solution de l'art antérieur consiste typiquement, durant le chargement du code, à élaborer et stocker en mémoire des tables de conversion, permettant d'associer, pour chaque méthode chargée, les anciennes adresses de destination cibles de saut dans le code intermédiaire source aux nouvelles adresses de destination de saut correspondantes dans le code destination. Il faut alors prévoir une entrée dans la table pour chaque adresse de destination de saut. Cependant, l'utilisation de cette solution présente des
inconvénients. Elle implique en effet de monopoliser une certaine quantité de mémoire vive, utilisée comme mémoire de travail, pour stocker les tables de conversion et la quantité de mémoire requise est de plus proportionnelle au nombre d'adresse de destination de saut différentes dans le code.
Aussi, si cette étape de chargement (et de conversion) de logiciels sous forme de code intermédiaire, basée sur l'utilisation de telles tables de conversion, est réalisable sur la plupart des ordinateurs de bureau présentant des ressources importantes de mémoire vive et de processeur, permettant ainsi de stocker les tables sans pénaliser pour autant l'exécution du logiciel en mémoire vive, certains systèmes devant embarquer des logiciels en code intermédiaire ont des capacités beaucoup plus limitées, qui empêchent l'utilisation des tables.
Ainsi, du fait des contraintes de miniaturisation, une carte à puce comprend typiquement entre 1 et 4 KiloOctets de mémoire vive (utilisée comme mémoire de travail) , entre 32 et 64 KiloOctets de mémoire non volatile réinscriptible (utilisée comme mémoire de travail et comme mémoire de masse) et environ 256 KiloOctets de mémoire morte (utilisée pour stocker le code de l'environnement d'exécution) . Une telle carte à puce est donc inadaptée à un fonctionnement qui impliquerait de stocker des tables de conversion pour recalculer les adresses de destination de saut dans le code destination. En effet, pour des méthodes comprenant un grand nombre de sauts, la taille de la
table deviendrait un problème susceptible d'empêcher le chargement du programme en mémoire.
Une autre solution pour de tels système consiste alors à utiliser un format de code destination qui ne modifie pas les déplacements objets des instructions de saut par rapport au code intermédiaire source qui est chargé. On utilise typiquement un format de code interne converti où les instructions du code destination ont la même taille que celles du code intermédiaire source, de façon à ne pas avoir à recalculer les déplacements objets des sauts par l'intermédiaire de tables de conversion. C'est la solution généralement adoptée par la machine virtuelle Java dans le cadre de la spécification JavaCard, permettant de faire tourner la technologie Java sur les cartes à puce et autres appareils à mémoire limitée. Cependant, cette solution n'est pas toujours envisageable.
La présente invention vise à résoudre les inconvénients précités. L'invention a ainsi pour objet un procédé de chargement d'un code logiciel source compilé en langage intermédiaire orienté objet dans un appareil numérique portatif muni d'une machine virtuelle d'exécution, comprenant une étape de conversion de la suite d'instructions dudit code source pour générer un code destination formé de ladite suite d'instructions converties, et une étape de mise à jour du code destination comprenant la détermination, pour chaque instruction de saut convertie, de la nouvelle adresse de destination de saut dans le code destination correspondant à l'adresse de destination de saut de
l'instruction de saut correspondante dans le code source, caractérisé en ce que la détermination de la nouvelle adresse de destination de saut dans le code destination comprend une analyse simultanée des codes source et destination prenant en compte la taille des instructions du code source et celle des instructions converties correspondantes du code destination.
Selon un mode de réalisation, l'analyse simultanée des codes source et destination pour la détermination de la nouvelle adresse de destination de saut dans le code destination comprend les étapes suivantes :
- lire la première instruction du code source et ajouter la taille de ladite instruction à un index de source préalablement initialisé à zéro ; - ajouter la taille de l'instruction convertie correspondante dans le code destination à un index de destination préalablement initialisé à zéro ;
- pour chaque instruction suivante du code source, lire ladite instruction et mettre à jour l'index de source en ajoutant la taille de ladite instruction et l'index de destination en ajoutant la taille de l'instruction convertie correspondante dans le code destination ;
- réitérer l'étape précédente jusqu'à ce que la valeur de l'index de source soit égale à l'adresse de destination de saut de l'instruction de saut correspondante dans le code source, et
- mettre à jour la nouvelle adresse de destination de saut dans le code destination avec la valeur de l'index de destination.
Selon un mode de réalisation particulier, l'ajout de la taille de l'instruction convertie correspondante dans le code destination à l'index de destination comprend une étape préalable de lecture de ladite instruction dans le code destination.
De préférence, le code destination est un code en langage intermédiaire.
Dans une variante, le code destination est un code machine exécutable par l'appareil portatif. L'invention concerne également un chargeur d'un code logiciel source compilé en langage intermédiaire orienté objet destiné à être chargé dans un appareil numérique portatif, caractérisé en ce qu'il est susceptible d'être stocké dans une mémoire non volatile de l'appareil pour la mise en œuvre du procédé selon 1' invention.
L'invention concerne encore un appareil numérique portatif comprenant une mémoire non volatile mémorisant le chargeur tel qu'il vient d'être décrit. De préférence, cet appareil est une carte à puce.
D'autres caractéristiques et avantages de la présente invention apparaîtront plus clairement à la lecture de la description suivante donnée à titre d'exemple illustratif et non limitatif et faite en référence aux figures annexées dans lesquelles :
-la figure 1 illustre un exemple de moyens mis en œuvre pour charger un code logiciel compilé sous forme d'un code intermédiaire dit code source, dans une carte à puce et a déjà été décrite ;
-la figure 2 est un organigramme résumant les principales étapes du procédé de l'invention selon un mode de réalisation préféré.
Par la suite, on détaillera plus particulièrement un exemple de réalisation pratique, dans le cas d'un logiciel compilé sous la forme d'un code intermédiaire
MSIL pour son chargement sur une carte à puce, bien que l'invention s'applique également pour des logiciels compilés dans d'autres langages intermédiaires orientés objet, tel que Java.
Ainsi, l'exemple suivant correspond à une méthode écrite en langage C#, prévue pour exécuter une boucle et appeler de manière répétée la fonction f() ou g() selon que la variable i est paire ou impaire : public static void example () { int i; for(i=0; i<100; ++i) { if( (i % 2) == 0 ) { f 0;
} else { g();
} } }
Tableau 1 : méthode en C#
Une fois ce programme compilé, on obtient le code source correspondant en langage intermédiaire MSIL. Le code suivant est plus précisément une représentation textuelle du code binaire qui sera chargé dans la carte :
.method public hidebysig static void example () cil managed {
.entrypoint
// Code size 31 (OxIf)
.maxstack 2
.locals init (int32 V 0) ldc.i4.0 stloc.O br.s 0019
0004 ldloc.O ldc.i4.2 rem brtrue.s 0010 call void Example.ExI::f (] br.s 0015
0010 call void Example.ExI: :g(]
0015 ldloc.O
\ \ Idc.i4.1
\ \ add stloc.O
0019 ldloc.O ldc.i4.s 100 bit.s 0004 ret
}
Tableau 2 : code intermédiaire MSIL
Les nombres sur la gauche en écriture hexadécimale correspondent à l'adresse de l'instruction correspondante. Chaque adresse d'instruction est plus particulièrement définie comme un déplacement ou une position (« offset » selon la terminologie anglo- saxonne) par rapport au début de la méthode. La première instruction de la méthode est ainsi à l'adresse 0000, puis suit une liste d'instructions, parmi lesquelles des instructions de saut, avec leur adresse, ou position par rapport au début de la méthode, associée. Les adresses d'instruction apparaissant en gras et en italique correspondent à des adresses de destination d'instructions de saut.
Ces adresses sont donc les adresses qui posent problème et qui vont devoir être mises à jour car il y a des instructions de saut dans le code intermédiaire qui les prennent en adresse de destination. Ainsi, à l'adresse 0002, on trouve l'instruction « br.s », qui
correspond à un saut et qui prend « 0019 » en paramètre indiquant l'adresse de destination de saut correspondante. A l'adresse 0007, on trouve l'instruction « brtrue.s », qui correspond à un saut et qui prend « 0010 » en paramètre indiquant l'adresse de destination de saut correspondante. A l'adresse 000e, on trouve l'instruction « br.s », qui prend « 0015 » en paramètre indiquant l'adresse de destination de saut correspondante. Enfin, à l'adresse 001c, on trouve l'instruction « bit. s », qui correspond à un saut et qui prend « 0004 » en paramètre indiquant l'adresse de destination de saut correspondante.
Ces adresses de destination de saut devront donc être mises à jour après conversion du code intermédiaire vers un code destination par le chargeur.
Selon l'exemple, la méthode est convertie dans le code destination suivant : example .nParams 0 .nLocals 1 .maxStack 2
LDC_1 0
STORE_4 0
BR 0019
LOAD_VAL 0
LDC_1 2
REM
BRNZ 0010
CALL 0 Method: Example.ExI.f
BR 0015
CALL 1 Method: Example.ExI.g
LOAD_VAL 0
LDC_1 1
ADD
STORE_4 0
LOAD_VAL 0
LDC_1 100
BLT 0004
RET_0 Tableau 3: code converti avant mise à jour des adresses de destination de saut
Tout d'abord, on s'aperçoit, en comparant les adresses des instructions entre le code source et le code destination, que la taille des instructions converties est différente. Cependant, dans un premier temps, les adresses de destination de saut, apparaissant en gras et en italique ci-dessus, correspondant aux instructions de saut converties dans le code destination sont inchangées et restent identiques aux adresses de destination de saut correspondant aux instructions de saut correspondante dans le code source. Ces paramètres sont donc maintenant invalides car les instructions converties n'ont plus la même taille que les instructions correspondantes dans le code source. Par exemple, l'instruction de saut convertie « BRNZ » à l'adresse 000c, qui est une conversion de l'instruction de saut correspondante « brtrue.s » du code source, ne doit pas cibler l'adresse de destination de saut 0010, mais bien plutôt l'adresse de destination de saut 0015, où se trouve dorénavant codée l'instruction « CALL », qui est l'instruction devant être ciblée par cette instruction de saut.
L'étape suivante consiste alors pour le chargeur à réécrire les adresses de destination de saut dans le code destination, de sorte qu'elles pointent vers l'instruction appropriée dans le code destination.
Pour déterminer les adresses de destinations devant être mises à jour dans le code destination, le chargeur peut parcourir le code source ou le code destination jusqu'à ce qu'une instruction de saut nécessitant d'être mise à jour soit identifiée. Dans ce
cas, le chargeur doit convertir l'adresse de destination de saut de l'instruction de saut dans le code source en une nouvelle adresse de destination de saut appropriée dans le code destination. Ainsi, dans l'exemple, l'instruction de saut du code destination à l'adresse 0004 nécessite d'être mise à jour, de même que les instructions aux adresses 000c, 0012 et 0023.
La détermination des nouvelles adresses de destination de saut dans le code destination pour ces instructions de saut va être effectuée à la volée, en ce sens qu'elle est effectuée dynamiquement et qu'aucun intermédiaire telle qu'une table de conversion n'est nécessaire. Elle va plus particulièrement être basée sur une analyse simultanée des codes source et destination, prenant en compte la taille des instructions du code source et celle des instructions converties correspondantes du code destination.
Plus précisément, le chargeur est prévu pour examiner chaque instruction dans le code source en maintenant un index de source et un index de destination préalablement initialisés à zéro. Ainsi, pour chaque instruction lue dans le code source, la taille de l'instruction de source est ajoutée à l'index de source et la taille de l'instruction convertie correspondante est ajoutée à l'index de destination. De cette façon, à chaque itération, la valeur de l'index de source indique l'adresse de l'instruction courante dans le code source tandis que la valeur de l'index de destination indique l'adresse de l'instruction correspondante dans le code destination. Lorsque
l'index de source est égal à l'adresse de destination de saut recherchée que l'on veut mettre à jour dans le code destination, alors l'index de destination indique une adresse d'instruction correspondante dans le code destination, correspondant à la nouvelle adresse de destination de saut qu'il convient de mettre à jour.
Prenons un exemple se rapportant à la mise à jour de l'instruction de saut à l'adresse 000c dans le code destination. Le problème consiste à déterminer la nouvelle adresse de destination de saut dans le code destination correspondant à l'adresse de destination de saut 0010 de l'instruction de saut correspondante dans le code source.
Dans une première étape, les index source et destination étant initialisés à zéro, on lit la première instruction « ldc.i4.0 » dans le code source et on met à jour la valeur de l'index de source avec la taille de cette instruction, en l'occurrence 1 octet. Une telle instruction est toujours convertie en une instruction sur 2 octets, en l'occurrence « LDC 1 param ». La taille de cette instruction convertie correspondante est alors ajoutée à l'index de destination pour sa mise à jour, qui prend alors la valeur 2. Puis, on passe à l'instruction suivante du code source à l'adresse 0001. Grâce aux index source et destination qui sont maintenus par le chargeur, on sait que l'instruction courante dans le code source à l'adresse 0001 a une instruction convertie correspondante à l'adresse 0002 dans le code destination.
On passe alors à la deuxième instruction dans le code source. En ce qui concerne la deuxième instruction lue dans le code source « stloc.O », sa taille est de 1 octet et l'index de source est alors mis à jour en ajoutant la taille de l'instruction et prend la valeur 2.
L'instruction « stloc.O » peut être convertie en instructions de taille différente suivant le type de variable qui est accédée. La taille de l'instruction convertie peut ainsi varier de 2 à 3 octets. Dans cette situation, il est nécessaire d'aller lire l'instruction convertie correspondante dans le code destination, en l'occurrence « STORE 4 », indiquant que c'est la variante sur 2 octets qui a été utilisée. Aussi, l'index de destination est mis à jour en ajoutant la taille de cette instruction et prend la valeur 4. De cette manière, on sait que la prochaine instruction courante à l'adresse 0002 du code source a une instruction convertie correspondante à l'adresse 0004 dans le code destination.
Ce processus est réitéré jusqu'à ce que valeur de l'index de source soit égale à l'adresse de destination de saut 0010. Lorsque c'est le cas, l'index de destination contient la valeur indiquant la nouvelle adresse de destination de saut correspondante dans le code destination, en l'occurrence 0015, qui peut alors être mise à jour dans l'instruction de saut à l'adresse 000c dans le code destination.
On opère de la même façon pour la mise à jour des instructions de saut converties du code destination à l'adresse 0004, 0012 et 0023, consistant à déterminer
les nouvelles adresses de destination de saut correspondantes dans le code destination.
On obtient pour finir le code destination final avec la mise à jour effectuée des adresses de destination de saut apparaissant en gras et en italique ci-dessous : example
.nParams 0
.nLocals 1
.maxStack 2
LDC 1 0
STORE 4 0
BR 24 (001f)
00 07 LOAD VAL 0
>v> BRNZ 6 (0015)
>v> V : CALL 0 Method: Example.ExI.f
BR 3 (0018)
0015 CALL 1 Method: Example.ExI.g
STORE 4 0
00 If LOAD VAL 0
>V' LDC 1 100
BLT - 31 (0007)
%, RET 0
La figure 2 décrit un organigramme résumant les principales étapes du procédé de l'invention tel qu'il vient d'être décrit en référence à l'exemple. Ainsi, lors de l'itération sur chaque instruction dans le code source, tant que la valeur de l'index de source n'est pas égale à l'adresse de destination de saut recherchée que l'on veut mettre à jour, l'instruction courante dans le code source est lue et l'index de source est mis à jour en ajoutant la taille de l'instruction courante.
La figure 2 illustre les deux alternatives qui se présentent pour la mise à jour de l'index de
destination. En effet, comme on l'a vu en référence à l'exemple ci-dessus, une instruction dans le code source peut être convertie en une autre instruction dans le code destination d'une taille prédéfinie et connue. Dans ce cas, on a immédiatement la taille de l'instruction convertie correspondante, qui est ajoutée à l'index de destination. Cependant, il peut y avoir d'autres cas où il est nécessaire, pour mettre à jour l'index de destination, de lire l'instruction convertie correspondante dans le code destination pour connaître la taille de l'instruction convertie, voir l'exemple avec l'instruction « stloc.O » ci-dessus.
Puis, lorsque la valeur de l'index de source devient égale à l'adresse de destination de saut recherchée, la mise à jour de la nouvelle adresse de destination de saut est réalisée avec la valeur de l'index de destination.
Bien que plus coûteux en termes de ressources de calcul que les méthodes classiques pour mettre à jour les instructions de saut converties, l'invention permet d'effectuer une telle mise à jour sans qu'il soit nécessaire d'élaborer et de stocker en mémoire des tables de conversion d'adresses, souvent consommatrices d'espace mémoire. Cette solution permet donc de libérer de la place en mémoire RAM lors du chargement d'un programme en langage intermédiaire et est donc particulièrement avantageuse pour les appareils portatifs contraints en mémoire.
Claims
1. Procédé de chargement d'un code logiciel source (10) compilé en langage intermédiaire orienté objet dans un appareil numérique portatif (20) muni d'une machine virtuelle d'exécution, comprenant une étape de conversion de la suite d'instructions dudit code source pour générer un code destination (50) formé de ladite suite d'instructions converties, et une étape de mise à jour du code destination comprenant la détermination, pour chaque instruction de saut convertie, de la nouvelle adresse de destination de saut dans le code destination correspondant à l'adresse de destination de saut de l'instruction de saut correspondante dans le code source, caractérisé en ce que la détermination de la nouvelle adresse de destination de saut dans le code destination comprend une analyse simultanée des codes source et destination prenant en compte la taille des instructions du code source et celle des instructions converties correspondantes du code destination et consistant à : - lire la première instruction du code source et ajouter la taille de ladite instruction à un index de source préalablement initialisé à zéro ; ajouter la taille de l'instruction convertie correspondante dans le code destination à un index de destination préalablement initialisé à zéro ; - pour chaque instruction suivante du code source, lire ladite instruction et mettre à jour l'index de source en ajoutant la taille de ladite instruction et l'index de destination en ajoutant la taille de l'instruction convertie correspondante dans le code destination ;
- réitérer l'étape précédente jusqu'à ce que la valeur de l'index de source soit égale à l'adresse de destination de saut de l'instruction de saut correspondante dans le code source, et
- mettre à jour la nouvelle adresse de destination de saut dans le code destination avec la valeur de l'index de destination.
2. Procédé selon la revendication 1, caractérisé en ce que l'ajout de la taille de l'instruction convertie correspondante dans le code destination à l'index de destination comprend une étape préalable de lecture de ladite instruction dans le code destination.
3. Procédé selon la revendication 1 ou 2, caractérisé en ce que le code destination est un code en langage intermédiaire.
4. Procédé selon la revendication 1 ou 2, caractérisé en ce que le code destination est un code machine exécutable par l'appareil portatif.
5. Chargeur (30) d'un code logiciel source compilé en langage intermédiaire orienté objet destiné à être chargé dans un appareil numérique portatif (20) , caractérisé en ce qu'il est susceptible d'être stocké dans une mémoire non volatile de l'appareil pour la mise en œuvre du procédé selon l'une quelconque des revendications précédentes .
6. Appareil numérique portatif comprenant une mémoire non volatile mémorisant le chargeur de la revendication 5.
7. Appareil selon la revendication 6, caractérisé en ce que cet appareil est une carte à puce.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0411752A FR2877454B1 (fr) | 2004-11-04 | 2004-11-04 | Procede de chargement d'un code logiciel en langage intermediaire oriente objet dans un appareil portatif |
| FR0411752 | 2004-11-04 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| WO2006048378A1 true WO2006048378A1 (fr) | 2006-05-11 |
Family
ID=34950938
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| PCT/EP2005/055405 WO2006048378A1 (fr) | 2004-11-04 | 2005-10-20 | Procede de chargement d'un code logiciel en langage intermediaire oriente objet dans un appareil portatif |
Country Status (2)
| Country | Link |
|---|---|
| FR (1) | FR2877454B1 (fr) |
| WO (1) | WO2006048378A1 (fr) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101236489B (zh) * | 2008-02-26 | 2011-04-20 | 北京深思洛克软件技术股份有限公司 | 虚拟硬件系统及其指令执行方法、以及虚拟机 |
| CN108256888A (zh) * | 2016-12-29 | 2018-07-06 | 北京国双科技有限公司 | 落地页的获取方法、网站服务器以及网络广告监测系统 |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110618824B (zh) * | 2018-06-20 | 2023-07-21 | 中移（杭州）信息技术有限公司 | 一种软件升级方法、装置、介质和设备 |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20030023954A1 (en) * | 1996-10-25 | 2003-01-30 | Wilkinson Timothy J. | Using a high level programming language with a microcontroller |
| US20040003377A1 (en) * | 2002-06-28 | 2004-01-01 | Di Loreto Michael A. | Converting byte code instructions to a new instruction set |
-
2004
- 2004-11-04 FR FR0411752A patent/FR2877454B1/fr not_active Expired - Fee Related
-
2005
- 2005-10-20 WO PCT/EP2005/055405 patent/WO2006048378A1/fr active Application Filing
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20030023954A1 (en) * | 1996-10-25 | 2003-01-30 | Wilkinson Timothy J. | Using a high level programming language with a microcontroller |
| US20040003377A1 (en) * | 2002-06-28 | 2004-01-01 | Di Loreto Michael A. | Converting byte code instructions to a new instruction set |
Non-Patent Citations (2)
| Title |
|---|
| "METHOD AND APPARATUS FOR DETERMINING BRANCH ADRESSES IN PROGRAMS GENERATED BY BINARY TRANSLATION", RESEARCH DISCLOSURE, KENNETH MASON PUBLICATIONS, WESTBOURNE, GB, no. 416, December 1998 (1998-12-01), pages 1667 - 1673, XP000834139, ISSN: 0374-4353 * |
| ANONYMOUS: "Lookup table", WIKIPEDIA, 14 August 2004 (2004-08-14), XP002329538, Retrieved from the Internet <URL:http://en.wikipedia.org/w/index.php?title=Lookup_table&oldid=9939793> [retrieved on 20050525] * |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101236489B (zh) * | 2008-02-26 | 2011-04-20 | 北京深思洛克软件技术股份有限公司 | 虚拟硬件系统及其指令执行方法、以及虚拟机 |
| CN108256888A (zh) * | 2016-12-29 | 2018-07-06 | 北京国双科技有限公司 | 落地页的获取方法、网站服务器以及网络广告监测系统 |
| CN108256888B (zh) * | 2016-12-29 | 2022-03-25 | 北京国双科技有限公司 | 落地页的获取方法、网站服务器以及网络广告监测系统 |
Also Published As
| Publication number | Publication date |
|---|---|
| FR2877454B1 (fr) | 2006-12-29 |
| FR2877454A1 (fr) | 2006-05-05 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP1212678B1 (fr) | Protocole de gestion, procede de verification et de transformation d'un fragment de programme telecharge et systemes correspondants | |
| US8261244B2 (en) | Arbitrary runtime function call tracing | |
| CA2317950C (fr) | Procede de compactage d'un programme de type code objet intermediaire executable dans un systeme embarque muni de ressources de traitement de donnees, systeme compacteur et systeme embarque multi-applications correspondants | |
| EP2649522B1 (fr) | Methode de mise a disposition d'une application en tant que librairie dans une machine virtuelle | |
| EP1486884A2 (fr) | Mécanisme de rendu de pages web en utilisant des thèmes programmatiques externes | |
| EP1782191A2 (fr) | Procede de chargement d"un logiciel en langage intermediaire oriente objet dans un appareil portatif | |
| US6574747B2 (en) | Extensible execute in place (XIP) architecture and related methods | |
| FR2906383A1 (fr) | Referentiel semantique de services web et procede utilisant ce referentiel | |
| EP1960934B1 (fr) | Procede pour securiser l'execution d'un code logiciel en langage intermediaire dans un appareil portatif | |
| EP1881404A1 (fr) | Procédé de protection dynamique des données lors de l'exécution d'un code logiciel en langage intermédiaire dans un appareil numérique | |
| US8332493B2 (en) | Directory server plug-in call ordering | |
| FR2841998A1 (fr) | Procede d'execution sur une station d'un reseau de communication d'un programme informatique represente dans un langage de balisage | |
| WO2006048378A1 (fr) | Procede de chargement d'un code logiciel en langage intermediaire oriente objet dans un appareil portatif | |
| WO2009128928A2 (fr) | Circuits et procedes de mobilite de fragments de programme effectifs | |
| FR2765363A1 (fr) | Procede et systeme de controle de l'utilisation d'un logiciel | |
| WO2003027851A1 (fr) | Procede et dispositif de verifieur de code optimise | |
| CA2504431C (fr) | Carte a microcircuit comportant des moyens de publication de ses objets informatiques | |
| WO2019180376A1 (fr) | Procédé et système pour créer une image d'une application | |
| EP3874368B1 (fr) | Executer des portions de code sur des ressources d´execution | |
| FR2817363A1 (fr) | Verification formelle notamment d'une machine virtuelle securisee | |
| CN117111904B (zh) | 用于将Web应用自动转换成无服务器函数的方法和系统 | |
| EP3411821B1 (fr) | Procédé de stockage de contenus, procédé de consultation de contenus, procédé de gestion de contenus et lecteurs de contenus | |
| FR2936327A1 (fr) | Procede de telechargement d'un programme .net et dispositif pour celui-ci | |
| EP4018313A1 (fr) | Récuperateur de données dans un dispositif électronique | |
| EP0688124B1 (fr) | Procédé de partage de ressources physiques et dispositif d'interface pour la mise en oeuvre du procédé |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| AK | Designated states |
Kind code of ref document: A1 Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KM KP KR KZ LC LK LR LS LT LU LV LY MA MD MG MK MN MW MX MZ NA NG NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SM SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW |
|
| AL | Designated countries for regional patents |
Kind code of ref document: A1 Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU LV MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG |
|
| 121 | Ep: the epo has been informed by wipo that ep was designated in this application | ||
| NENP | Non-entry into the national phase |
Ref country code: DE |
|
| 122 | Ep: pct application non-entry in european phase |
Ref document number: 05808040 Country of ref document: EP Kind code of ref document: A1 |