FR 2795836 A1 20010105 FR 9908408 A 19990630 Procédé pour comptabiliser le temps dans un dispositif de traitement d'information, et dispositif associé Lorsque l'on veut que deux appareils électroniques intelligents dialoguent entre eux, il faut mettre en place un protocole de communication pour gérer la bonne entente entre ces appareils. II en est de même pour la communication entre une carte à microcalculateur et le lecteur de cette carte. Plusieurs protocoles de communication ont été imaginés et/ou implémentés tels que le protocole T=1 , dit protocole par blocs , ou le plus utilisé actuellement qui est le protocole T=0 , ou protocole caractère . Dans tous ces protocoles, on se doit de spécifier différentes règles garantissant une bonne communication, telle que la reconnaissance du début de l'émission , ou la fin de l'émission . Dans l'architecture de communication entre la carte et le lecteur, la carte est considérée comme esclave et le lecteur maître . Cela signifie que c'est toujours le lecteur qui prend l'initiative du début d'un dialogue. Plus précisément, la carte est sollicitée par le lecteur, par envoi d'une commande, et la carte, après réception de cette commande, exécute un certain traitement, puis donne en retour la réponse à la commande. Notons que le cas de la mise sous-tension de la carte est un cas particulier dans la mesure où c'est par application de la tension adéquate sur la broche Reset (remise à zéro) du composant carte que le lecteur initie le dialogue. On peut considérer donc que c'est une façon particulière d'envoyer une commande sortante à la carte. En réponse à cette excitation électrique, la carte effectue le traitement adéquat d'initialisation, par exemple en remettant à zéro certaines variables en RAM, ou en leur affectant des valeurs initiales, et termine son traitement en émettant la réponse à la mise sous tension, ou ATR ( Answer To Reset en anglais). On peut distinguer plusieurs types de commande # commande entrante, avec des données l'accompagnant, voire sans donnée # commande sortante, avec des données attendues en retour # ou une combinaison des commandes précédentes Dans tous les cas, la carte doit répondre au moins par un ou deux mot(s) d'état(s). Et cette réponse doit être renvoyée au lecteur au plus tard une seconde après la fin de réception de la commande. Pratiquement, si l'on se place du côté de la carte, celle-ci doit donc disposer d'un moyen pour décompter le temps qui s'écoule. Pour l'homme du métier, le moyen classique qu'il utilisera est le service d'un compteur adjoint au microcalculateur. Celui-ci sera armé à une valeur inférieure à la seconde au début du processus, et lorsqu'il arrivera au bout de son décompte, il préviendra l'unité centrale de la carte, par déclenchement d'une interruption. L'homme du métier aura pris soin de brancher cette interruption dans la routine adéquate qui aura pour tâche d'émettre un mot d'état d'attente. Mais comme les cartes, en tant que produits commercialisées, doivent satisfaire à un certain coût imposé par le marché, leur microcalculateur est rarement équipé d'un compteur. De plus, le compteur occupe un volume non négligeable et pose donc des difficultés dans la phase d'encartage de la puce dans le support plastique. Dans l'art actuel et futur proche, de nouvelles plate-formes de système d'exploitation arrivent. Elles conservent encore des caractéristiques de l'art ancien dans la mesure où, comme auparavant, il y a un système d'exploitation de base accomplissant des tâches plus ou moins génériques, comme la gestion des entrées I sorties, ou l'écriture en mémoire non volatile du type EEPROM, et parfois encore accompagnés d'applications dédiées, par exemple une application PME (Porte Monnaie Electronique). Mais ce qui est nouveau c'est que ces plates formes sont fournies avec un noyau interpréteur de commandes, ou machine virtuelle, et d'un ensemble de routines spécifiques documentées à l'usage des développeurs d'applications en code interprété, routines nommées APIs (de l'anglais Application Program Interface : interface de programme d'application), et un mécanisme de téléchargement de ces applications. Ces applications en code interprété ont deux caractéristiques majeures qui les différencient du processus existant dans l'art antérieur. La première est que ces applications peuvent être développées, pas seulement par le fournisseur de la plate-forme, composée du système d'exploitation de base + interpréteur + APIs, mais elles sont davantage destinées à être développées par un tiers disposant de la plate-forme et des spécifications de programmation décrivant la couche la plus élevée de la plate-forme, c'est à dire le langage interprété et les APIS. La seconde est que ces applications sont téléchargées non pas pendant la mise au point du système d'exploitation de base, mais ultérieurement, pendant la phase d'utilisation de la carte ! Ainsi, une fois l'application téléchargée, l'ensemble du code qui est exécuté durant une commande carte est le résultat du déroulement mixte du code du système d'exploitation de base et celui du code interprété. La base de la solution selon l'invention utilise le fait que pour exécuter le code interprété, la plate-forme de base (système d'exploitation de base + interpréteur + APIs) doit de manière itérative prendre chaque instruction de l'application téléchargée et l'interpréter. II y a donc existence d'un processus itératif pendant l'exécution du code interprété. La solution consiste alors à insérer une routine nouvelle, que l'on nommera routine d'accumulation de durée , dans le code gérant ce processus itératif de manière à ce qu'elle soit appelée à chaque itération. L'invention concerne à cet effet un procédé pour comptabiliser le temps dans un dispositif de traitement d'information comprenant des moyens de traitement et des moyens de mémorisation, caractérisé en ce qu'il comprend les étapes consistant à -définir un tableau contenant, pour chaque instruction d'un ensemble d'instructions à exécuter par les moyens de traitement, un temps d'exécution de cette instruction ; -exécuter un programme comprenant au moins une instruction en ajoutant, au moment de l'exécution de chaque instruction, le temps d'exécution de cette instruction à une valeur de cumul de temps. En variante, l'invention concerne aussi un procédé pour comptabiliser le temps dans un dispositif de traitement d'information comprenant des moyens de traitement et des moyens de mémorisation, caractérisé en ce qu'il comprend les étapes consistant à -définir un tableau contenant, pour chaque instruction d'un programme à exécuter par les moyens de traitement, un temps d'exécution de cette instruction ; -vérifier chaque instruction du programme en déterminant si cette instruction obéit à au moins une règle déterminée en ajoutant, au moment de la vérification de chaque instruction, le temps d'exécution de cette instruction à une valeur de cumul de temps ; -comparer, au moment de la vérification de chaque instruction, la valeur de cumul de temps à une valeur de référence de temps ; -insérer dans le programme, à un endroit où se trouve l'instruction en cours de vérification, une instruction définissant une opération à effectuer par les moyens de traitement, quand la valeur de cumul de temps atteint la valeur de référence de temps ; et -faire exécuter le programme par les moyens de traitement du dispositif de traitement d'information. L'invention concerne aussi le dispositif de traitement d'information associé à ce procédé. D'autres détails et avantages de la présente invention apparaîtront au cours de la description suivante d'un mode d'exécution préféré mais non limitatif, en regard des dessins annexés sur lesquels La figure 1 représente un dispositif de traitement de données coopérant avec un objet portatif ; La figure 2 est un tableau indiquant, pour chaque instruction interprétée d'une application, sa durée d'exécution; La figure 3 est un tableau indiquant, pour chaque instruction élémentaire des moyens de traitement, sa durée d'exécution ; La figure 4 est un organigramme d'exécution d'une application intégrant une routine d'accumulation de durée selon l'invention ; La figure 5 est un tableau réduit indiquant, pour chaque instruction interprétée d'une application, sa durée d'exécution ; La figure 6 est un organigramme de vérification d'une application intégrant une routine d'accumulation de durée selon l'invention ; La figure 1 représente un dispositif de traitement de données 1 coopérant avec un objet portatif 8. Le dispositif de traitement de données comprend de façon connue en soi un microprocesseur 2 auquel sont reliés une mémoire ROM 3, une mémoire RAM 4, des moyens 5 pour coopérer, avec ou sans contact physique, avec l'objet portatif 8, et une interface de transmission 7 permettant au dispositif de traitement de données de communiquer avec un réseau de communication de données. Le dispositif de traitement de données 1 peut en outre être équipé de moyens de stockage tels que des disquettes ou disques amovibles ou non, de moyens de saisie (tels qu'un clavier et/ou un dispositif de pointage du type souris) et de moyens d'affichage, ces différents moyens n'étant pas représentés sur la figure 1. Le dispositif de traitement de données peut être constitué par tout appareil informatique installé sur un site privé ou public et apte à fournir des moyens de gestion de l'information ou de délivrance de divers biens ou services, cet appareil étant installé à demeure ou portable. II peut notamment s'agir aussi d'un appareil dédié aux télécommunications. Par ailleurs, l'objet portatif 8 porte une puce incluant des moyens de traitement de l'information 9, une mémoire non volatile 10, une mémoire volatile de travail RAM 14, et des moyens 13 pour coopérer avec le dispositif de traitement de données 1. Cette puce est agencée pour définir, dans la mémoire 10, une zone secrète 11 dans laquelle des informations une fois enregistrées, sont inaccessibles depuis l'extérieur de la puce mais seulement accessibles aux moyens de traitement 9, et une zone accessible 12 qui est rendue accessible depuis l'extérieur de la puce par les moyens de traitement 9 pour une lecture et/ou une écriture d'informations. Chaque zone de la mémoire non volatile 10 peut comprendre une partie non modifiable ROM et une partie modifiable EPROM, EEPROM, ou constituée de mémoire RAM du type "flash" ou FRAM (cette dernière étant une mémoire RAM ferromagnétique), c'est-à-dire présentant les caractéristiques d'une mémoire EEPROM avec en outre des temps d'accès identiques à ceux d'une RAM classique. En tant que puce, on pourra notamment utiliser un microprocesseur autoprogrammable à mémoire non volatile, tel que décrit dans le brevet américain n 4.382.279 au nom de la Demanderesse. Dans une variante, le microprocesseur de la puce est remplacé - ou tout du moins complété - par des circuits logiques. En effet, de tels circuits sont aptes à effectuer des calculs, notamment d'authentification et de signature, grâce à de l'électronique câblée, et non microprogrammée. Ils peuvent notamment être de type ASIC (de l'anglais Application Specific Integrated Circuit ). Avantageusement, la puce sera conçue sous forme monolithique. Selon l'invention, l'objet portatif 8 stocke, dans sa mémoire non volatile 10, un tableau TAB-INS-DUREE (figure 2) qui possède deux colonnes. Une première colonne contient des identifiants ou codes I, , IZ , ......,I; , ...... I, de n instructions interprétées constituant le code ou programme d'une application écrite en langage évolué, constituée d'éléments de ce langage et d'appels à des fonctions APIs (de l'anglais Application Program Interface , signifiant Interface de Programme d'Application ). Les fonctions APIs sont écrites en un ensemble d'instructions qui peuvent, soit être élémentaires, soit faire appel à d'autres fonctions APIs : elles accomplissent une certaine tâche. De façon connue en soi, une application est destinée à être interprétée par une machine virtuelle qui est située en mémoire non volatile 10 de l'objet portatif 8 et qui se présente sous la forme d'un code interpréteur, désigné par la suite l'interpréteur : l'interpréteur est chargé de traduire chaque instruction interprétée en des instructions appartenant à un système d'exploitation de base des moyens de traitement 9 et qui sont donc directement exécutables par ceux-ci. Une seconde colonne du tableau TAB-INS-DUREE contient, pour chacune des instructions interprétées I, , 12 , ......,I; , ...... h de l'application, une durée respective T, , T2 ,...., T; , ......, T,, correspondant au temps que mettent les moyens de traitement 9 pour exécuter l'instruction interprétée considérée. La façon dont sont calculées les durées T, , T2 ,...., T; , ......, T" va maintenant être exposée. Le fabricant de la puce équipant l'objet portatif 8 fournit habituellement, dans sa documentation, un tableau (figure 3) donnant, pour chaque instruction élémentaire i, , i2 ,....ii ,.....in, faisant partie de son système d'exploitation de base, sa durée t, , t2 , .... ti ,.....tm en nombre de cycles effectués par les moyens de traitement 9: connaissant la fréquence d'exécution des instructions élémentaires, il est facile de traduire cette durée en un temps exprimé en secondes. Par ailleurs, chaque instruction interprétée est une juxtaposition d'un certain nombre d'instructions élémentaires ; par exemple, I;=(i2 , i5 , ii , ......, ik , ..... , iP ), de sorte que sa durée T; peut être calculée comme la somme des durées respectives de ces instructions élémentaires , soit T; = t2 + t5 + ti +......+ tk +......+ tP . Un opérateur peut donc, à partir du tableau de la figure 3, constituer le tableau TAB-INS- DUREE. Dans le cas où une instruction interprétée peut comprendre plusieurs chemins possibles d'instructions élémentaires, l'opérateur choisira comme durée de l'instruction interprétée, la durée du chemin le plus long. Cette méthode est acceptable car, en se référant au codage actuel pour une plate- forme de base (système d'exploitation de base + interpréteur + fonctions APIs), on constate que la durée d'exécution de la grande majorité des instructions interprétables est autour de 250 gs. Et sachant que pour le composant de la famille 6805, une instruction élémentaire nécessite en moyenne autour de 3 cycles, et que la fréquence d'horloge normalisée est de 3,57 MHz, on en déduit qu'une instruction élémentaire s'exécute en moyenne en environ 1 las, et par conséquent, les 250 las cités ci-dessus représentent environ 250 instructions élémentaires. Et donc, pour les quelques instructions à interpréter ayant des séquences de traitement différentes, la différence entre une branche et une autre est de quelques dizaines d'instructions, typiquement entre 10 et 50 instructions élémentaires, soit quelques 10 à 50 lis de plus à ajouter aux 250 us, ce qui est relativement faible par rapport à la seconde (= 106 las ) qui est le seuil critique, délai dans lequel la carte, après avoir reçu une commande du lecteur, doit envoyer une réponse à celui-ci. La figure 4 illustre un exemple d'utilisation du tableau TAB-INS- DUREE pour permettre à une carte d'envoyer à un lecteur de carte un mot d'état d'attente dès qu'une durée Tmax s'est écoulée depuis le début d'exécution, par la carte, d'une commande envoyée par le lecteur. On considère que le tableau TAB-INS-DUREE a été stocké dans la carte. La figure 4 représente le code, stocké en carte, pour exécuter une application comprenant les n instructions interprétées I, à In , dans lequel a été insérée une routine d'accumulation de durée permettant à la carte d'envoyer ledit mot d'état d'attente. Ce code est contenu dans l'interpréteur (en variante, l'interpréteur n'est pas réalisé de façon logicielle mais matérielle, et la routine d'accumulation de durée selon l'invention est réalisée sous forme logicielle ou matérielle). A l'étape 41, l'objet portatif 8 reçoit un ordre du dispositif de traitement de données 1. A l'étape 42, une variable de temps T est initialisée à 0, et à l'étape 43, les moyens de traitement 9 lisent le code I; de l'instruction interprétable qui doit être exécutée maintenant et lisent, dans le tableau TAB-INS-DUREE, la durée T; de cette instruction qu'ils ajoutent à la variable de temps T. A l'étape 44, on compare la valeur de la variable de temps T à la durée Tmax. Si la variable de temps T n'est pas inférieure à la durée Tm,, , cela signifie que l'exécution de l'instruction interprétée courante I; va conduire à un dépassement de la durée Tm#,, : il y a donc lieu d'envoyer, à l'étape 45, un mot d'état d'attente au lecteur puis de réinitialiser à 0 la variable de temps T (par retour à l'étape 42). Suite à l'étape 44 dans le cas où la variable de temps T est inférieure à la durée T".x , l'interpréteur de la carte interprète l'instruction interprétée I; puis l'exécute (étape 46). A l'étape 47, les moyens de traitement 9 testent si l'instruction interprétée l; est la drenière à exécuter. Dans l'affirmative, l'objet portatif rend la main au dispositif de traitement de données 1 (étape 48). Dans la négative, la carte retourne à l'étape 43 en vue de traiter l'instruction interprétée suivante. On constate donc que la routine d'accumulation de durée qui a été insérée dans le code d'exécution de l'application comprend les étapes 42 à 45. L'origine de décompte du temps peut être soit la première utilisation de l'interpréteur, lors de la mise en service de la carte (on aura alors la possibilité de connaître une durée absolue, en quelque sorte l'âge d'usure de la carte) ; soit le début de chaque commande nouvelle: on aura alors une durée relative (cas de la figure 4 où la variable de temps T est initialisée au début de la commande d'exécution de l'application considérée). Dans le cas où on implémente la solution avec la durée absolue, il est facile de connaître la durée relative par simple soustraction. En effet, au début de chaque commande, on mémorise dans une variable tampon la durée absolue atteinte, puis ultérieurement, pour connaître la durée relative, il suffit de prendre la valeur de la durée absolue au moment de la consultation et de la soustraire à la valeur de la durée absolue mémorisée précédemment dans la variable tampon. Inversement, si on a choisi une implémentation en durée relative, on peut connaître la durée absolue par simple addition. Dans ce cas, à la fin de chaque commande, il faut additionner la valeur de la durée relative (T, figure 4) à la valeur contenue dans une variable cumulative permanente, c'est à dire persistante au delà de la commande courante. Une autre manière un peu plus fine d'optimiser la taille du tableau TAB-INS-DUREE, est de regrouper un ensemble d'instructions interprétables qui ont des valeurs de durée d'exécution proche, et en ne prenant que la plus grande des valeurs. Par exemple on peut faire un pas de 100 gs, et ainsi avoir un tableau du type de celui de la figure 5, dans lequel on a rangé les instructions interprétées d'une application en trois groupes. Ce tableau se lit de la manière suivante # l'ensemble d'instructions interprétées I, , 15, .....I; de la première ligne comprend toute instruction interprétée dont la durée d'exécution est inférieure ou égale à 100 gs ; # l'ensemble d'instructions interprétées IZ , 16, .....I; de la deuxième ligne comprend toute instruction interprétée dont la durée d'exécution est comprise entre 100 gs et 200 #ts ; # l'ensemble d'instructions interprétées 13 ,14 ,. ...... 1k de la troisième ligne comprend toute instruction interprétée dont la durée d'exécution est comprise entre 200 gs et 300 us, et on suppose ici que 300 gs est la durée d'exécution maximale pour l'ensemble des instructions interprétées. On constate que la taille de ce tableau est réduite par rapport à celui TAB-INS-DUREE de la figure 2, puisqu'il ne comprend que (n+3) éléments au lieu de (n+n) éléments. On utilise le tableau la figure 5 en cumulant les durées des instructions interprétées (figure 4) : la valeur de la durée T; de la figure 4 sera selon le cas 100, 200, ou 300 Ns. En ce qui concerne le lieu de stockage du tableau TAB-INS-DUREE, celui-ci doit être renseigné lors de la mise au point finale de la plate-forme de base (système d'exploitation de base + interpréteur + fonctions APIs). Ce tableau peut être placé dans la mémoire non volatile masquée, telle que la ROM, ce qui a l'avantage de ne pas gaspiller de la mémoire non volatile utilisateur, du type EEPROM, mais présente l'inconvénient de ne pouvoir évoluer si la plate forme de base est amenée à évoluer en plaçant du code additionnel, ou correctif, en mémoire non volatile utilisateur, du type EEPROM (voir la demande de brevet américaine de la demanderesse déposée sous le numéro 08981607) Dans ce cas, on peut envisager dès le départ de placer le tableau en mémoire non volatile utilisateur, du type EEPROM pour pouvoir le mettre à jour. Une autre solution consisterait à placer le tableau TAB-INS-DUREE initial en mémoire non volatile masquée, telle que la ROM, et télécharger ultérieurement, en même temps que le code additionnel pour la plate forme de base (système d'exploitation de base + interpréteur + fonctions APIs), un tableau additionnel, en mémoire non volatile utilisateur, du type EEPROM, contenant les informations correspondant aux instructions interprétées nouvellement téléchargées, ou corrigeant les valeurs de durées de certaines des instructions interprétées contenues dans le tableau initial, et prévoir dans la routine d'accumulation de durée une porte de sortie telle que dans la demande de brevet américaine de la demanderesse déposée sous le numéro 08981607, afin que cette routine analyse et tienne compte d'abord du tableau additionnel, puis seulement, le cas échéant, du tableau initial. Lorsque le tableau est analysé de la manière décrite plus haut, c'est à dire consulté par la routine d'accumulation de durée à chaque itération dans le processus de l'interpréteur de code, on peut nommer cette méthode d'analyse méthode en carte . A l'opposé, on peut utiliser une méthode dite méthode hors-carte . Celle-ci consiste à disposer du tableau TAB-INS- DUREE, en dehors de la carte. Par exemple, il est intégré à l'outil dit vérificateur qui analyse l'intégrité et l'authenticité du code de l'application en langage interprété à télécharger dans la carte. Ainsi, dans cet outil vérificateur , on peut, en parcourant le code et en effectuant une opération d'accumulation de durée à l'aide du tableau TAB-INS-DUREE, modifier le code de l'application en insérant dans celui-ci l'appel de la routine permettant d'émettre le mot d'état d'attente. Ceci est illustré par la figure 6. A l'étape 60, une variable de temps T est initialisée à 0, et à l'étape 61 on augmente la variable de temps T de la valeur T; correspondant à la durée de l'instruction interprétable qui va être vérifiée maintenant, valeur qui est lue dans le tableau TAB-INS-DUREE. A l'étape 62, on compare la valeur de la variable de temps T à la durée TmaX. Si la variable de temps T n'est pas inférieure à la durée Tmax , cela signifie que l'exécution future, par la carte, de l'instruction interprétable courante i va conduire à un dépassement de la durée Tmax : il y a donc lieu d'insérer, dans le code de l'application, à l'étape 63, une instruction d'attente la consistant, pour la carte, à envoyer un mot d'état d'attente au lecteur. Puis le vérificateur réinitialise à 0 la variable de temps T (par retour à l'étape 60). Suite à l'étape 62 dans le cas où la variable de temps T est inférieure à la durée Tmax , le vérificateur de la carte vérifie l'instruction interprétable I; (étape 64). Le vérificateur détermine ensuite si l'instruction interprétable en cours de traitement est la dernière à vérifier. Dans l'affirmative, le traitement est fini. Dans la négative, le vérificateur retourne à l'étape 61 en vue de traiter l'instruction interprétable suivante. Suite à cette opération, le code de l'application se présente sous la forme suivante, dans laquelle une ou éventuellement plusieurs instructions d'attente la sont présentes : I, ,1z, ....I; ,.....,la , .....h. Ce code va alors pouvoir être téléchargé dans la carte pour son exécution. Lors de cette exécution, à chaque fois que la carte rencontrera une instruction d'attente la , elle enverra au lecteur un mot d'état d'attente. Dans ce qui précède, on a décrit l'invention dans le cadre d'un objet portatif contenant une machine virtuelle et manipulant des instructions interprétables. L'invention s'applique aussi à un objet portatif dépourvu d'une telle machine virtuelle ; elle s'applique aussi à tout autre dispositif de traitement de données ayant à effectuer, sous un certain délai, une certaine opération, cette opération pouvant consister à fournir une réponse à un autre dispositif avec lequel il coopère, ou bien à effectuer un traitement interne. REVENDICATIONS 1. Procédé pour comptabiliser le temps dans un dispositif de traitement d'information comprenant un processeur (9) et une mémoire (10,14), caractérisé en ce qu'il comprend les étapes consistant à -définir, dans la mémoire, un tableau contenant, pour chaque instruction d'un ensemble d'instructions à exécuter par le processeur, un temps d'exécution de cette instruction ; -exécuter (46), au moyen du processeur, un programme contenu dans la mémoire et comprenant au moins une instruction en ajoutant (43), au moment de l'exécution de chaque instruction, le temps d'exécution de cette instruction à une valeur de cumul de temps. 2. Procédé selon la revendication 1, dans lequel les instructions sont des instructions interprétables écrites dans un langage évolué et l'étape d'exécution du programme comprend une étape d'interprétation de ces instructions interprétables afin de les traduire en des instructions élémentaires écrites dans un langage propre au processeur (9) et exécutées par le processeur. 3. Procédé selon la revendication 1, comprenant les étapes consistant à -comparer (44) au moyen du processeur, lors de l'exécution de chaque instruction, la valeur de cumul de temps à une valeur de référence de temps ; _déclencher une opération (45) à effectuer par le processeur quand la valeur de cumul de temps atteint la valeur de référence de temps. 4. Procédé selon la revendication 3, dans lequel le dispositif de traitement d'information (8) coopère avec un autre dispositif de traitement d'information (1) et la valeur de référence de temps correspond à un temps dans lequel le dispositif de traitement d'information doit transmettre un message audit autre dispositif de traitement d'information et, lorsque la valeur de cumul de temps atteint la valeur de référence de temps, le processeur transmet (45) ledit message audit autre dispositif de traitement d'information. 5. Procédé selon la revendication 1, qui comprend les étapes consistant à -répartir, dans la mémoire, ledit ensemble d'instructions à exécuter par le processeur en plusieurs groupes d'instructions, les instructions de chaque groupe ayant des temps d'exécution voisins les uns des autres ; -définir, dans la mémoire, et pour chaque groupe d'instructions, un temps d'exécution moyen, unique pour toutes les instructions de ce groupe d'instructions. 6. Procédé pour comptabiliser le temps dans un dispositif de traitement d'information comprenant un processeur (9) et une mémoire (10,14), caractérisé en ce qu'il comprend les étapes consistant, dans un outil vérificateur d'instructions, à -définir un tableau contenant, pour chaque instruction d'un programme à exécuter par ledit processeur, un temps d'exécution de cette instruction ; -vérifier (64) chaque instruction du programme en déterminant si cette instruction obéit à au moins une règle déterminée en ajoutant (61), au moment de la vérification de chaque instruction, le temps d'exécution de cette instruction à une valeur de cumul de temps; -comparer (62), au moment de la vérification de chaque instruction, la valeur de cumul de temps à une valeur de référence de temps ; -insérer (63) dans le programme, à un endroit où se trouve l'instruction en cours de vérification, une instruction définissant une opération à effectuer par le processeur, quand la valeur de cumul de temps atteint la valeur de référence de temps; et en ce qu'il comprend l'étape consistant à faire exécuter le programme par le processeur du dispositif de traitement d'information. 7. Procédé selon la revendication 6, dans lequel les instructions sont des instructions interprétables écrites dans un langage évolué et l'étape d'exécution du programme comprend une étape d'interprétation de ces instructions interprétables afin de les traduire en des instructions élémentaires écrites dans un langage propre au processeur et exécutées par le processeur. 8. Procédé selon la revendication 6, qui comprend les étapes consistant à -répartir, dans la mémoire, ledit ensemble d'instructions à exécuter par le processeur en plusieurs groupes d'instructions, les instructions de chaque groupe ayant des temps d'exécution voisins les uns des autres ; -définir, dans la mémoire et pour chaque groupe d'instructions, un temps d'exécution moyen, unique pour toutes les instructions de ce groupe d'instructions. 9. Dispositif de traitement d'information comprenant un processeur (9) et une mémoire(10,14), caractérisé en ce qu'il comprend, dans la mémoire -des moyens pour définir, pour chaque instruction d'un ensemble d'instructions à exécuter par le processeur, un temps d'exécution de cette instruction ; -des moyens de calcul de temps pour ajouter (43), lors de l'exécution, par le processeur, d'un programme comprenant au moins une instruction et au moment de l'exécution de chaque instruction, le temps d'exécution de cette instruction à une valeur de cumul de temps. 10. Dispositif selon la revendication 9, qui comprend, dans la mémoire -des moyens de comparaison pour comparer (44), lors de l'exécution de chaque instruction, la valeur de cumul de temps à une valeur de référence de temps ; -des moyens de déclenchement pour déclencher une opération à effectuer (45) par le processeur quand la valeur de cumul de temps atteint la valeur de référence de temps.