WO2006063911A1 - Procede de positionnement de donnees elementaires d'une structure de donnees dans une memoire - Google Patents

Procede de positionnement de donnees elementaires d'une structure de donnees dans une memoire Download PDF

Info

Publication number
WO2006063911A1
WO2006063911A1 PCT/EP2005/055966 EP2005055966W WO2006063911A1 WO 2006063911 A1 WO2006063911 A1 WO 2006063911A1 EP 2005055966 W EP2005055966 W EP 2005055966W WO 2006063911 A1 WO2006063911 A1 WO 2006063911A1
Authority
WO
WIPO (PCT)
Prior art keywords
memory
data
size
bytes
class
Prior art date
Application number
PCT/EP2005/055966
Other languages
English (en)
Inventor
Laurent Lagosanto
Antoine Requet
Jean-Jacques Vandewalle
Original Assignee
Gemplus
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Gemplus filed Critical Gemplus
Publication of WO2006063911A1 publication Critical patent/WO2006063911A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/0223—User address space allocation, e.g. contiguous or non contiguous base addressing
    • G06F12/023—Free address space management
    • G06F12/0238—Memory management in non-volatile memory, e.g. resistive RAM or ferroelectric memory

Definitions

  • the present invention relates to embedded software and execution environments in a portable electronic device with a microcontroller uniting a processor and memories, such as a smart card for example.
  • the invention relates to a method for positioning elementary data of a data structure in a memory.
  • data structures representing an organization of the elementary data of a code in a particular logical structure are used. These data structures are then intended to be allocated in memory, that is to say a memory area is reserved to store this data structure, during loading and installation of the code in memory by the environment execution.
  • the software code itself does not contain information on how to place the elementary data of the structure in memory (order, disposition), but generally provides information on the type and size of this data.
  • the elementary data is typically encoded on either 1 byte, 2 bytes, or multiple 4 bytes.
  • the one-byte data can be set to any memory address, whereas the double-byte data can only be set to a memory address that is multiple of 2, and the data encoded in multiples of four Bytes can only be set to a memory address that is a multiple of 4.
  • a Java software is conventionally distributed in the form of a set of modules consisting of .class files. These files correspond to a compiled form of the software. Each compiled file corresponds to a data structure of class type and comprises as such the description of the elements of the class, in particular its fields, which constitute in this context the elementary data to be placed in memory for the execution of the pseudo-Java code.
  • the virtual machine loader is then provided to load and transform the information in the .Class file into work memory data structures, which are specific to the virtual machine and allow this virtual machine to run the software.
  • the optimal size of the instances of the class is equal to the sum of the size of each of its fields, ie 7 bytes for the instances of the class ⁇ C.
  • FIG. 1 illustrates a zone 10 in a 32-bit memory structure, as it arises at the end of a process for storing the fields of the pseudo-code under consideration, where each field is placed at the following the other, taking into account the alignment constraints described above.
  • the field bl, encoded on 1 byte is positioned at the memory address 0
  • the field it, coded on 4 bytes is necessarily positioned at the memory address 4 because of the constraints of alignment of the processor, and the field if, coded on 2 bytes, is then positioned at the memory address 8.
  • FIG. 2 A solution for optimizing the occupation of the memory during the positioning of the fields of a class data structure class was then developed and is presented in Figure 2.
  • This solution consists in establishing a memory card 20, allowing to memorize for each address of the memory 10, whether it is occupied or not. Initially, all the bits of the card of which initialized to 0. According to this method, the first field bl, coded on 1 byte, is positioned at the memory address 0 and the corresponding bit of the memory card for this byte is then placed to 1, indicating that this byte is now busy.
  • mapping of the memory must be kept in memory.
  • the virtual machine when the virtual machine receives a child class from an already treated parent class, it must take into account, for the calculation of the positioning of the fields of the child class, the position of the fields of the mother class: they also exist in the girl class and are positioned in the same place.
  • the aim of the invention is to solve one or more of these disadvantages, by proposing a method making it possible to obtain optimal positioning in memory of elementary data of a data structure, while being efficient in terms of memory consumption and time of storage. calculation.
  • the invention thus relates to a method for positioning elementary data of a data structure in a memory organized in words of at least four bytes, comprising, depending on the size of the next data to be positioned, the determination of the position to allocate in memory to said elementary data item according to a description of said structure in memory, and updating said description of said structure in memory, characterized in that said description is based on at least three indices respectively indicating the next available memory location for placing one byte size data, the next available memory location for placing two byte size data, and the next available memory location for placing a data size of at least three bytes.
  • the determination of the position in memory of the elementary data item to be set according to the description of the data structure in memory consists in assigning to said position the current value of the index corresponding to the size of the data element. the given data.
  • the update of the description of the data structure in memory consists in assigning new values to said indices as a function of their relative positions, so that said updated values respectively describe the new position in the smallest available memory where a next elementary data of size one byte, two bytes, or at least three bytes can be positioned.
  • the method according to the invention is advantageously applied to the positioning in memory of the fields of a class of a software code compiled into an object-oriented intermediate language, the class possibly being a class inheriting from another class.
  • the method according to the invention also advantageously applies to the positioning in memory in an execution stack of variables of a set of local variables of a function.
  • the invention also relates to a charger for a software code compiled into an object-oriented intermediate language intended to be loaded into a portable electronic device, characterized in that it is capable of being stored in a non-volatile memory of the device for the implementation of the method according to the invention.
  • the invention also relates to a portable electronic device comprising a non-volatile memory storing the charger as just described.
  • this device is a smart card.
  • FIG. 1 is a schematic representation of a memory zone in a 32-bit memory structure, in which the fields of a class have been positioned according to a method of the prior art
  • FIG. 2 is a schematic representation of said memory zone, in which the fields of a class have been positioned according to an optimized method of the prior art
  • - Figure 3 is a flowchart illustrating the implementation of the method according to the present invention.
  • the method for positioning elementary data of a data structure in memory is based on a particular description of the structure in memory. This description is based on the calculation and updating of three indices, v1, v2 and v4, instead of keeping in memory the memory card of the solution of the prior art described above.
  • the indices v1, v2 and v4 are provided to respectively describe the next position or available memory address (and therefore well aligned) where a data coded on 1 byte can be placed, the next available memory address where a data coded on 2 bytes can be placed and the next available memory address where a data coded on 3 bytes, 4 bytes or more (in this case, one will round the size of the data to the multiple of 4 superior) could be placed. Because of the alignment constraints, data encoded on 3, 4, 5 bytes and more can be aligned only in multiples of 4 in memory address.
  • the three indices v1, v2 and v4 required for the implementation of the positioning method according to the invention can for example be coded each on 2 or 4 bytes. They then occupy a maximum of 6 or 12 bytes in memory. The use of such indices therefore has the advantage of consuming only a fixed amount of memory, independent of the size of the memory structure to be described.
  • FIG. 3 illustrates the implementation of the method of the invention based on the use of the three indices v1, v2 and v4.
  • the indices are initialized to zero if we are addressing the beginning of the data structure, otherwise the indices are initialized with the structure start address in the memory.
  • the initialization of the indices only occurs the first time that we have to position an elementary datum in the structure. Subsequently, the indices retain their current values as the data structure evolves in memory.
  • the three indices are thus updated so that they each correspond to the newest available small memory address where a next datum respectively of size 1, 2, or multiple of 4 bytes can be positioned.
  • This updating of the indices is advantageously deduced from a simple analysis of their relative positions. Similar to what has just been described for a data item of size 1, if, in E9, the next data to be placed is of size 2 bytes, the position Res which is allocated in ElO to this data in memory is given, according to the principle of the invention, by the current value of the index v2.
  • the position allocated to a data item of size 2 in memory is in fact determined by the current value of the index corresponding to the size of the data item, namely in this case, v2.
  • the placement Res which is allocated in E17 to this piece of data in memory is given, according to the principle of the invention, by the current value of the index v4. It should be noted that if the size of the data considered is greater than 4 bytes, its size will be rounded up for index positioning and update calculations to the multiple of 4 immediately greater than or equal to
  • the new value nv4 is updated to E18 and takes the current value v4 to which is added the size of the data considered, rounded to the multiple value of 4 immediately greater than or equal to.
  • the new value nvl of the index vl updated takes the new value nv2 of index v2, otherwise, in E24, the new value nvl of index vl updated keep the current value vl.
  • the method of the invention simply needs as input the size of the next elementary data element of the data structure to be placed in the memory and the description of this structure in memory, which is provided by the three indices v1, v2 and v4, respectively indicating the next available memory address and well aligned to place a data of size 1, the next available memory address and aligned well to place a data of size 2 and the next memory address available and well aligned to place a data multiple size of 4. Then we obtain the position in memory
  • the method for positioning a piece of data in memory based on the three indices v1, v2 and v4, which has just been described, is more particularly intended to respond to the alignment constraints inherent to 32 bit type memory structures, where the Memory word size is therefore 4 bytes.
  • the alignment rules require that the 1-byte data can be positioned only at addresses that are multiples of 1, the data of 2 bytes can only be set to multiple addresses of 2, the 3 and 4 byte data can only be set at multiple addresses of 4 and the other size data can only be set at multiple addresses of 8.
  • 4 indices to be able to fully describe the structure in memory and modify accordingly the updating rules of the indices in the algorithm described in FIG.
  • the method of positioning data in memory according to the invention is intended to apply to all the execution environments where the memory must be organized and to store elementary data of variable sizes in the memory in an optimized manner. terms of memory occupancy, taking into account hardware alignment constraints.
  • the method according to the invention is applicable to the calculation of the positioning of the fields of a data structure in general and, for example, to the computation of the positioning of the fields of a class of a software code compiled into intermediate oriented language. object, when loading the class into working memory by a loader of an embedded virtual machine.
  • the method of the invention is more particularly advantageous in the case where the class to be loaded is a class that inherits from another class.
  • the virtual machine receives a child class from a parent class already processed, it must take into account, for the calculation of the positioning of the fields of the child class, the position of the fields of the mother class whose daughter class inherits .
  • the three indices vl, v2 and v4 already used when calculating the positioning of the parent class fields are added to the class information, so that they can be reused to calculate the positions of the child class fields when it is loaded, which are then added to the fields of the mother class already positioned.
  • the method of the invention thus typically applies to the Java Card (registered trademark) or .Net (registered trademark) platform.
  • another application of the method according to the invention relates to the positioning of a set of local variables of a function in an execution stack, this set of local variables forming a data structure. Indeed, in the same way that each field is assigned a position in a class instance in memory, the local variables of a function stored in the stack must be assigned a position relative to the position of the stack at the same time. input of the function.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

