FR 2814257 A1 20020322 FR 0011995 A 20000920 L'invention concerne une nouvelle architecture de microprocesseur vir- tuel. Par "microprocesseur virtuel" ou "machine virtuelle", on entendra une configuration informatique apparaissant de l'extérieur comme une machi- ne autonome, mais qui en fait inclut et intègre une machine hôte (encore dénommée "machine d'accueil" ou "plate-forme hôte") dont la machine virtuelle est un sur-ensemble. La machine hôte comprend elle-même une plate-forme matérielle et une plate-forme logicielle. La plate-forme matérielle comprend un microprocesseur physique ("mi- croprocesseur hôte") et ses périphériques tels que mémoire, affichage et moyens d'introduction de données. La plate-forme logicielle ou "système hôte" est bâtie autour d'un système d'exploitation particulier connu, qui pilote directement le microprocesseur hôte. La machine virtuelle fonctionne en réponse à des instructions d'un pro- gramme écrit dans un langage qui lui est propre, et différent du langage spécifique de la machine hôte. L'architecture de microprocesseur virtuel de l'invention, comme on le ver- ra, est particulièrement bien adaptée à un environnement matériel d'ac- cueil avec des ressources informatiques réduites (mémoire, vitesse d'horloge, absence de stockage de masse), comme cela est le cas dans les ordinateurs de poche du type "palmtop computer" ou "PDA", ou en- core les téléphones cellulaires incluant des fonctions de traitement de données (WAP, GPRS, etc.), les décodeurs de télévisions externes (de type "set-top box") ou intégrés à un téléviseur, et de façon générale les divers produits d'électronique grand public et/ou d'informatique de poche intégrant des fonctions mises en oeuvre par des moyens informatiques. Ces différents produits sont habituellement désignés sous le vocable gé- nérique d"'informatique embarquée et mobile", qui constitue le champ d'application privilégié de l'invention. Le domaine de l'informatique embarquée et mobile est confronté à une multiplicité de systèmes d'exploitation différents et incompatibles, ainsi qu'à une grande variété de plates-formes matérielles. On peut ainsi citer, parmi les différentes plates-formes ou systèmes d'ex- ploitation existants: EPOC du consortium Symbian, Windows CE et Win- dows NT for embedded de Microsoft, PalmOS de Palm Computing, BeOS de Beinc, QNX d'IBM, ainsi que divers OS (systèmes d'exploitation) "pro- priétaires" spécifiques à divers constructeurs tels que Casio, Texas Ins- truments, Sharp, etc. (les diverses dénominations citées sont des mar- ques déposées par leur titulaires respectifs). Cette multiplicité des plates-formes va à l'encontre des impératifs actuels du marché de l'informatique embarquée et mobile, marché qui est guidé par des besoins d'homogénéité, de simplicité et de réduction des coûts de revient. Par ailleurs, la portabilité des applications d'une plate-forme à l'autre est également un besoin permanent des développeurs d'applications, qui cherchent à réduire le plus possible le travail d'adaptation d'un logiciel ap- plicatif lors du passage d'une plate-forme à une autre. À cet effet, I'invention propose une nouvelle architecture de machine vir- tuelle particulièrement adaptée à l'informatique embarquée et mobile, et incluant un "middleware" (logiciel médiateur) fonctionnant en symbiose, et parallèlement, avec le système d'exploitation hôte de la machine. Essentiellement, I'architecture de l'invention repose sur un processeur vir- tuel et un quasi-système d'exploitation pouvant comprendre un moteur de base de données, un gestionnaire de fichiers, un BIOS (Basic In- put/Output Operating System, Système d'Exploitation des Entrées-Sorties de Base), des gestionnaires de communication, d'affichage et de clavier et éventuellement un protocole TCP/IP. Ce processeur virtuel se greffe entre le système d'exploitation principal hôte et le BIOS de la machine hôte, fonctionnant en symbiose avec ces derniers et en ne consommant que très peu de capacité mémoire. Comme on le verra, cette machine virtuelle est conçue de manière à être multiplate-forme, c'est-à-dire à ne requérir qu'un minimum de modifica- tions pour passer d'un système d'exploitation hôte à un autre. Ce caractère multiplate-forme permet de garantir: - la pérennité des applications développées, quelles que soient les évo- lutions logicielles et matérielles; - I'intégrité de la plate-forme matérielle et logicielle hôte, la partie de lo- giciel médiateur de l'invention étant complémentaire de celle-ci mais ne venant pas s'y substituer; ainsi les logiciels applicatifs fonctionnant sur la machine virtuelle de l'invention ne pourront pas perturber le sys- tème d'exploitation hôte, permettant de bien séparer les rôles de cha- cun de ces éléments; - I'ouverture des systèmes d'exploitation propriétaires aux dernières in- novations technologiques par l'incorporation d'un logiciel médiateur permettant de conférer à l'ensemble l'architecture selon l'invention. Ainsi, une machine virtuelle selon l'invention implantée dans un télé- phone dont le système est fermé permettra de faire fonctionner toutes les applications développées pour la machine virtuelle de l'invention sur les autres plates-formes, par exemple d'apporter à ce téléphone les dernières fonctionnalités développées sur d'autres téléphones plus récents; - enfin et surtout, I'architecture de l'invention permet, grâce à des outils de développement adaptés, d'accélérer de manière très importante les cycles de développement de produits nouveaux en facilitant la con- ception des applications et leur portage d'une plate-forme à une autre. Il existe certes des systèmes logiciels permettant une communication in- terplate-formes, comme JAVA (marque déposée de Sun Microsystems) ou WAP. Ces systèmes sont cependant différents de la proposition de l'in- vention, et peuvent d'ailleurs être utilisés en complément de cette der- nière. En effet, à la différence par exemple des logiciels JAVA, la machine virtuelle de l'invention constitue, comme on le verra, un ordinateur virtuel avec sa propre pile mémoire et sa propre base de données, et dispose donc de fonctionnalités supplémentaires. De plus et surtout, l'ordinateur virtuel de l'invention peut, comme un ordinateur réel, être programme dans différents langages, à la différence de JAVA (ou de produits similai- res) qui est indissociablement lié à la structure de la machine virtuelle JAVA. En ce qui concerne les ressources nécessaires pour faire fonctionner la machine virtuelle de l'invention, les minima requis sont inférieurs à 64 Ko de mémoire morte et 20 Ko de mémoire vive, et la machine virtuelle peut être réalisée autour de processeurs 8 bits avec des vitesses d'horloge de moins de 3 MHz. Ces valeurs sont tout à fait compatibles avec celles rencontrées dans l'in- formatique embarquée et mobile, par exemple les téléphones mobiles, par opposition aux micro-ordinateurs classiques, portables ou de bureau, o il est nécessaire par exemple de disposer d'au moins 400 Mo de mémoire disque et 32 Mo de mémoire vive pour faire fonctionner des systèmes d'exploitation tels que Windows NT, avec en outre des performances très médiocres en termes de rapidité. Plus précisément, la présente invention propose un microprocesseur vir- tuel multiplate-forme et son système d'exploitation complémentaire, com- prenant, en combinaison: - une machine d'accueil avec: une plate-forme matérielle comprenant un microprocesseur physique hôte; une plate-forme logicielle compre- nant un système d'exploitation hôte, des modules gestionnaires de mémoire et de matériel, et d'éventuelles applications natives; - des moyens médiateurs comportant: - un noyau implémentant des fonctions de bas niveau, ce noyau in- cluant une interface avec (i) ledit système d'exploitation hôte, (ii) lesdits modules gestionnaires de mémoire et de matériel, et (iii) lesdites éventuelles applications natives, - une API apte à recevoir des instructions exécutables formulées dans un langage indépendant du microprocesseur et du système hôte, le microprocesseur virtuel opérant en réponse à ces instruc- tions exécutables, - des modules fonctionnels de haut niveau interfacés (i) entre eux, (ii) avec l'API et (iii) avec le noyau, et - des moyens pour transcrire le code desdites instructions exécuta- bles en code de bas niveau directement exécutable sur le micro- processeur hôte; Tout échange de données entre les moyens médiateurs et la plate-forme logicielle est opéré via ladite interface du noyau, et l'ensemble des moyens médiateurs, à l'exception de ladite interface du noyau, est codé en un langage indépendant de la machine d'accueil. Selon diverses caractéristiques subsidiaires avantageuses: - le code du logiciel médiateur est incorporé dans une mémoire morte, ou une mémoire flash de microcontrôleur; - lesdits moyens pour transcrire le code des instructions exécutables en code de bas niveau directement exécutable sur le microprocesseur hôte comprennent un translateur de code, un compilateur à la volée et/ou un convertisseur de byte-code; - lesdites fonctions de bas niveau implémentées par le noyau compren- nent: un IOCS/BIOS, un gestionnaire de mémoire distinct du gestion- naire de mémoire de la plate-forme hôte et /ou un gestionnaire des pi- les des moyens médiateurs; ainsi qu'éventuellement une gestion d'in- terface utilisateur graphique intégrée indépendante du système d'ex- ploitation hôte et/ou des fonctions de: allocation/désallocation d'une zone mémoire partagée entre plusieurs applications, sémaphore inter- thread, création et suppression de thread, création et suppression de temporisation, écriture et lecture de type RAW vers un pilote vidéo, gestion de périphérique d'entrée de clavier matériel ou logiciel, gestion de périphérique de pointage, gestion de périphérique de sortie pour liaison matérielle, économie d'énergie, et/ou accès à un système de stockage de masse; - lesdits modules fonctionnels de haut niveau sont des modules aptes à implémenter des fonctions de: gestion d'un système de fichiers, mo- teur de base de données, communication avec l'extérieur, pile TCP/IP, gestion d'imprimante, lecteur de livre électronique, module hypertexte, gestionnaire d'interface graphique et module graphique, outils et librai- rie de fonctions auxiliaires et/ou interface d'appel vers un système lo- cal; - les moyens médiateurs sont des moyens aptes à être mis en oeuvre en mode superviseur du système d'exploitation. On va maintenant décrire un exemple de réalisation, en référence à la figure unique annexée qui est un synoptique illustrant l'architecture de la machine virtuelle selon l'invention. Sur la figure 1, la référence 100 désigne, de façon générale, la machine virtuelle selon l'invention, qui fonctionne en réponse à des instructions de programme d'une application exécutable 200. L'application exécutable 200 est en un code binaire propre à la machine virtuelle, mais ce code binaire peut être obtenu à partir d'un langage de haut niveau et n'est pas lié à un langage spécifique. Ainsi, les langages tels que JAVA, C, C++, BASIC, HTML, WML, etc. sont utilisables, et une application écrite dans l'un de ces langages sera traitée au moyen d'un outil de développement comprenant un assembleur et un compilateur (ainsi qu'un convertisseur de byte-code JAVA, s'il y a lieu), pour donner le code binaire exécutable appliqué directement au micropro- cesseur de la machine virtuelle de l'invention. Cet outil de développement peut être le cas échéant incorporé à la ma- chine virtuelle proprement dite, celle-ci intégrant alors par exemple un convertisseur de byte-code JAVA pour permettre la traduction directe du programme écrit en JAVA en code exécutable par la machine virtuelle. Par ailleurs, le langage de la machine virtuelle de l'invention est universel en ce sens qu'il est indépendant de la plate-forme sur laquelle il est exé- cuté, tant matérielle (type de microprocesseur) que logicielle (système d'exploitation hôte). Cette caractéristique "multiplate-forme" est un avantage essentiel procuré par la présente invention, qui permet donc le développement d'applica- tions sûres, hautement performantes et robustes sur des plates-formes multiples fermées ou au sein de réseaux hétérogènes sans être liées à un langage spécifique. Ces applications pourront ainsi être exécutées sur une plate-forme quel- conque sans avoir besoin de connaître le système d'exploitation hôte ou l'environnement matériel d'accueil, en particulier le microprocesseur et les périphériques d'entrée-sortie. De plus, grâce à la structure de machine virtuelle que l'on va décrire, ces applications pourront être exécutées sur des machines à ressources limi- tées comme dans le cas des ordinateurs de poche (PDA), des téléphones portables ou encore des téléviseurs, décodeurs ou dispositifs semblables, car la machine virtuelle est conçue de manière à consommer le strict mini- mum de puissance sur la machine locale, tant en ce qui concerne la mé- moire (typiquement moins de 64 Ko de mémoire morte et 20 Ko de mé- moire vive) que les performances du microprocesseur (la machine vir- tuelle peut accepter les processeurs 8 bits avec des vitesses d'horloge inférieures à 3 MHz). La machine virtuelle 100 comporte, essentiellement: - une plate-forme matérielle constituée d'un microprocesseur physique hôte 110, qui peut être indifféremment un microprocesseur de type RISC ou CISC (Reduced/Complex Instruction Set Computer, Ordina- teur à Jeu d'instructions Réduit/Complexe); - une plate-forme logicielle hôte 120, réalisée autour d'un système d'ex- ploitation hôte 121 d'un type classique préexistant, non modifié; - un "middleware" (logiciel médiateur) 130, coopérant d'une part avec la plate-forme matérielle et logicielle 110, 120 et, d'autre part, avec l'ap- plication 200 dont il reçoit des instructions de programme exécutables, en code binaire adapté au microprocesseur virtuel 138. La plate-forme matérielle et logicielle 110, 120 est une plate-forme pre- existante, déjà intégrée à l'appareil en question (ordinateur de poche, té- léphone, décodeur, etc.); elle n'est en aucune façon modifiée et elle est réutilisée pour la mise en oeuvre de la machine virtuelle de l'invention, dont elle est un élément nécessaire au fonctionnement. Plus précisément, la plate-forme logicielle hôte ou système hôte 120 com- prend, outre le système d'exploitation hôte 121 au sens strict, une unité de gestion de la mémoire MMU (Memory Management Unit, Unité de Gestion de la Mémoire) 123, ainsi qu'un certain nombre de gestionnaires de matériel 124 optionnels tels que gestion vidéo, gestion d'un clavier, gestionnaire multitâche, gestion des entrées (souris, stylo, entrée vocale ou autre). L'ensemble de ces modules constitue un micro-noyau 122 interfacé avec le système d'exploitation hôte 121 par une API (Application Programming Interface, Interface de Programmation d'Application) de bas niveau 125. La plate-forme hôte peut également inclure des applications natives 126, qui seront gérées de la même manière que le système d'exploitation hôte 120. Le système d'exploitation hôte est un système d'exploitation connu, parmi lesquels on peut citer, en ce qui concerne les systèmes adaptés à l'infor- matique embarquée et mobile: Windows CE dans ses différentes ver- sions, Epoc 32, Epoc 16, Synergie, PalmOs, les systèmes "propriétaires" tels que ceux de Casio, Texas, Sharp, etc., et également les systèmes d'exploitation traditionnels tels que Windows 3.1, 95, 98, NT, ou Linux (les dénominations citées sont des marques déposées par leurs titulaires res- pectifs). En dehors du cadre en trait plein épais délimitant la machine virtuelle 100 de l'invention (englobant les éléments 110, 120 et 130), toutes les appli- cations conçues pour la machine virtuelle de l'invention sont indépen- dantes de la plate-forme qui les mettra en oeuvre, tant matérielle (micro- processeur 110 et circuits associés) que logicielle (système hôte 120). La ligne en tiretés délimite, en bas et à droite, l'ensemble des éléments réutilisés préexistants (plate-forme matérielle 110 et logicielle 120) et, en haut et à gauche, le logiciel médiateur 130 de l'invention permettant l'a- daptation aux différentes configurations, pour l'exécution d'une application exécutable écrite indépendamment de la plate-forme considérée. Ce logiciel médiateur 130 est bâti autour d'une couche basse 131 formant noyau et contenant des fonctions de bas niveau requises par la machine virtuelle de l'invention. Ce noyau 131 contient un IOCS/BIOS (Input-Output Commun System / Basic Input-Output Operation System, Système Commun aux Entrées- Sorties / Système d'Exploitation des Entrées-Sorties de Base), ainsi qu'un gestionnaire de mémoire (distinct du gestionnaire de mémoire de la plate- forme hôte) ainsi qu'un gestionnaire des piles du logiciel 130 et d'autres gestionnaires qu'il peut être avantageux de prévoir. Plus précisément, le noyau 131 doit permettre de faire fonctionner le logi- ciel médiateur 130 de façon autonome dans certaines circonstances, par exemple pour la gestion d'un périphérique dépourvu de système d'ex- ploitation hôte. Pour ce faire, le noyau 131 doit permettre: - le lancement du logiciel médiateur par le système (appel d'un point d'entrée par le système); l'accès horloge, typiquement par incrément minimum d'une seconde; I'allocation d'une zone mémoire continue, typiquement d'un minimum de 20 Ko de mémoire vive; - en cas de système à optimisation mémoire automatique, ou d'un systè- me à allocation mémoire au travers d'un moteur de base de données, la possibilité de verrouiller au minimum une zone mémoire de 20 Ko. Le noyau 131 n'a pas besoin d'une MMU, mais peut utiliser une MMU pour faire apparaître en contigu plusieurs types de mémoires physiques disjointes, simplifiant ainsi l'allocation mémoire. Dans tous les cas, le noyau fournira une zone mémoire programme continue, en présence ou en l'absence d'une MMU. D'autres fonctions peuvent éventuellement être intégrées au noyau 131 pour en assurer le support, telles que: - allocation/désallocation d'une zone mémoire partagée entre plusieurs applications; - sémaphore "inter-thread", création et suppression de "thread" (chaî- nage dans le cas d'un fonctionnement multitâche) - création et suppression de temporisation; - écriture et lecture de type RAW vers un pilote vidéo; - périphérique d'entrée clavier (clavier matériel ou logiciel); périphérique de pointage (stylo, souris, entrée vocale ou autre), avec possibilité d'accéder directement à la couche matérielle ou fournir une émulation logicielle à partir d'un autre périphérique. En cas d'interac- tion avec un utilisateur, un moyen d'entrée doit être disponible (inter- face série, infrarouge ou autre); - périphérique de sortie pour liaison matérielle (liaison série, réseau, infrarouge ou autre); - fonctions d'économie d'énergie; - accès au système de stockage de masse éventuel, avec possibilité de fournir un support de disque virtuel géré en RAM ou en mémoire flash, - fonction de sortie sonore si l'appareil le permet. Le noyau 131 est configuré de manière à ce que seulement une partie très réduite du code, représentée en 132 (interface vers le système d'ex- ploitation hôte) soit spécifique à la plate-forme hôte; pour le reste, le noyau est indépendant de la plate-forme utilisée, et peut-être écrit en un langage de programmation classique (par exemple en C). Il en est de mê- me pour le reste de la machine virtuelle de sorte que, pour porter celleci sur une nouvelle plate-forme, il ne sera nécessaire que d'adapter très peu de code, typiquement une quinzaine de fonctions, le reste du code ne va- riant pas. Il est également possible d'intégrer des spécificités lors de cas particuliers, par exemple la présence de plusieurs processeurs dans un même appareil ou de DSPs (Digital Signal Processors, Processeurs Nu- mériques de Signaux) spécifiques, par exemple dans le domaine du trai- tement vidéo ou de la téléphonie. L'interface 132 communique avec le système hôte et constitue le point de passage obligé pour tout échange de données ou appels du logiciel mé- diateur 130 avec la plate-forme d'accueil. C'est cette interface qui assure la communication: - avec le système d'exploitation hôte 121 via l'API de bas niveau 125, - avec les applications natives 126, le cas échéant, et - avec le micro-noyau et gestionnaire de matériel 122 du système d'ex- ploitation hôte. En d'autres termes, à chaque appel vers le système hôte, qu'il s'agisse d'une opération interne au logiciel médiateur 130 ou de l'exécution d'une instruction de l'application exécutable 200, cette appel devra transiter par l'interface 132, qui est la seule partie dépendante de la plate-forme hôte. Aucune des caractéristiques fournies par le logiciel médiateur 130 direc- tement ou indirectement n'impose d'exigences particulières sur le système d'exploitation hôte 120. Ainsi, si un service du système d'exploitation 120 est indisponible ou différent, une solution de remplacement ou de com- plément sera automatiquement fournie par le logiciel médiateur 130. De plus, ce dernier, qui gère ses propres piles et inclut sa propre gestion mémoire, n'utilise pas le système de gestion mémoire hôte si celui-ci n'est pas disponible. Il comprend également un système de simulation d'inter- ruption au cas o le système hôte ne peut en fournir. Le système de gestion graphique intégré peut fournir une GUI (Graphical User Interface, Interface Utilisateur Graphique) indépendante du système d'exploitation hôte, pour mettre en ceuvre de façon uniforme des graphi- ques et des fenêtrages, et une police de caractères constante et identique sur tous les systèmes hôtes. Par ailleurs, le noyau 131 est associé à une série de modules fonction- nels 133, avec lesquels il communique par l'intermédiaire d'APIs standar- disées. Une API interne 134 autorise la communication entre modules 133 et une autre API 135 assure l'interfaçage pour la programmation. Chacun des modules 133 assure une fonction particulière, qui peut être notamment: - gestion d'un système de fichiers (FAT et VFAT), - moteur de base de données. - modules de communication, - pile TCP/IP, - gestion d'imprimante, lecteur de livre électronique et module hypertexte, - gestionnaire d'interface graphique et module graphique, - outils et librairie de fonctions diverses, - interface d'appel vers un système local. La structure modulaire et l'indépendance par rapport à la plate-forme per- mettent un enrichissement et une amélioration constants de ces différen- tes fonctions sans remise en cause ni de l'architecture ni de l'écriture du reste du système. Comme on l'a déjà indiqué plus haut, une seule tâche est nécessaire pour mettre la machine virtuelle en adéquation avec un système d'exploitation hôte particulier, à savoir le portage de la partie spécifique 132 en fonction des ressources disponibles ou autorisées par la plate-forme hôte. Par ailleurs, la structure modulaire permet par exemple, si nécessaire ou pour améliorer la vitesse d'exécution, d'utiliser un pilote de périphérique spécifique à la machine virtuelle de l'invention en lieu et place du pilote du système hôte et ceci, sans avoir à adapter ce pilote particulier à la plate-forme en question. De façon générale, cette structure modulaire permet de doter la machine virtuelle de l'invention d'un certain nombre de fonctionnalités intégrées de manière native, indépendamment de la plate-forme d'accueil, tout en con- servant la possibilité d'utiliser en pratique les ressources du système hôte (si elles existent), qui fonctionnent toujours parallèlement à celles du logi- ciel médiateur. Inversement, si le système hôte possède des caractéristiques qui lui sont propres, la machine virtuelle de l'invention peut, de manière transparente pour les applications conçues pour elle, utiliser ces caractéristiques à la place de celles intégrées dans le logiciel médiateur. L'ensemble du code du logiciel médiateur 130 est écrit dans un langage indépendant de la machine, par exemple en langage C, et peut avanta- geusement être incorporé dans une mémoire morte. Étant conçu pour s'exécuter localement, il ne demande donc pas à être chargé en mémoire vive (sauf contrainte particulière du système d'exploitation hôte), d'o un gain très important de place mémoire et de rapidité. Au lancement, une à cinq zones de mémoire sont allouées, y compris une zone pour la pile propre au logiciel 130 ainsi que les pilotes gestionnaires des périphériques. Le code de démarrage gère également les systèmes de configuration du matériel qu'il a détectés dans les pilotes correspon- dants. La machine virtuelle de l'invention fournit un environnement de fonction- nement contrôlé et plus sûr qu'un système natif. De ce fait, le système dans son intégralité, y compris le téléchargement des applications exécu- tables ou la mise à jour de la machine virtuelle, peut être exécuté dans le mode superviseur du système. Le fait de travailler en mode superviseur uniquement et sans qu'il soit nécessaire d'avoir une MMU permet de sim- plifier la machine virtuelle de l'invention et la rendre plus efficace que les systèmes virtuels traditionnels. * L'invention prévoit enfin des moyens pour transcrire le code binaire 200 de la machine virtuelle en code de bas niveau directement exécutable sur le processeur physique 110. Un premier moyen consiste à prévoir un interpréteur de code 136, plus précisément un translateur de code, générant des instructions de bas ni- veau à partir du code binaire et donc identiques à une stratégie de micro- processeur physique. L'autre moyen consiste à utiliser un compilateur à la volée 137. Ce der- nier produit un résultat identique, mais le traitement est exécuté une seule fois au lancement de l'application, et non à chaque instruction. Le code devient donc identique au code exécutable nativement sans qu'il soit né- cessaire de l'interpréter, avec un gain important de vitesse. Le compilateur à la volée ou le translateur de code sont écrits dans un langage indépendant de la machine, par exemple en langage C. REVENDICATIONS 1. Un microprocesseur virtuel (100) multiplate-forme et son système d'ex- ploitation complémentaire, destiné notamment au domaine de l'informati- que embarquée et mobile, caractérisée en ce qu'il comprend, en combinaison: - une machine d'accueil avec: - une plate-forme matérielle (110) comprenant un microprocesseur physique hôte, - une plate-forme logicielle (120) comprenant: un système d'exploitation hôte (121), des modules gestionnaires de mémoire (123) et de matériel (124), et d'éventuelles applications natives (126); - des moyens médiateurs (130) comportant: - un noyau (131) implémentant des fonctions de bas niveau, ce noyau incluant une interface (132) avec (i) ledit système d'exploita- tion hôte, (ii) lesdits modules gestionnaires de mémoire et de maté- riel, et (iii) lesdites éventuelles applications natives, - une API (134, 135) apte à recevoir des instructions exécutables (200) formulées dans un langage indépendant du microprocesseur et du système hôte, le microprocesseur virtuel opérant en réponse à ces instructions exécutables, - des modules fonctionnels de haut niveau (133) interfacés (i) entre eux, (ii) avec l'API et (iii) avec le noyau, et - des moyens (136, 137) pour transcrire le code desdites instructions exécutables en code de bas niveau directement exécutable sur le microprocesseur hôte; en ce que tout échange de données entre les moyens médiateurs (130) et la plate-forme logicielle (120) est opéré via ladite interface (132) du noyau (131), et en ce que l'ensemble des moyens médiateurs, à l'exception de ladite interface du noyau, est codé en un langage indépendant de la machine d'accueil. 2. Le microprocesseur virtuel et son système d'exploitation complémen- taire de la revendication 1, o le code du logiciel médiateur est incorporé dans une mémoire morte, ou une mémoire flash de microcontrôleur. 3. Le microprocesseur virtuel et son système d'exploitation complémentaire de la revendication 1, o lesdits moyens pour transcrire le code des instructions exécutables en code de bas niveau directement exécutable sur le microprocesseur hôte sont des moyens du groupe comprenant: un translateur de code (136); et un compilateur à la volée (137). 4. Le microprocesseur virtuel et son système d'exploitation complémen- taire de la revendication 1, o lesdits moyens pour transcrire le code des instructions exécutables en code de bas niveau directement exécutable sur le microprocesseur hôte comprennent un convertisseur de byte-code. 5. Le microprocesseur virtuel et son système d'exploitation complémen- taire de la revendication 1, o lesdites fonctions de bas niveau implé- mentées par le noyau (131) sont des fonctions du groupe comprenant: un IOCS/BIOS; un gestionnaire de mémoire distinct du gestionnaire de mé- moire de la plate-forme hôte; et un gestionnaire des piles des moyens médiateurs. 6. Le microprocesseur virtuel et son système d'exploitation complémen- taire de la revendication 5, o lesdites fonctions de bas niveau implé- mentées par le noyau (131) incluent une gestion d'interface utilisateur graphique intégrée indépendante du système d'exploitation hôte. 7. Le microprocesseur virtuel et son système d'exploitation complémen- taire de la revendication 5, o lesdites fonctions de bas niveau implé- mentées par le noyau (131) incluent en outre des fonctions du groupe comprenant: allocation/désallocation d'une zone mémoire partagée entre plusieurs applications; sémaphore inter-thread; création et suppression de thread; création et suppression de temporisation; écriture et lecture de type RAW vers un pilote vidéo gestion de périphérique d'entrée de clavier matériel ou logiciel; gestion de périphérique de pointage; gestion de périphérique de sortie pour liaison matérielle; économie d'énergie accès à un système de stockage de masse. 8. Le microprocesseur virtuel et son système d'exploitation complémen- taire de la revendication 1, o lesdits modules fonctionnels de haut niveau (133) sont des modules aptes à implémenter des fonctions du groupe comprenant: gestion d'un système de fichiers; moteur de base de don- nées; communication avec l'extérieur; pile TCP/IP; gestion d'impriman- te; lecteur de livre électronique module hypertexte gestionnaire d'in- terface graphique et module graphique outils et librairie de fonctions auxiliaires; interface d'appel vers un système local. 9. Le microprocesseur virtuel et son système d'exploitation complémen- taire de la revendication 1, o les moyens médiateurs sont des moyens aptes à être mis en oeuvre en mode superviseur du système d'exploita- tion.