FR 2929729 A1 20091009 FR 0852231 A 20080403 L'invention concerne un dispositif de gestion de la mémoire comprenant au moins un processeur/coeur de processeur, au moins une mémoire et une unité de gestion de la mémoire (UGM) connectée à la fois à un ou plusieurs processeurs/coeurs de processeur et à une ou plusieurs mémoires, ainsi qu'éventuellement à un ou à plusieurs systèmes d'exploitation. L'invention concerne une unité de gestion de mémoire (UGM) intégrée au sein de ce dispositif ou environnement informatique. Le processeur est notamment agencé pour exécuter des applications et faire appel à différentes fonctions pour chaque application. Le processeur est en outre agencé pour donner des instructions d'allocation d'espace mémoire. Ces instructions sont typiquement une requête d'un espace mémoire qui peut être faite automatiquement ou semiautomatiquement. L'invention s'applique particulièrement à un environnement multitâches, dans lequel la mémoire est partitionnée en une pluralité de zones de mémoire allouées respectivement à une pluralité d'applications. Les applications peuvent ainsi travailler en parallèle en se partageant le même espace mémoire. Il est connu d'incorporer, dans un tel environnement, une unité de gestion de la mémoire (encore connue sous le nom de � MMU � pour � Memory Management Unit �) qui est un dispositif matériel permettant de réaliser cette gestion des zones de mémoire pour des applications différentes. Une MMU comprend généralement 2 parties : segmentation et pagination. La segmentation consiste à convertir d'abord une adresse virtuelle en adresse linéaire tandis que la pagination transforme une adresse linéaire en adresse physique. Ce mécanisme peut être au moins partiellement géré par le processeur. Lors de la segmentation, une MMU translate une adresse virtuelle en adresse linéaire grâce à une notion de segment et d'offset. Une MMU est configurée selon un système de pagination qui utilise un principe de translation apte à mettre en correspondance des pages de mémoire linéaire avec des pages de mémoire réelle afin de réaliser ladite traduction. Les pages ont chacune une taille (ou espace) mémoire bien déterminée. Le système de pagination est mis en oeuvre en partie par le système d'exploitation. La MMU gère ainsi une table de pages dont les entrées sont indicées, les indices correspondant à des références de pages linéaires. La MMU retrouve d'abord la page linéaire associée à l'adresse linéaire reçue, pour faire ensuite correspondre une page réelle. Les sorties de la table sont des adresses réelles de mémoire permettant d'allouer des zones mémoire. La MMU, via sa table, peut également comprendre des informations concernant l'état de la page (e.g. si des données y ont été écrites ou la dernière fois qu'elle a été utilisée) et gérer l'accès à la mémoire (e.g. mode utilisateur, mode administrateur par exemple). Une MMU permet donc non seulement de déterminer une zone mémoire réelle spécifique à chaque application, mais aussi de définir des permissions d'accès sur chaque zone mémoire. De façon générale, la MMU gère la mémoire avec une granularité d'une page. La MMU subdivise l'espace mémoire en pages qui deviennent l'unité de base, même si le besoin en mémoire est inférieur à une page entière. Il n'est pas possible de faire coïncider la taille d'une page avec la taille d'un tableau ou bien la taille d'une zone mémoire allouée dynamiquement (malloc en langage C). Plus précisément, dans les systèmes actuels, la mémoire virtuelle est manipulée par un seul champ variant de manière linéaire. A chaque adresse virtuelle correspond une adresse réelle grâce à un mécanisme d'indirections.30 Toutefois, avec ce type de gestion de la mémoire, des risques de débordement mémoire lors des accès en lecture ou écriture existent soit : - à l'intérieur même d'une application (une erreur ou bug informatique est présente dans cette application). Un cas classique est la corruption par une partie de l'application d'une zone mémoire utilisée par une autre partie de l'application; - soit entre plusieurs applications qui interagissent ensemble (cela peut se produire lors de l'appel à une librairie du système informatique, lorsqu'une application s'appuie sur une seconde application, ou bien lors de l'échange d'informations entre deux applications). Cette possibilité d'écrire ou lire de manière erronée en mémoire entraîne souvent soit une erreur dans une application (bug informatique), soit la propagation d'un virus, soit la prise de contrôle potentielle d'une machine par une personne malveillante. Ces problèmes peuvent devenir d'autant plus importants que les applications sont typiquement de plus en plus complexes, celles-ci faisant notamment appel à de plus en plus de fonctionnalités différentes. Il existe donc un besoin d'affiner les moyens de gérer la mémoire afin de résoudre ces problèmes. Pour pallier à ces problèmes, l'invention prévoit un dispositif comprenant une unité de gestion de mémoire (UGM), d'une part connectée et/ou intégrée à au moins un processeur ou coeur de processeur et d'autre part en communication avec une ou plusieurs mémoires, et éventuellement avec un ou plusieurs systèmes d'exploitations, caractérisé en ce que le ou les processeur(s) ou coeur de processeur(s) manipule la mémoire uniquement sous la forme d'une série de champs, tandis que l'unité de gestion mémoire, s'interfaçant entre premièrement le ou les processeurs/coeurs de processeurs et deuxièmement la ou les mémoires, fait la correspondance entre d'un coté cette série de champs adressant la mémoire coté processeur et de l'autre coté la mémoire physique. L'invention comprend également au moins l'une des caractéristiques suivantes : - l'unité de gestion de mémoire (UGM) est agencée pour diviser la mémoire dynamiquement en différents sous-ensembles de tailles variables indicés par un champ et chaque sous-ensemble pouvant être lui-même récursivement et dynamiquement subdivisé en de nouveaux sous-ensembles indicés par un champ additionnel ; - chaque sous-ensemble est délimité en mémoire par des bornes gérées par l'UGM, qui s'assure que tout accès mémoire à ce sous-ensemble respecte les bornes délimitées ; - chaque sous-ensemble est dimensionné avec une granularité aussi fine qu'une adresse mémoire ; - chaque sous-ensemble mémoire, tout en conservant la même série de champs le désignant, est déplacé par l'unité de gestion mémoire d'une partie de la mémoire vers une autre partie de la mémoire, et ceci de manière transparente pour le processeur, le système d'exploitation et les applications du système informatique ; - l'espace mémoire alloué à chaque sous-ensemble est agrandi ou rétréci sur demande par l'unité de gestion mémoire, tout en conservant la même série de champs le désignant ; - l'unité de gestion mémoire est agencée de sorte à différencier, en se basant sur l'identification par série de champs, un sous-ensemble mémoire contenant du code et un sous-ensemble mémoire contenant des données; - l'unité de gestion de mémoire comprend en outre des moyens pour gérer des droits d'accès en lecture, en écriture, en exécution et en interaction d'un sous-ensemble mémoire à un autre sous-ensemble mémoire en se basant sur l'identification des sous-ensembles par la série de champs ; - les moyens pour gérer les droits d'accès sont agencés pour autoriser un ou plusieurs accès à des zones mémoire, en lecture, en écriture et exécution ; - l'unité de gestion de mémoire est agencée de sorte à gérer l'espace mémoire en regroupant/déplaçant les sous-ensembles mémoire pour combler les espaces mémoires vides et pour éviter le fractionnement mémoire tout en rendant cette opération transparente au processeur/coeur de processeur, au système d'exploitation et aux logiciels ; - l'unité de gestion de mémoire est agencée pour allouer/désallouer un espace mémoire sur demande logicielle en gérant intégralement le processus d'allocation/désallocation et sans que ce processus ne fasse intervenir le processeur/coeur de processeur, le système d'exploitation ou les applications logicielles ; - l'unité de gestion de mémoire est agencée pour gérer la désignation d'un même sous-ensemble mémoire par deux séries de champs différentes ; - l'unité de gestion de mémoire est agencée pour séparer la mémoire en un premier espace mémoire composé par les zones mémoire utilisées et un deuxième espace mémoire vide, et le dispositif est apte à couper dynamiquement au moins une partie de l'alimentation électrique du deuxième espace mémoire ; - le processeur manipule et désigne toute adresse mémoire au travers d'une série de champs de telle sorte que chaque pointeur du processeur soit composé d'une série de champs dont l'un des champs contient l'index associé à une variable et/ou l'index associé à une fonction et/ou l'index associé à un processus au sens informatique du terme et/ou l'index associé à une classe au sens informatique du terme et/ou l'index associé à une méthode au sens informatique du terme et/ou l'index associé à une librairie au sens informatique du terme et/ou l'index associé à un système d'exploitation ; - le processeur manipule et désigne toute instruction à exécuter par une série de champs de telle sorte que l'un des champs contient l'index associé à une fonction au sens informatique du terme et/ou l'index associé à un processus au sens informatique du terme et/ou l'index associé à une classe au sens informatique du terme et/ou l'index associé à une méthode au sens informatique du terme et/ou l'index associé à une librairie au sens informatique du terme et/ou l'index associé à un système d'exploitation ; - le dispositif est agencé de telle sorte que l'unité de gestion mémoire inclut un mécanisme de pagination simplifié qui découpe la mémoire en pages et fait la translation de manière bijective entre les pages linéaires ou virtuelles utilisées, contenant la traduction de séries de champs en adresses, et les pages de mémoire physique utilisées ; - l'unité de gestion de mémoire fonctionne comme une machine d'état, dont l'exécution est autonome par rapport à tout autre programme d'ordinateur, y compris le cas échéant un système d'exploitation, la machine d'état étant réalisée de façon matérielle ou logicielle ou bien en partie de façon logicielle et en partie de façon matérielle ; - l'unité de gestion de mémoire est agencée pour qu'un programme d'ordinateur puisse être mis à jour par un utilisateur ; - l'unité de gestion mémoire est agencée de telle sorte que toute adresse mémoire manipulée par le processeur/coeur de processeur soit composée d'une série de champs qui segmentent dynamiquement la mémoire en une arborescence à plusieurs niveaux, et dont chaque niveau correspond à un champ de la série, de façon à ce que le premier champ divise dynamiquement la mémoire en différents sous-ensembles et que chacun des champs suivants divise dynamiquement le sous-ensemble désigné par les champs précédents en de nouveaux sous-ensembles ; - l'unité de gestion mémoire est agencée de telle sorte qu'elle gère la mémoire par un système de plusieurs niveaux de segmentation imbriqués les uns dans les autres. D'autres caractéristiques, buts et avantages de la présente invention apparaîtront à la lecture de la description détaillée qui va suivre, et en regard des dessins annexés, donnés à titre d'exemples non limitatifs et sur lesquels: - la figure 1 représente schématiquement différents éléments d'un environnement informatique selon l'invention ; - la figure 2 concerne, à titre d'exemple, la description de la gestion de la mémoire d'un processus ; - les figures 3a, 3b représentent une étape d'allocation d'un nouvel espace mémoire ; - les figures 4a, 4b, 4c représentent différentes étapes de réallocation des données afin de combler les espaces mémoires libérés ; - les figures 5a, 5b, 5c, 5d, 5e, 5f représentent différentes étapes de recopie des contenus pour réallouer un espace mémoire vide ; - les figures 6a et 6b représentent différentes étapes de réallocation d'un espace mémoire supprimé ; - les figures 7a, 7b et 7c représentent différentes étapes donnant une permission d'accès à la mémoire d'un processus par un autre processus. Dans ce document, la mémoire pourra contenir soit des données (comme par exemple des variables ou des tableaux manipulés par un processeur) ou bien du code (des instructions exécutées par un processeur). Dans les exemples ci-dessous, la mémoire sera définie par 3 champs. Pour les données, les champs sont les suivants: - Indice de l'application. - Indice de sous-ensemble de données. - Taille maximale du sous-ensemble de données. De même, le code peut être définit par 3 champs par symétrie : - Indice de l'application. - Indice de fonction. - Taille maximale de la fonction. Cette compartimentation est donnée à titre d'exemple, mais il reste possible de modifier la nature ainsi que le nombre de champs. La figure 1 est constituée de quatre éléments (ou blocks) formant les 10 éléments principaux de l'environnement informatique considéré. Un premier block 10 correspond au coeur du processeur. Le coeur du processeur manipule selon l'exemple considéré la mémoire en fonction des trois champs prédéfinis: processus, sous-ensemble (SE), offset à l'intérieur d'un sous-ensemble. 15 La mémoire n'est plus vue comme une grande plage d'adressage linéaire : les systèmes actuellement utilisés manipulent un champ unique. Chaque accès mémoire se fait au travers de l'UGM 30, et plus précisément par le premier étage de cette UGM, à savoir le block 31. Pour chaque accès mémoire, le processeur 10 envoie trois champs : processus, 20 sous-ensemble, et offset. L'UGM 30 gère en mémoire les bornes de chaque sous-ensemble : elle permet ainsi de reconstituer grâce au block 310 contenant la logique de contrôle les bornes en mémoire délimitant chaque sous-ensemble. La logique interne de ce block 310 reconstitue à partir des informations 25 contenues dans la série de champs l'adresse mémoire réelle correspondante à un sous-ensemble. Le superviseur 320 vérifie les droits d'accès à un sous-ensemble en lecture, écriture ou exécution. Ces bornes sont entièrement gérées par l'UGM et peuvent être mémorisées à l'intérieur même de l'UGM ou dans la mémoire externe. 30 Dans cet exemple, un block supplémentaire a été ajouté (Block 32 complémentant le block 30 de l'UGM) : il est constitué d'une MMU classique5 gérant la mémoire sous forme de page. Ce block 32 fait correspondre une adresse mémoire virtuelle à une adresse mémoire réelle. Ce second étage ou table de référencement 32 n'est pas indispensable mais permet de gagner en flexibilité lors de l'allocation/désallocation de mémoire lorsque plusieurs applications tournent en parallèle. Cette procédure permet d'attribuer chaque page à un processus défini permettant de créer virtuellement une 'colonne' de mémoire à chaque processus. Lors de la suppression d'un sous-ensemble mémoire dans une application, le processus de recopie des données, afin de combler le trou vide, se fait uniquement à l'intérieur de ce processus. Le processus de recopie ne touche donc pas à la mémoire des autres processus. Enfin, le block 20 correspond quant à lui à la mémoire physique stockant les données. Dans le cas illustré sur la figure 1, l'UGM 30 est réalisée de façon matérielle (solution préférentielle), mais celle-ci peut être également réalisée au moins en partie de manière logicielle. L'approche de l'invention permet d'affiner la représentation en mémoire par rapport aux représentations classiques, en travaillant non plus sur une granularité de page mémoire ayant une taille prédéfinie mais par l'intermédiaire de champs, définissant les zones mémoires avec exactement la dimension souhaitée. De plus un système classique attribue un espace mémoire à un processus et interdit à d'autres processus de s'immiscer dans cet espace mémoire. Mais rien n'interdit qu'une partie d'un processus corrompe dans un système classique l'espace mémoire utilisé par une autre partie de ce même processus. La figure 2 concerne un exemple de gestion de la mémoire d'un processus. Dans cet exemple, il existe cinq sous-ensembles mémoire (représentés par l'acronyme SE), à savoir les sous-ensembles 0, 1, 2, 3, et 4 qui sont représentés à l'état initial sur le tableau du haut. Chaque sous-ensemble possède une taille qui lui est propre. i0 Sur la seconde partie (étape 1), le sous-ensemble 3 est supprimé sur instruction du processeur 10. Ce sous-ensemble a une taille de 7 adresses mémoires (de l'adresse 10 à l'adresse 16 incluse). Afin d'éviter cette perte de mémoire par fragmentation, l'UGM 30 va combler petit à petit l'espace libre et recopie les données du sous-ensemble 4 dans l'espace libre (anciennement sous-ensemble 3). Le processus de recopie est pris en charge intégralement par l'UGM sans faire intervenir le processeur, le système d'exploitation ou l'application. Cette opération est gérée de façon autonome par l'UGM et reste transparente pour une application, un processeur ou bien un système d'exploitation : ils continuent de manipuler la mémoire à travers une série de champs et la position exacte des données en mémoire leur reste masquée. A la fin de la recopie (troisième partie, état final), l'adresse la plus haute utilisée en mémoire vaut 12 au lieu de 19 au début de l'opération. L'espace libéré par la suppression de ce sous-ensemble 3 est donc utilisable par une autre application. Bien entendu, l'invention n'est pas limitée à cet exemple comportant les champs : processus, sous-ensemble, offset (figure 2) ; une zone mémoire pouvant être définie par davantage de champs et/ou par des champs de nature différente. Une caractéristique importante de cette invention est que le processeur, l'application et le système d'exploitation n'ont connaissance de l'espace mémoire que par l'intermédiaire de ces champs (adressage virtuel). Seule l'UGM 30 est en mesure de faire le lien entre une zone mémoire manipulée par des champs et l'adresse physique en mémoire 20. L'UGM 30 prend donc entièrement en charge la translation entre d'un coté le ou les processeurs/coeurs de processeur, les applications et le ou les systèmes d'exploitation le cas échéant manipulant une série de champs virtuels et de l'autre coté le contenu physique (réel) de la mémoire. Cette représentation de la mémoire est préférentiellement réalisée de façon synchrone entre l'UGM 30 et le processeur 10. L'UGM 30 peut en particulier prendre en charge l'intégralité des allocations en mémoire sur simple demande du processeur, de façon indépendante de toute application exécutée et de tout système d'exploitation. Nous allons maintenant préciser un autre intérêt de l'invention. En effet, un programme informatique manipule des variables, ces variables étant de tailles inégales. Chaque variable occupe selon sa taille une certaine zone en mémoire. Ces variables sont rangées les unes à coté des autres. Il n'est pas possible de distinguer la séparation entre deux variables : une zone de 10 adresses mémoires peut correspondre à dix variables rangées les unes à coté des autres ou bien à un tableau de 10 éléments. Il est ainsi facile de corrompre la mémoire d'un programme en venant écrire une variable par erreur : aucune protection ne permet de s'en affranchir. Les MMU existantes permettent de paginer la mémoire, c'est-à-dire d'autoriser une application uniquement à accéder aux pages qui lui ont été attribuées, par contre à l'intérieur même de cette application aucun mécanisme de protection n'empêche une corruption mémoire ou un écrasement de variable à l'intérieur même d'une application. A cet effet, l'UGM 30 comprend l'utilisation d'une logique de contrôle 310 (de type matériel et/ou logiciel, ou bien en partie logicielle et en partie matérielle) apte à superviser dynamiquement l'exécution logicielle. Un exemple permettant de mieux appréhender une situation d'écrasement/corruption est présentée ci-dessous : Dans un environnement selon le langage C, une fonction intitulée � foo � est déclarée et écrite comme suit : 30 Int foo (int a, int * b, int j) { int tmp; int table[10]; int overflow; for (i=0; R a, i++) { table [i] = .... /*code*/ } /*code*/ return (tmp); } Ce code informatique est composé d'une fonction manipulant les variables suivantes : a, *b, j, tmp, i, table[10], overflow; Les variables manipulées sont de tailles variables (entre une adresse 20 mémoire et une dizaine d'adresses mémoires comme le tableau appelé table'). L'UGM manipule ces variables au travers des champs suivants : 25 Indice de processus : PO (Il s'agit du processus 0 dans cet exemple) ; Variable 'Int a' : Sous-ensemble 0, Taille maximale TO = 1 (une seule adresse mémoire réservée) ; Variable 'Int table [10]' : Sous-ensemble 4, Taille maximale T5 = 10 (10 adresses mémoires réservées) ; 12 30 Nom Indices Type de Taille donnée Int a P0, SEO, TO donnée 1 adresse mémoire Int * b P0, SE1, T1 donnée 1 adresse mémoire Int tmp P0, SE2, T3 donnée 1 adresse mémoire Int i P0, SE3, T4 donnée 1 adresse mémoire Int table[10] P0, SE4, T5 donnée 10 adresses mémoire Int overflow P0, SE5, T6 donnée 1 adresse mémoire Code de la P0, CO, TC0 Code/ Taille de la fonction fonction Foo instructions Foo 15 Tableau 1 En référence au tableau 1, où : • PO est l'indice représentant la fonction ou l'application considérée, • SEO, SE1, SE2, SE3, SE4, SE5 sont les indices représentant 20 respectivement les sous-ensembles de 6 contenus de données, • TO, T1, T2, T3, T4, T5 représentent le nombre d'adresses mémoires utilisées par chaque sous-ensemble. • CO est l'indice représentant le code de cette fonction et TCO représentant le nombre d'adresses mémoires utilisées par le code 25 de la fonction CO. Dans un dispositif classique, et en partant de l'hypothèse que ces variables sont rangées les consécutivement en mémoire, si la valeur de la variable � J � excède 10, la boucle sera exécutée plus de 10 fois et la 30 variable 'overflow' va être écrasée en étant abusivement considérée comme le 11ème élément du tableau. 10 Un des avantages premiers de la gestion mémoire par l'UGM 30 est de supprimer les risques d'écrasement mémoire (connus sous le nom de 'buffer overflow'): grâce à sa connaissance de la taille des variables manipulées (T5 dans cet exemple), l'UGM 30 prévient tout risque d'écrasement mémoire en détectant cette anomalie et retournant un signal d'erreur au processeur. Selon l'invention, appliquée au cas d'espèce (tableau 1), lors de l'exécution, le sous-ensemble � SE5 � étant limité par la taille � T5 � valant par déclaration 10, le mécanisme de bornes selon l'invention empêche l'écriture de la variable � overflow �. L'UGM 30 peut aussi comprendre d'autres fonctionnalités additionnelles. La logique de contrôle 310 peut fonctionner à partir d'une table d'exécution de sorte qu'à chaque sous-ensemble mémoire soit associé des règles d'exécution de son contenu. Par exemple, cette table d'exécution peut autoriser le code d'un sous- ensemble � code � à accéder uniquement en lecture ou en écriture seulement ou en lecture/écriture aux sous-ensembles � données �. Cet accès peut en supplément être limité à un certain nombre de fois (l'UGM 30 peut autoriser un sous-ensemble mémoire en lecture une et une seule fois seulement par exemple). Cette table d'exécution peut ainsi garantir que la fonction s'exécutera uniquement dans l'espace mémoire qui lui est réservé, puisque l'accès au code et aux données est entièrement maîtrisé par l'UGM 30. L'UGM 30 comprend ainsi des moyens pour gérer les droits d'accès à une zone mémoire allouée à des données, par le code de cette fonction et par les codes d'autres fonctions, et/ou les droits d'appel d'une fonction à une autre fonction. Cette gestion des droits s'appuie sur la notion de série de champs (spécifique à l'invention), définissant des sous-ensembles qui partitionnent la mémoire. Lors de l'exécution du programme de la fonction, l'UGM 30 vérifie lors de chaque accès d'un sous-ensemble contenant du code à un sous- ensemble contenant des données que cette transaction est autorisée. en écriture ou en lecture. Ainsi, en reprenant l'exemple ci-dessus, peut être associée à la fonction � foo � (notée � PO �), la table d'exécution suivante : - P0, CO, TO: La variable 'a' est uniquement lue (mais non écrite). Les variables 'b', 'tmp', 'j', 'table', 'overflow' sont à la fois écrites et lues. - P0, SEO, TO - P0, SE1, Tl - P0, SE2, T2 - P0, SE3, T3 - P0, SE4, T4 - P0, SE5, T5( a ) : Lecture seule ( b ) : Lecture / écriture ( tmp ) : Lecture / écriture ( i ) : Lecture / écriture ( table ) : Lecture / écriture ( overflow ): Lecture / écriture Etant donné qu'il est inutile pour le code de la fonction � foo �, stocké dans le sous-ensemble � CO �, d'accéder aux sous-ensembles d'autres zones mémoires que la zone mémoire � PO �, l'UGM 30, via la table d'exécution, ne lui autorise donc l'accès qu'aux sous-ensembles � SEO � à � SE5 �. Les autres zones mémoire � P1 �, � P2 �, � P3 �, � P4 �, � P5 �, � P6 �, � P7 �... d'autres fonctions (et a fortiori d'autres applications) sont ainsi protégées de tout risque de corruption de mémoire ou de sur-écriture liée à des phénomènes d� Dans les exemples ci-dessus, il a été attribué une série de 3 champs propre à chaque sous-ensemble tandis que chaque fonction possédait également sa propre série de 3 champs. Il est possible de faire correspondre l'attribution de ces champs à la structure même du programme. La série de champs va refléter l'architecture logicielle. Il est ainsi possible d'attribuer à chaque fonction sa propre série de champs. Dans une représentation à 3 niveaux par exemple : - Processus Px - Code Cx - Offset Ox Chaque fonction sera indicée par un index Cx différent pour s'adapter à l'organisation propre au programme informatique. Exemple : Fonction initialisation -* P1, Cl, 01 Fonction calcul -* P1, C2, 02 { 30 Fonction lecture -* P1, C3, 03 } Fonction affichage -* P1, C4, 04 { Fonction écriture -* P1, C5, 05 } } (P1, Cl, 01 : Processus 1, Code 1, Offset 1) Dans cet exemple, la structure même de l'indexation en série de champs reflète la structure du programme. De la même manière, il est possible d'appliquer la même logique dans le cas d'un langage orienté objet utilisant classes et méthodes. A titre d'exemple, nous pouvons utiliser une classification avec 4 champs : - Processus - Classe - Méthode - Offset Classe initialisation -* P1, Cl, M1, 01 Classe calcul-* P1, C2, M1, 01 { 18 fonction lecture -* P1, C2, M2, 02 } Classe affichage -* P1, C3, M1, 01 { fonction écriture -* P1, C3, M2, 02 } } Ou P1, Cl, M1, 01 représentent Processus 1, Classes, Methodei, Offset 1. 15 La structure des champs gérés par l'UGM découle directement de l'architecture logicielle pour s'inspirer de la logique interne du programme informatique. Ainsi, la suite de champs est définie de telle sorte que l'organisation de la mémoire épouse le découpage du système informatique en applications, librairies, fonctions, classes, méthodes, système 20 d'exploitation ou toute autre classification. Le nombre de champs définissant la mémoire est directement lié au type d'application : ainsi avec une représentation à 3 champs (processus, sous-ensemble, taille maximale du sous-ensemble), il est possible d'instancier deux fois la même application dans deux processus différents 25 sans risque de confusion entre les deux exécutions. De même, en rajoutant un champ 'système d'exploitation', deux systèmes d'exploitation peuvent fonctionner en parallèle sur le même système informatique sans risque de confusion mémoire : la mémoire se définit alors avec 4 champs : système d'exploitation, processus, sous- 30 ensemble, taille maximale du sous-ensemble. 10 Par ailleurs, dans un environnement mufti-coeur ou multi-processeur, un champ peut être attribué à chaque processeur pour éviter tout risque de confusion en mémoire. De manière générale, l'unité de gestion de mémoire comprend des moyens pour gérer les droits d'accès à un sous-ensemble contenant des données par un sous-ensemble contenant du code et également par les droits d'appels ou d'exécution d'un sous-ensemble contenant du code à un autre sous-ensemble contenant du code en se basant sur l'identification des sous-ensemble par une série de champs. Nous allons maintenant décrire le fonctionnement de l'allocation mémoire. Une des fonctions classiques proposées par un système d'exploitation est l'allocation et désallocation d'espace mémoire à une application. Une application peut demander de façon dynamique une certaine zone mémoire pour y stocker et travailler des données. La quantité mémoire réclamée peut être grandement variable d'une application à une autre et même d'une exécution à une autre de la même application. Cette fonctionnalité est classiquement prise en charge par le système d'exploitation. (Il s'agit des instructions 'malloc' ou 'free' des langages informatiques). Dans cette invention, l'espace mémoire est géré non plus par adresse mais par une série de champs ; LUGM faisant la translation entre ces 25 champs et l'adresse physique en mémoire. L'UGM 30 étant responsable de la gestion de la mémoire, elle peut automatiquement allouer et/ou désallouer un espace mémoire sur simple demande du processeur. L'UGM 30 réserve donc en mémoire la quantité de mémoire demandée par l'application. Ce sous-ensemble se voit attribuer 30 une série de champs permettant de le désigner (Par exemple indice d'application, indice de sous-ensemble, indice d'offset maximal). Une des caractéristiques principales de LUGM 30 est d'offrir la possibilité d'allouer cet espace mémoire à la suite de l'espace mémoire déjà utilisé (figure 3 (a)) sur demande d'une application. Elle dispose de la possibilité d'allouer cette zone mémoire (� espace nouvellement alloué �, figure 3(b)) immédiatement après la zone mémoire préalablement allouée et ce de manière transparente pour le processeur/coeur de processeur, de l'application ou d'un système d'exploitation, qui n'interviennent pas dans le processus de réservation d'espace mémoire. De même lors d'une libération mémoire, LUGM 30 peut automatiquement, toujours sans intervention d'un processeur / coeur de processeur, d'une application ou d'un système d'exploitation repositionner les données afin de combler les espaces libérés par une application (figure 4). L'UGM recopie automatiquement les données de la zone mémoire supérieure (figure 4(b)) vers la zone mémoire inférieure (figure 4(c)). Cette opération reste totalement transparente pour une application, un processeur / coeur de processeur ou un système d'exploitation, car les données manipulées restent adressées sous forme de champs et non pas par une adresse (réelle ou virtuelle). La figure 5 représente une zone mémoire utilisée par le processus 0, comprenant 6 sous-ensembles (numérotés de 0 à 5). Le sous-ensemble 3 n'est plus utile au programme et est donc effacé : un trou se forme en mémoire (figure 5b). L'UGM 30 peut alors recopier les données du sous-ensemble 5 automatiquement et ce toujours sans aucune intervention ni d'un processeur/coeur de processeur, ni d'une application ni d'un système d'exploitation (figures 5e -5f). L'UGM accède indifféremment aux données déjà recopiées ou bien à celles se trouvant en attente de recopie sans latence, et peut accéder aux autres données pendant la recopie. Cette possibilité permet d'éviter la fragmentation mémoire (trous inutilisés dans le tableau mémoire). Il devient très facile d'allouer de grandes zones mémoires pour une application. (Si la mémoire libre est fragmentée en de multiples zones, il devient délicat d'allouer une zone mémoire d'une taille supérieure à la plus grande zone mémoire contigüe disponible, même si la quantité de mémoire libre est supérieure à la taille de la zone mémoire à allouer). Dans l'exemple mentionné aux figures 6a, 6b, on a représenté les données des différents processus (ou applications) P0, P1, P2. Chaque processus utilise un certain nombre de pages mémoires, à savoir dans cet exemple trois pour P1, et quatre pour PO et P2. Le processus P1 est supprimé (fig. 6b) et les sous-ensembles C, G, H liés à P1 deviennent donc vides et libres pour stocker de nouvelles informations. La suppression de ce processus P1 n'entraîne pas de recopie de données grâce à ce mécanisme de pages et permet d'allouer/désallouer des espaces mémoires plus facilement. Il est à noter que ce mécanisme de pages est déjà connu et implémenté actuellement mais peut permettre d'optimiser les mécanismes de l'UGM. Cette pagination est optionnelle pour l'UGM mais permet de gagner en souplesse lors d'allocations mémoire. Par contre, il est également possible à l'UGM de recopier les pages utilisées dans les pages vides afin, là encore, de réduire la fragmentation mémoire. Cette particularité permet à l'UGM de diviser de manière dynamique la mémoire physique en deux espaces distincts : une partie de cet espace utilisée et une autre inutilisée. En conséquence, cela permet de couper dynamiquement l'alimentation électrique de la zone mémoire non utilisée afin de réduire la consommation électrique globale du système informatique. Par symétrie, l'UGM peut alimenter de nouveau une zone mémoire quand le système informatique réclame davantage de ressource mémoire. Nous allons maintenant décrire le rôle et le fonctionnement de la logique de contrôle ou superviseur.30 Les paragraphes précédents ont en effet traité du cas où une application fonctionne de façon autonome : la mémoire est découpée en entités élémentaires (sous-ensembles) pour éviter tout risque de corruption mémoire à l'intérieur d'une application ou bien par une application externe. Par contre, il devient impossible d'échanger des informations entre deux applications car l'UGM 30 compartimente de façon hermétique la mémoire entre les différentes applications du fait de l'adressage mémoire particulier. L'UGM 30 permet cependant de résoudre ce problème en implémentant un module de supervision 320 (Figures) permettant d'échanger des données entre plusieurs applications. L'UGM peut, dans ce but, stocker une table de correspondance et de droits d'accès spécifiques à certains sous-ensembles. Ainsi, un sous-ensemble caractérisé par un ensemble de champs Pa, Bb peut être visible par une autre application comme le sous-ensemble Px, By. Il s'agit du même espace mémoire mais identifié de deux façons différentes par deux applications différentes. L'UGM fait le lien entre les deux sous-ensembles de façon transparente pour chaque application. L'UGM 30 peut gérer de façon très fine les droits d'accès à ces sous- ensembles: chaque sous-ensemble peut être accessible en lecture et/ou écriture et ceci un certain nombre de fois seulement par une ou plusieurs applications. Dans l'exemple mentionné aux figures 7a à 7c, le processus PO veut partager le sous-ensemble PO-SE6 avec le processus P1. Le processus PO informe d'abord l'UGM 30 (et plus précisément le superviseur 320) qu'il veut partager en lecture le sous-ensemble 6, c'est l'action (1) de la figure 7a. Parallèlement, le processus P1 demande à l'UGM l'accès à ce sous-ensemble ou bien l'UGM informe le processus P1, qu'un sous-ensemble est à sa disposition en lecture. Mais le processus P1 ne pourra pas lire un sous-ensemble appartenant au processus P0, car ils appartiennent à deux sous-ensembles distincts, c'est-à-dire PO et P1. L'UGM, au travers du superviseur (Block 320 - figure 1) va permettre aux deux processus de partager ce sous-ensemble en autorisant le processus P1 à manipuler une série de champs appartenant au processus PO (PO - SE6 dans l'exemple de la figurez) ou bien en désignant par le sous-ensemble P1 - SE19 le sous-ensemble PO-SE6. Pratiquement, ce même sous-ensemble PO-SE6 pourra être vu par le processus P1 comme un sous-ensemble P1, SE19, voir action (3) de la figure 7c, et par le processus PO comme un sous-ensemble PO-SE6. Ce système permet ainsi de partager de façon fiable et sûre un sous-ensemble entre deux processus (ou deux applications). Nous allons maintenant expliciter la gestion d'un processus par l'UGM 30. L'UGM est informée de l'indice du processus en cours d'exécution et ainsi permet de stopper les accès aux données appartenant à d'autres processus (sauf dans le cas d'un sous-ensemble partagé entre plusieurs processus). Lorsqu'un processus PO est stoppé pour laisser la place à l'exécution d'un autre processus P1, l'UGM en est informée par les signaux émis par le processeur. L'UGM cesse alors d'autoriser les accès dans la mémoire utilisée par le processus PO mais autorise les accès mémoire P1. (Suivant notre classification mémoire par une série de champs, il suffit de lire l'indice du processus pour déterminer immédiatement à quel processus est rattachée cette adresse mémoire). De même, lorsqu'une nouvelle application est lancée, il faut lui attribuer un nouvel indice Px. Le processeur (généralement le système d'exploitation) informe l'UGM qu'un nouveau processus va être lancé et l'UGM va ainsi lui attribuer un nouvel indice. Ce système propose ainsi la fonctionnalité de l'opération 'FORK' sur de nombreux systèmes d'exploitation et peut être contrôlé directement par l'UGM. Ce mécanisme permet par exemple d'éviter à un virus de s'exécuter en parallèle et de se multiplier sur un système informatique car cette création de nouveaux processus est sous le contrôle de l'UGM. Cette caractéristique permet également à l'UGM de contrôler un système informatique fonctionnant sur plusieurs processeurs ou coeur de processeurs: l'UGM permet à chaque coeur d'accéder à la mémoire sans risquer à un coeur d'écraser les données d'un autre coeur. Grâce à l'UGM, il est possible d'interrompre facilement une application tournant sur un processeur ou coeur de processeur et de faire redémarrer cette application sur un autre processeur ou coeur de processeur. La mémoire utilisée par le processeur pour un processus est clairement identifiable au travers de la série de champs, il est alors facile de transférer les données à traiter et le code à exécuter d'un processeur/coeur de processeur à un autre. L'invention présente ainsi de nombreux avantages. Parmi ceux-ci, il s'agit de la sécurité par la suppression des risques de � buffer overflow � ou de corruption mémoire à l'intérieur d'une application (ou processus) ou bien entre applications (entre processus). L'invention permet ainsi à la fois de fiabiliser le logiciel et de garantir son bon fonctionnement ainsi que d'en faciliter le développement. Toujours sur le plan de la sécurité, un code malicieux (ou virus informatique) ne peut se propager ou corrompre d'autres applications. Il reste cloisonné dans son environnement mémoire : chaque application (processus) n'accède qu'à sa propre zone mémoire car chaque sous-ensemble est délimité par des bornes. Le virus pourra certes s'exécuter sur un ordinateur comme une application parmi d'autres mais ne pourra pas interférer avec d'autres programmes. De plus, la consommation électrique peut être réduite sur la mémoire car il est possible de n'alimenter dynamiquement que la partie de la mémoire réellement utilisée, l'espace vide n'étant pas alimenté. L'UGM optimise et fiabilise la communication entre plusieurs applications. Elle rend possible la communication inter-tâches qui est souvent gérée par une librairie spécialisée du système d'exploitation : l'UGM la prend en charge de façon beaucoup plus souple, plus rapide, plus fiable et sans intervention du processeur principal. On libère ainsi le système d'exploitation de cette tâche, rendant ce dernier plus efficace pour la gestion de l'ensemble de l'environnement informatique. REVENDICATIONS1. Dispositif de gestion de la mémoire comprenant une unité de gestion de mémoire (UGM), d'une part connectée et/ou intégrée à au moins un processeur ou coeur de processeur et d'autre part en communication avec une ou plusieurs mémoires, et éventuellement avec un ou plusieurs systèmes d'exploitations, caractérisé en ce que le ou les processeur(s) ou coeur de processeur(s) manipule la mémoire uniquement sous la forme d'une série de champs, tandis que l'unité de gestion mémoire, s'interfaçant entre premièrement le ou les processeurs/coeurs de processeurs et deuxièmement la ou les mémoires, fait la correspondance entre d'un coté cette série de champs adressant la mémoire coté processeur et de l'autre coté la mémoire physique. 2. Dispositif selon la revendication 1, caractérisé en ce que l'UGM est agencée pour diviser la mémoire dynamiquement en différents sous-ensembles de tailles variables indicés par un champ et que chaque sous-ensemble peut être lui-même récursivement et dynamiquement subdivisé en de nouveaux sous-ensembles indicés par un champ additionnel. 3. Dispositif selon l'une des revendications précédentes, caractérisé en ce que chaque sous-ensemble est délimité en mémoire par des bornes gérées par l'UGM, qui s'assure que tout accès mémoire à ce sous-ensemble respecte les bornes délimitées. 4. Dispositif selon l'une des revendications précédentes, caractérisé en ce que chaque sous-ensemble est dimensionné avec une granularité aussi fine qu'une adresse mémoire. 30 5. Dispositif selon l'une des revendications précédentes, caractérisé en ce que chaque sous-ensemble mémoire, tout en conservant la même série de champs le désignant, est déplacé par l'unité de gestion mémoire d'une partie de la mémoire vers une autre partie de la mémoire, et ceci de manière transparente pour le processeur, le système d'exploitation et les applications du système informatique. 6. Dispositif selon l'une des revendications précédentes, caractérisée en ce que l'espace mémoire alloué à chaque sous-ensemble est agrandi ou rétréci sur demande par l'unité de gestion mémoire, tout en conservant la même série de champs le désignant. 7. Dispositif selon l'une des revendications précédentes, caractérisée en ce que l'unité de gestion mémoire est agencée de sorte à différencier, en se basant sur l'identification par série de champs, un sous-ensemble mémoire contenant du code et un sous-ensemble mémoire contenant des données. 8. Dispositif selon l'une des revendications précédentes, caractérisé en ce que, l'unité de gestion de mémoire comprend en outre des moyens pour gérer des droits d'accès en lecture, en écriture, en exécution et en interaction d'un sous-ensemble mémoire à un autre sous-ensemble mémoire en se basant sur l'identification des sous-ensembles par la série de champs. 9. Dispositif selon la revendication précédente, caractérisé en ce que les moyens pour gérer les droits d'accès sont agencés pour autoriser un ou plusieurs accès à des zones mémoire, en lecture, en écriture et exécution.30 10. Dispositif selon l'une des revendications précédentes, caractérisé en ce que l'unité de gestion de mémoire est agencée de sorte à gérer l'espace mémoire en regroupant/déplaçant les sous-ensembles mémoire pour combler les espaces mémoires vides et pour éviter le fractionnement mémoire tout en rendant cette opération transparente au processeur/coeur de processeur, au système d'exploitation et aux logiciels. 11. Dispositif selon l'une des revendications précédentes, caractérisé en ce que l'unité de gestion de mémoire est agencée pour allouer/désallouer un espace mémoire sur demande logicielle en gérant intégralement le processus d'allocation/désallocation et sans que ce processus ne fasse intervenir le processeur/coeur de processeur, le système d'exploitation ou les applications logicielles. 12. Dispositif selon l'une des revendications précédentes, caractérisé en ce que l'unité de gestion de mémoire est agencée pour gérer la désignation d'un même sous-ensemble mémoire par deux séries de champs différentes. 13. Dispositif selon l'une des revendications précédentes, caractérisé en ce que l'unité de gestion de mémoire est agencée pour séparer la mémoire en un premier espace mémoire composé par les zones mémoire utilisées et un deuxième espace mémoire vide, et en ce que le dispositif est apte à couper dynamiquement au moins une partie de l'alimentation électrique du deuxième espace mémoire. 14. Dispositif selon la revendication 1 selon lequel le processeur manipule et désigne toute adresse mémoire au travers d'une série de champs de telle sorte que chaque pointeur du processeur soit composéd'une série de champs dont l'un des champs contient l'index associé à une variable et/ou l'index associé à une fonction et/ou l'index associé à un processus au sens informatique du terme et/ou l'index associé à une classe au sens informatique du terme et/ou l'index associé à une méthode au sens informatique du terme et/ou l'index associé à une librairie au sens informatique du terme et/ou l'index associé à un système d'exploitation. 15. Dispositif selon l'une des revendications précédentes selon lequel le processeur manipule et désigne toute instruction à exécuter par une série de champs de telle sorte que l'un des champs contient l'index associé à une fonction au sens informatique du terme et/ou l'index associé à un processus au sens informatique du terme et/ou l'index associé à une classe au sens informatique du terme et/ou l'index associé à une méthode au sens informatique du terme et/ou l'index associé à une librairie au sens informatique du terme et/ou l'index associé à un système d'exploitation. 16. Dispositif selon l'une des revendications précédentes agencé de telle sorte que l'unité de gestion mémoire inclut un mécanisme de pagination simplifié qui découpe la mémoire en pages et fait la translation de manière bijective entre les pages linéaires ou virtuelles utilisées, contenant la traduction de séries de champs en adresses, et les pages de mémoire physique utilisées. 17. Dispositif selon l'une des revendications précédentes, caractérisée en ce que l'unité de gestion de mémoire fonctionne comme une machine d'état, dont l'exécution est autonome par rapport à tout autre programme d'ordinateur, y compris le cas échéant un système d'exploitation, la machine d'état étant réalisée de façon matérielle ou logicielle ou bien en partie de façon logicielle et en partie de façon matérielle. 18. Dispositif selon la revendication précédente, caractérisé en ce que l'unité de gestion de mémoire est agencée pour qu'un programme d'ordinateur puisse être mis à jour par un utilisateur. 19. Dispositif selon l'une des revendications précédentes, dans lequel l'unité de gestion mémoire est agencée de telle sorte que toute adresse mémoire manipulée par le processeur/coeur de processeur soit composée d'une série de champs qui segmentent dynamiquement la mémoire en une arborescence à plusieurs niveaux, et dont chaque niveau correspond à un champ de la série, de façon à ce que le premier champ divise dynamiquement la mémoire en différents sous-ensembles et que chacun des champs suivants divise dynamiquement le sous-ensemble désigné par les champs précédents en de nouveaux sous-ensembles. 20. Dispositif selon l'une des revendications précédentes, dans lequel l'unité de gestion mémoire est agencée de telle sorte qu'elle gère la mémoire par un système de plusieurs niveaux de segmentation imbriqués les uns dans les autres.20