L'invention concerne un procédé de positionnement de données élémentaires (b1, i1, s1) d'une structure de données dans une mémoire organisée en mots d'au moins quatre octets, comprenant, suivant la taille de la prochaine donnée à positionner, la détermination de la position (Res) à affecter en mémoire à ladite donnée élémentaire en fonction d'une description de ladite structure en mémoire, et la mise à jour de ladite description de ladite structure en mémoire, caractérisé en ce que ladite description est basée sur au moins trois indices (v1, v2, v4) indiquant respectivement la prochaine position en mémoire disponible pour placer une donnée de taille un octet, la prochaine position en mémoire disponible pour placer une donnée de taille deux octets et la prochaine position en mémoire disponible pour placer une donnée de taille au moins trois octets.

Description

PROCEDE DE POSITIONNEMENT DE DONNEES ELEMENTAIRES D'UNE STRUCTURE DE DONNEES DANS UNE MEMOIRE
La présente invention porte sur les logiciels et environnements d'exécution embarqués dans un appareil électronique portatif doté d'un microcontrôleur réunissant un processeur et des mémoires, tel qu'une carte à puce par exemple.
Plus particulièrement, l'invention concerne un procédé de positionnement de données élémentaires d'une structure de données dans une mémoire.
On utilise en effet, pour organiser le contenu d'une mémoire, des structures de données représentant une organisation des données élémentaires d'un code dans une structure logique particulière. Ces structures de données sont alors prévues pour être allouées en mémoire, c'est-à-dire qu'une zone mémoire est réservée pour stocker cette structure de données, lors du chargement et de l'installation du code en mémoire par l'environnement d'exécution.
Le code logiciel en lui-même ne contient pas d' information sur la façon de placer les données élémentaires de la structure en mémoire (ordre, disposition) , mais fournit généralement des informations sur le type et la taille de ces données . Les données élémentaires sont typiquement codées soit sur 1 octet, soit sur 2 octets, soit sur des multiples 4 octets. Lors de l'affectation des données élémentaires d'une structure de données en mémoire, il est nécessaire de respecter les contraintes d'alignement pour la représentation des données en mémoire, qui sont imposées par l'architecture matérielle du processeur. Ainsi, les données codées sur un octet peuvent être positionnées à n'importe quelle adresse mémoire, alors que les données codées sur deux octets ne peuvent être positionnées qu'à une adresse mémoire multiple de 2, et les données codées sur des multiples de quatre octets ne peuvent être positionnées qu'à une adresse mémoire multiple de 4.
Aujourd'hui, les architectures matérielles reposent principalement sur l'adressage de mémoire 32 bits, la taille des mots mémoire étant alors limitée à 4 octets. La description qui suit sera faite en référence à cette taille de mot mémoire bien que l'invention ne se limite pas à de telles structures de mémoire.
Plusieurs approches classiques peuvent alors être envisagées pour calculer le positionnement de données élémentaires d'une structure de données en mémoire. Les exemples ci-après sont basés sur une structure de données de type classe et vont ainsi décrire le chargement d'une classe par une machine virtuelle embarquée, qui constitue l'interface permettant de traduire en instructions exécutables par le processeur de l'appareil hôte, 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.
Pour rappel, un logiciel Java est classiquement diffusé sous forme d'un ensemble de modules constitué de fichiers .class. Ces fichiers correspondent donc à une forme compilée du logiciel. Chaque fichier compilé correspond à une structure de données de type classe et comprend en tant que telle la description des éléments de la classe, notamment ses champs, qui constituent dans ce contexte les données élémentaires à placer en mémoire pour l'exécution du pseudo-code Java.
Le chargeur de la machine virtuelle est alors prévu pour charger et transformer les informations du fichier .Class en des structures de données en mémoire de travail, qui sont propres à la machine virtuelle et qui permettent à cette machine virtuelle d'exécuter le logiciel.
Pour illustrer le processus de positionnement des champs d'une classe lors de son chargement dans une structure de mémoire selon l'état de la technique, soit le morceau de pseudo-code suivant, décrivant une classe comportant trois champs de tailles différentes.
Class C { //la classe est nommée ΛC
Byte bl ; //un champ nommé Λbl' de taille 1 octet Int il ; // un champ nommé Λil/ de taille 4 octets
Short si ; // un champ nommé Λsl' de taille 2 octets
} La taille optimale des instances de la classe est égale à la somme de la taille de chacun de ses champs, soit 7 octets pour les instances de la classe ΛC .
La figure 1 illustre une zone 10 dans une structure de mémoire 32 bits, telle qu'elle se présente à l'issue d'un processus de stockage des champs du pseudo-code considéré, où chaque champ est placé à la suite de l'autre, en tenant compte des contraintes d'alignement décrites plus haut. Ainsi, pour la classe ΛC considérée, le champ bl, codé sur 1 octet, est positionné à l'adresse mémoire 0, le champ il, codé sur 4 octets, est positionné nécessairement à l'adresse mémoire 4 du fait des contraintes d'alignement du processeur, et le champ si, codé sur 2 octets, est alors positionné à l'adresse mémoire 8.
Chaque champ de la classe occupe donc la même place en mémoire. On s'aperçoit que cette solution n'est pas du tout optimale en ce qui concerne la taille totale d'une instance de cette classe, qui dans cet exemple occupe 12 octets, alors que 5 octets restent inoccupés (octets apparaissant en blanc sur la figure) , correspondant à autant de place perdue en mémoire.
Une solution permettant d'optimiser l'occupation de la mémoire lors du positionnement des champs d'une structure de données type classe a alors été développée et est présentée à la figure 2. Cette solution consiste à établir une carte de la mémoire 20, permettant de mémoriser pour chaque adresse de la mémoire 10, si elle est occupée ou non. Au départ, tous les bits de la carte dont initialisés à 0. Selon cette méthode, le premier champ bl, codé sur 1 octet, est positionné à l'adresse mémoire 0 et le bit correspondant de la carte mémoire pour cet octet est alors placé à 1, indiquant que cet octet est désormais occupé.
Pour positionner le champ suivant il, codé sur 4 octets, on va parcourir la carte mémoire depuis son début jusqu'à trouver le prochain emplacement bien aligné (c'est-à-dire à une adresse multiple de 4), de taille 4 octets, qui soit disponible. En conséquence, le champ il est positionné à l'adresse mémoire de départ 4 et la carte mémoire est mise à jour. Pour ce faire, les bits correspondant de la carte mémoire pour les octets des adresses mémoires 4 à 7 sont placés à 1, indiquant que ces octets sont désormais occupés.
Puis, pour positionner le champ suivant si, codé sur 2 octets, on va à nouveau parcourir la carte mémoire depuis son début jusqu'à trouver le prochain emplacement bien aligné (c'est-à-dire à une adresse multiple de 2), de taille 2 octets, qui soit disponible. Cet emplacement correspond aux adresses mémoires 2 et 3. Le champ si est alors positionné à l'adresse mémoire 2 et la carte mémoire est mise à jour. Pour ce faire, les bits correspondant de la carte mémoire pour les octets des adresses mémoires 4 à 7 sont placés à 1, indiquant que ces octets sont désormais occupés. La carte mémoire permet ainsi de fournir lors du processus de positionnement des champs, une description de la structure de données en mémoire.
On obtient alors un positionnement optimal des champs de la classe dans la zone mémoire qui lui est affectée. En effet, dans cet exemple les instances de la classe ΛC auraient une taille de 8 octets, et on a uniquement un octet de perdu au niveau de l'occupation de la mémoire pour une instance de cette classe.
Cette solution présente néanmoins deux inconvénients majeurs. Tout d'abord, elle est consommatrice en mémoire. En effet, elle nécessite, lors du calcul du placement des champs, de stocker la carte mémoire, cette dernière occupant une quantité de mémoire non négligeable, puisque proportionnelle à la taille de la structure de mémoire dont elle reproduit la cartographie. Cette méthode pourrait donc s'avérer inadaptée à une implémentation dans des environnements contraints en mémoire, tels que les cartes à puce par exemple, où une utilisation optimale de la ressource mémoire est une exigence forte.
En outre, dans ce même contexte, pour pouvoir assurer la notion d'héritage de classe, la cartographie de la mémoire doit être maintenue en mémoire. En effet, lorsque la machine virtuelle reçoit une classe fille d'une classe mère déjà traitée, elle doit tenir compte, pour le calcul du positionnement des champs de la classe fille, de la position des champs de la classe mère : ils existent aussi dans la classe fille et sont positionnés au même endroit.
Un autre inconvénient de cette solution concerne l'inefficacité en termes de temps d'exécution du calcul de positionnement des champs. En effet, cette méthode impose de parcourir la carte mémoire depuis son début autant de fois qu'il y a de champs à placer dans la structure mémoire. Ce processus peut devenir fortement pénalisant en présence d'un grand nombre de champs à placer, notamment dans les environnements embarquées, disposant généralement de faibles ressources de calcul.
L'invention vise à résoudre un ou plusieurs de ces inconvénients, en proposant un procédé permettant d'obtenir un positionnement optimal en mémoire de données élémentaires d'une structure de données, tout en étant efficace en termes de consommation de mémoire et de temps de calcul. L'invention a ainsi pour objet un procédé de positionnement de données élémentaires d'une structure de données dans une mémoire organisée en mots d'au moins quatre octets, comprenant, suivant la taille de la prochaine donnée à positionner, la détermination de la position à affecter en mémoire à ladite donnée élémentaire en fonction d'une description de ladite structure en mémoire, et la mise à jour de ladite description de ladite structure en mémoire, caractérisé en ce que ladite description est basée sur au moins trois indices indiquant respectivement la prochaine position en mémoire disponible pour placer une donnée de taille un octet, la prochaine position en mémoire disponible pour placer une donnée de taille deux octets et la prochaine position en mémoire disponible pour placer une donnée de taille au moins trois octets.
Selon un mode de réalisation, la détermination de la position en mémoire de la donnée élémentaire à positionner en fonction de la description de la structure de données en mémoire, consiste à affecter à ladite position la valeur courante de l'indice correspondant à la taille de la donnée considérée.
Selon un mode de réalisation, la mise à jour de la description de la structure de données en mémoire consiste à affecter de nouvelles valeurs aux dits indices en fonction de leurs positions relatives, de sorte que lesdites valeurs mises à jour décrivent respectivement la nouvelle position en mémoire la plus petite disponible où une prochaine donnée élémentaire de taille un octet, deux octets, ou au moins trois octets pourra être positionnée. Le procédé selon l'invention s'applique avantageusement au positionnement en mémoire des champs d'une classe d'un code logiciel compilé en langage intermédiaire orienté objet, la classe pouvant être une classe héritant d'une autre classe.
Le procédé selon l'invention s'applique aussi avantageusement au positionnement en mémoire dans une pile d'exécution, des variables d'un ensemble de variables locales d'une fonction.
L'invention concerne également un chargeur d'un code logiciel compilé en langage intermédiaire orienté objet destiné à être chargé dans un appareil électronique 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 électronique 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 est une représentation schématique d'une zone mémoire dans une structure mémoire 32 bits, dans laquelle ont été positionnés les champs d'une classe selon un procédé de l'art antérieur ; - la figure 2 est une représentation schématique de ladite zone mémoire, dans laquelle ont été positionnés les champs d'une classe selon un procédé optimisée de l'art antérieur ; - la figure 3 est un organigramme illustrant la mise en oeuvre du procédé selon la présente invention.
Selon l'invention, le procédé de positionnement de données élémentaires d'une structure de données en mémoire est basé sur une description particulière de la structure en mémoire. Cette description repose sur le calcul et la mise à jour de trois indices, vl, v2 et v4, en lieu et place du maintient en mémoire de la carte de la mémoire de la solution de l'art antérieur décrite plus haut. Les indices vl, v2 et v4 sont prévus pour décrire respectivement la prochaine position ou adresse mémoire disponible (et donc bien alignée) où une donnée codée sur 1 octet pourra être placée, la prochaine adresse mémoire disponible où une donnée codée sur 2 octets pourra être placée et la prochaine adresse mémoire disponible où une donnée codée sur 3 octets, 4 octets ou plus (dans ce cas, on arrondira la taille de la donnée au multiple de 4 supérieur) pourra être placée. Du fait des contraintes d'alignement, des données codées sur 3, 4, 5 octets et plus ne peuvent être alignées que sur des multiples de 4 en adresse mémoire.
Les trois indices vl, v2 et v4 nécessaires à la mise en œuvre du procédé de positionnement selon l'invention, peuvent par exemple être codés chacun sur 2 ou 4 octets. Ils occupent alors au maximum 6 ou 12 octets en mémoire. L'utilisation de tels indices présente donc l'avantage de ne consommer qu'une quantité fixe de mémoire, indépendante de la taille de la structure de mémoire à décrire.
L'organigramme de la figure 3 illustre la mise en œuvre du procédé de l'invention basé sur l'utilisation des trois indices vl, v2 et v4.
Soient des données élémentaires d'une structure de données de tailles 1, 2 et multiples de 4 octets à positionner en mémoire. Les trois indices vl, v2 et v4 sont initialisés à zéro au début du processus et on donne en entrée la taille de la prochaine donnée à positionner en mémoire.
Plus précisément, on initialise les indices à zéro si on est en adressage relativement au début de la structure de données, sinon les indices sont initialisés avec l'adresse de début de structure dans la mémoire. L'initialisation des indices n'intervient que la première fois où l'on a à positionner une donnée élémentaire dans la structure. Par la suite, les indices conservent leurs valeurs courantes au fur et à mesure de l'évolution de la structure de données en mémoire.
En El, on regarde si la taille de la donnée est égale à 1. Dans cette hypothèse, en E2, la position (nommée « Res ») qui est allouée à cette donnée en mémoire est donnée par la valeur courante de l'indice vl . La position des données en mémoire est en effet déterminée par la valeur courante de l'indice correspondant à la taille de la donnée considérée. Les valeurs des trois indices doivent alors être mises à jour selon le processus suivant. En E3, on regarde si vl est égal à v2. Si ce n'est pas le cas, on passe en E4 où la nouvelle valeur de l'indice vl mise à jour, nommée nvl, prend la valeur courante v2, la nouvelle valeur de l'indice v2 mise à jour, nommée nv2, reste égale à la valeur courante v2, et la nouvelle valeur de l'indice v4 mise à jour, nommée nv4, reste égale à la valeur courante v4.
Par contre, dans le cas où l'égalité testée en E3 est vérifiée, on passe en E5, où la valeur de l'indice vl est mise à jour. Cette nouvelle valeur nvl de l'indice vl mise à jour prend dans ce cas la valeur vl+1. Pour la mise à jour des valeurs des autres indices v2 et v4, on regarde alors en E6 si v2 est égal à v4. Si ce n'est pas le cas, on passe en E7, où la nouvelle valeur nv2 de l'indice v2 mise à jour prend la valeur courante v4, et la nouvelle valeur nv4 de l'indice v4 mise à jour, reste égale à la valeur courante v4. Par contre, dans le cas où l'égalité testée en E6 est vérifiée, on passe en E8, où dans ce cas, la nouvelle valeur nv4 de l'indice v4 mise à jour prend la valeur v4+4, et la nouvelle valeur nv2 de l'indice v2 mise à jour prend la valeur v2+2.
Les trois indices sont donc mis à jour de sorte qu'ils correspondent chacun à la nouvelle adresse mémoire la plus petite disponible où une prochaine donnée respectivement de taille 1, 2, ou multiple de 4 octets pourra être positionnée. Cette mise à jour des indices est avantageusement déduite d'une simple analyse de leurs positions relatives. De façon similaire à ce qui vient d'être décrit pour une donnée de taille 1, si, en E9, la prochaine donnée à placer est de taille 2 octets, la position Res qui est allouée en ElO à cette donnée en mémoire est donnée, selon le principe de l'invention, par la valeur courante de l'indice v2. La position allouée à une donnée de taille 2 en mémoire est en effet déterminée par la valeur courante de l'indice correspondant à la taille de la donnée considérée, à savoir dans ce cas, v2.
Une fois le positionnement de la donnée considérée déterminée, les valeurs des trois indices vl, v2 et v4 doivent alors être mises à jour.
Pour ce faire, on regarde en ElI si v2 est égal à v4. Si ce n'est pas le cas, on passe en E12, où la nouvelle valeur nv2 de l'indice v2 mise à jour prend la valeur courante v4, et la nouvelle valeur nv4 de l'indice v4 mise à jour, reste égale à la valeur courante v4. Par contre, dans le cas où l'égalité testée en ElI est vérifiée, on passe en E13, où dans ce cas, la nouvelle valeur nv4 de l'indice v4 mise à jour prend la valeur v2+4, et la nouvelle valeur nv2 de l'indice v2 mise à jour prend la valeur v2+2.
Pour ce qui est de la mise à jour de l'indice vl, on passe en E14, où on vérifie l'égalité vl = v2. Si c'est le cas, en E15, la nouvelle valeur nvl de l'indice vl mise à jour prend la valeur nv2 de l'indice v2 qui vient d'être mis à jour, sinon, en E16, la nouvelle valeur nvl de l'indice vl mise à jour garde la valeur courante vl .
Enfin, si la prochaine donnée à placer a une taille de 3 octets ou plus, le placement Res qui est allouée en E17 à cette donnée en mémoire est donnée, selon le principe de l'invention, par la valeur courante de l'indice v4. Il convient de noter que si la taille de la donnée considérée est supérieure à 4 octets, on arrondira sa taille pour les calculs de positionnement et de mise à jour des indices à la valeur multiple de 4 immédiatement supérieure ou égale
(ainsi, une donnée codée sur 3 octets verra sa taille arrondie à 4 octets, une donnée codée sur 4 octets verra sa taille demeurée à 4 octets, une donnée codée sur 5 ou 6 ou 7 ou 8 octets verra sa taille arrondie à 8 octets, etc. ) .
Ainsi, la nouvelle valeur nv4 est mise à jour en E18 et prend la valeur courante v4 à laquelle on ajoute la taille de la donnée considérée, arrondie à la valeur multiple de 4 immédiatement supérieure ou égale.
Pour ce qui est de la mise à jour des indices vl et v2, on passe en E19, où on vérifie l'égalité v4 = v2. Si les deux indices v4 et v2 ont des valeurs différentes, la mise à jour est effectuée de la façon suivante en E20 où la nouvelle valeur nv2 mise à jour demeure inchangée et garde la valeur courante v2, et la nouvelle valeur nvl mise à jour demeure inchangée et garde la valeur courante vl . Par contre, si l'égalité en E19 est vérifiée, la nouvelle valeur nv2 de l'indice v2 est mise à jour en E21 et prend la valeur nv4 qui vient d'être mis à jour. Puis, la mise à jour de l'indice vl consiste à vérifier en E22 l'égalité vl=v2. Si c'est le cas, en E23, la nouvelle valeur nvl de l'indice vl mise à jour prend la nouvelle valeur nv2 de l'indice v2, sinon, en E24, la nouvelle valeur nvl de l'indice vl mise à jour garde la valeur courante vl . Ainsi, le procédé de l'invention a simplement besoin en entrée de la taille de la prochaine donnée élémentaire de la structure de données à placer dans la mémoire et de la description de cette structure en mémoire, qui est fournie par les trois indices vl, v2 et v4, indiquant respectivement la prochaine adresse mémoire disponible et bien alignée pour placer une donnée de taille 1, la prochaine adresse mémoire disponible et bien alignée pour placer une donnée de taille 2 et la prochaine adresse mémoire disponible et bien alignée pour placer une donnée de taille multiple de 4. On obtient alors en sortie la position en mémoire
(Res) qui doit être allouée à la donnée à placer et la description mise à jour de la structure en mémoire, qui est déduite d'une simple analyse des positions relatives des indices .
Le procédé de positionnement d'une donnée en mémoire basé sur les trois indices vl, v2 et v4, qui vient d'être décrit est plus particulièrement prévu pour répondre aux contraintes d'alignement inhérentes aux structures de mémoires de type 32 bits, où la taille des mots mémoire est donc de 4 octets . Toutefois, il pourrait être envisagé, sans pour autant sortir du cadre de l'invention, d'utiliser plus d'indices si les contraintes d'alignement matériel étaient différentes. Cela pourra être le cas par exemple avec une mémoire organisée en mots de 8 octets (64 bits) où les règles d'alignement imposent que les données de 1 octet ne peuvent être positionnées qu'à des adresses multiples de 1, les données de 2 octets ne peuvent être positionnées qu'à des adresses multiples de 2, les données de 3 et 4 octets ne peuvent être positionnées qu'à des adresses multiples de 4 et les données de taille autre ne peuvent être positionnées qu'à des adresses multiples de 8. Dans cet exemple, il faudrait alors prévoir 4 indices pour pouvoir décrire complètement la structure en mémoire et modifier en conséquence les règles de mise à jour des indices dans l'algorithme décrit en figure 3.
De manière générale, le procédé de positionnement de données en mémoire selon l'invention est prévu pour s'appliquer à tous les environnements d'exécution où il faut organiser la mémoire et stocker des données élémentaires de tailles variables dans la mémoire de façon optimisée en termes d'occupation de la mémoire, en tenant compte des contraintes d'alignement matériel.
Ainsi, le procédé selon l'invention s'applique au calcul du positionnement des champs d'une structure de données en général et, par exemple, au calcul du positionnement des champs d'une classe d'un code logiciel compilé en langage intermédiaire orienté objet, lors du chargement de la classe en mémoire de travail par un chargeur d'une machine virtuelle embarquée. Le procédé de l'invention est de plus particulièrement avantageux dans le cas où la classe à charger est une classe qui hérite d'une autre classe. En effet, lorsque la machine virtuelle reçoit une classe fille d'une classe mère déjà traitée, elle doit tenir compte, pour le calcul du positionnement des champs de la classe fille, de la position des champs de la classe mère dont la classe fille hérite. A cet effet, les trois indices vl, v2 et v4 déjà utilisés lors du calcul du positionnement des champs de la classe mère sont ajoutés à l'information de la classe, de sorte qu'ils peuvent être réutilisés pour calculer les positions des champs de la classe fille lors de son chargement, qui sont alors ajoutés aux champs de la classe mère déjà positionnés.
Le procédé de l'invention s'applique ainsi typiquement à la plate-forme Java Card (marque déposée) ou .Net (marque déposée) . Egalement, une autre application du procédé selon l'invention concerne le positionnement d'un ensemble de variables locales d'une fonction dans une pile d'exécution, cet ensemble de variables locales formant une structure de données. En effet, de la même manière que chaque champ se voit affecter une position dans une instance de classe en mémoire, les variables locales d'une fonction stockées dans la pile doivent se voir affecter une position par rapport à la position de la pile à l'entrée de la fonction.

Claims

REVENDICATIONS
1. Procédé de positionnement de données élémentaires (bl, il, si) d'une structure de données dans une mémoire organisée en mots d'au moins quatre octets, comprenant, suivant la taille de la prochaine donnée à positionner, la détermination de la position
(Res) à affecter en mémoire à ladite donnée élémentaire en fonction d'une description de ladite structure en mémoire, et la mise à jour de ladite description de ladite structure en mémoire, caractérisé en ce que ladite description est basée sur au moins trois indices
(vl, v2, v4) indiquant respectivement la prochaine position en mémoire disponible pour placer une donnée de taille un octet, la prochaine position en mémoire disponible pour placer une donnée de taille deux octets et la prochaine position en mémoire disponible pour placer une donnée de taille au moins trois octets.
2. Procédé selon la revendication 1, caractérisé en ce que la détermination de la position en mémoire de la donnée élémentaire à placer en fonction de la description de la structure de données en mémoire, consiste à affecter à ladite position (Res) la valeur courante de l'indice (vl, v2, v4) correspondant à la taille de la donnée considérée.
3. Procédé selon la revendication 1 ou 2, caractérisé en ce que la mise à jour de la description de la structure de données en mémoire consiste à affecter de nouvelles valeurs aux dits indices (vl, v2, v4) en fonction de leurs positions relatives, de sorte que lesdites valeurs mises à jour (nvl, nv2, nv4) décrivent respectivement la nouvelle position en mémoire la plus petite disponible où une prochaine donnée élémentaire de taille un octet, deux octets, ou au moins trois octets pourra être positionnée.
4. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il consiste à positionner en mémoire des champs d'une classe d'un code logiciel compilé en langage intermédiaire orienté objet.
5. Procédé selon la revendication 4, caractérisé en ce la classe est une classe héritant d'une autre classe.
6. Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce qu'il consiste à positionner en mémoire dans une pile d'exécution, des variables d'un ensemble de variables locales d'une fonction.
7. Chargeur d'un code logiciel compilé en langage intermédiaire orienté objet destiné à être chargé dans un appareil électronique 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 l'une quelconque des revendications 1 à 5.
8. Appareil électronique portatif comprenant une mémoire non volatile mémorisant le chargeur de la revendication 7.
9. Appareil selon la revendication 8, caractérisé en ce que cet appareil est une carte à puce.
PCT/EP2005/055966 2004-12-14 2005-11-14 Procede de positionnement de donnees elementaires d'une structure de donnees dans une memoire WO2006063911A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0413294 2004-12-14
FR0413294A FR2879319B1 (fr) 2004-12-14 2004-12-14 Procede de positionnement de donnees elementaires d'une structure de donnees dans une memoire

Publications (1)

Publication Number Publication Date
WO2006063911A1 true WO2006063911A1 (fr) 2006-06-22

Family

ID=34952588

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2005/055966 WO2006063911A1 (fr) 2004-12-14 2005-11-14 Procede de positionnement de donnees elementaires d'une structure de donnees dans une memoire

Country Status (2)

Country Link
FR (1) FR2879319B1 (fr)
WO (1) WO2006063911A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102009036095A1 (de) * 2009-08-04 2011-02-10 Giesecke & Devrient Gmbh Verfahren zum Verwalten von Speicherressourcen in einem portablen Datenträger

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5623654A (en) * 1994-08-31 1997-04-22 Texas Instruments Incorporated Fast fragmentation free memory manager using multiple free block size access table for a free list
WO2001016759A1 (fr) * 1999-08-31 2001-03-08 Cryptec Systems, Inc. Systeme et procede de gestion de memoire de carte a puce

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5623654A (en) * 1994-08-31 1997-04-22 Texas Instruments Incorporated Fast fragmentation free memory manager using multiple free block size access table for a free list
WO2001016759A1 (fr) * 1999-08-31 2001-03-08 Cryptec Systems, Inc. Systeme et procede de gestion de memoire de carte a puce

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
LINDBLAD J: "Handling memory fragmentation", EDN ELECTRICAL DESIGN NEWS, REED BUSINESS INFORMATION, HIGHLANDS RANCH, CO, US, May 2004 (2004-05-01), pages 47 - 48,50, XP002338069, ISSN: 0012-7515 *
SHUF Y ET AL: "Creating and preserving locality of Java applications at allocation and garbage collection times", PROCEEDINGS OF THE ACM OOPSLA CONFERENCE, XX, XX, 4 November 2002 (2002-11-04), pages 13 - 25, XP002338073 *
WILSON P R ET AL: "Dynamic Storage Allocation: A Survey and Critical Review", MEMORY MANAGEMENT. INTERNATIONAL WORKSHOP IWMM. PROCEEDINGS, 1995, pages 1 - 78, XP002262845 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102009036095A1 (de) * 2009-08-04 2011-02-10 Giesecke & Devrient Gmbh Verfahren zum Verwalten von Speicherressourcen in einem portablen Datenträger

Also Published As

Publication number Publication date
FR2879319A1 (fr) 2006-06-16
FR2879319B1 (fr) 2007-01-19

Similar Documents

Publication Publication Date Title
EP0421845B1 (fr) Procédé d'exploitation de la mémoire dans un système informatique du type à adressage virtuel et dispositif pour la mise en oeuvre dudit procédé
FR2787601A1 (fr) Systeme de memorisation comprenant des moyens de gestion d'une memoire avec anti-usure et procede de gestion anti-usure d'une memoire
WO2000028416A1 (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
US8818967B2 (en) Method for compressing identifiers
WO2013079885A1 (fr) Ecriture de donnees dans une memoire non volatile de carte a puce
EP1483673A1 (fr) Methode de stockage de blocs de donnees dans une memoire
FR2860894A1 (fr) Procede pour utiliser des indicateurs de fonction afin de determiner la compatibilite entre des revisions du bios et du materiel installe pendant une mise a jour de la memoire flash
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
FR2613851A1 (fr) Carte a circuits integres et procede pour y enregistrer des donnees
WO2006063911A1 (fr) Procede de positionnement de donnees elementaires d'une structure de donnees dans une memoire
CN110059135B (zh) 一种数据同步方法和装置
EP1585071B1 (fr) Partage de fichiers non divisibles
EP0838053A1 (fr) Procede et dispositif permettant a un programme fige de pouvoir evoluer
FR2825491A1 (fr) Procede d'implementation d'un pluralite d'interfaces d'objets
WO2006048378A1 (fr) Procede de chargement d'un code logiciel en langage intermediaire oriente objet dans un appareil portatif
EP1064596A1 (fr) Procede et systeme de collecte electronique de fonds
FR2775375A1 (fr) Chargement de programmes informatiques en blocs
CN116382707A (zh) 一种多应用集成方法及装置
EP0998807B1 (fr) Procede et dispositif de reception de messages numeriques
FR2808605A1 (fr) Procede et dispositif de transfert de donnees entre deux memoires
FR2829847A1 (fr) Procede de controle d'acces a des ressources partagees dans un systeme embarque et systeme embarque pour la mise en oeuvre d'un tel procede
FR2633744A1 (fr) Dispositif de memoire vive electronique
FR2662830A1 (fr) Procede de dialogue entre les processeurs d'un systeme, systeme pour sa mise en óoeuvre et utilisation pour la repartition des processus aux processeurs.
CN118012400A (zh) 针对程序的方法集合获取方法和装置

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 KN 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): 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: 05819121

Country of ref document: EP

Kind code of ref document: A1

WWW Wipo information: withdrawn in national office

Ref document number: 5819121

Country of ref document: EP