« Fonctionnement d'un ordinateur/Les architectures à capacités » : différence entre les versions

Contenu supprimé Contenu ajouté
Ligne 14 :
 
En effet, accéder aux données de l'objet demande de connaitre son adresse mémoire. Pour cela, il faudra fatalement convertir l'identifiant d'objet en une adresse mémoire. Cette conversion s’effectuera dans la MMU, mais la méthode de conversion dépend de la conception du processeur, aussi il sera difficile de faire des généralités sur le sujet. Toujours est-il que le processeur doit contenir une liste de correspondance entre objet et adresse de celui-ci. On peut préciser que ces techniques s'appuient souvent sur la segmentation. Chaque objet est stocké dans un segment, qui commence à une adresse physique bien précise. Les attributs de l'objet sont stockés dans ce segment, à une place prédéfinie. L'identifiant est alors simplement l'adresse logique, virtuelle, du segment qui contient l'objet. Mais d'autres techniques peuvent être possibles.
 
==Rekursiv==
 
Nous allons commencer par aborder le processeur Rekursiv. Ne soyez pas perturbé par son nom : il ne s'agit pas d'une coïncidence, comme on le verra plus tard. Ce processeur fut inventé par la compagnie Linn Product, un fabricant de matériel Hi-Fi, qui voulait améliorer ses chaînes de production automatisées. Celles-ci fonctionnaient avec un ordinateur DEC VAX assez correct pour l'époque. Cette compagnie avait lancé un grand projet de rajeunissement de sa chaîne de production. Au tout début, le projet consistait simplement à créer de nouveaux outils logiciels pour faciliter le fonctionnement de la chaîne de production. Au cours de ce projet, un langage de programmation orienté objet, le Lingo, fut créé dans ce but. Mais les programmes créés dans ce langage fonctionnaient vraiment lentement sur les DEC VAX de l'entreprise. L'entreprise, qui n'avait pas hésité à créer un nouveau langage de programmation pour ce projet, prit ce problème de performances à bras le corps et décida carrément d'inventer un nouveau processeur spécialement adapté à Lingo. Ainsi naquit le processeur Rekursiv, premier processeur orienté objet de son genre. Rekursiv était au départ prévu pour être utilisé sur des stations de travail Sun 3. Mais malgré ses nombreuses qualités, Rekursiv ne s'est pas beaucoup vendu dans le monde : à peine 20 exemplaires furent vendus. La majorité des acheteurs étaient des chercheurs en architecture des ordinateurs, et rares furent les entreprises qui achetèrent des processeurs Rekursiv. Il faut dire que ce processeur était relativement spécialisé et difficile à utiliser, sans compter que d'autres processeurs concurrents firent leur apparition, comme l'Intel 432. Ce processeur fut donc un échec commercial retentissant, malgré une réussite technique indéniable.
 
Vu de loin, ce processeur ressemble à un processeur tout à fait normal, découpé en quatre grands circuits principaux bien connus :
 
* Numerik : l'unité de calcul ;
* Logik : le séquenceur ;
* Objekt : une MMU orientée objet ;
* et Klock, une unité regroupant des timers et un générateur d'horloge.
 
Le support du paradigme objet était géré par Logik et par Objekt, aussi nous verrons plus en détail leurs possibilités dans la suite de ce tutoriel. Mais nous n'allons pas passer sous silence Numerik et Klock. Klock est chargée de synchroniser les différents composants de ce processeur. Plus précisément, elle contient des timers, des composants permettant de mesurer des durées, et de quoi générer le signal d'horloge du processeur. Ce processeur avait une fréquence d'environ 10 Mhz, ce qui n'était pas si mal pour l'époque.
 
Numerik est le nom donné à l'ALU de ce processeur. Son jeu d'instructions est donc assez limité. On peut néanmoins dire que cette unité de calcul contient un circuit capable d'effectuer des multiplications ainsi qu'un barrel shifter, un circuit capable d'effectuer des instructions de décalage et de rotation. Cette unité de calcul est rattachée à 16 registres 32 bits, rassemblés dans un register file. Numerik est capable de manipuler des nombres de 32 bits. Cette unité de calcul est un peu particulière : elle est formée de petites unités de calcul 4 bits, de marque AMD : des AMD2900, pour être précis. Ces unités de calculs AMD de 4 bits sont reliées entre elles pour former Numerik. Cette technique qui consiste à créer des unités de calcul plus grosses à partir d’unités de calcul plus élémentaires s'appelle en jargon technique du Bit Slicing.
 
Son séquenceur était micro-codé, son Control Store de Rekursiv n'étant autre qu'une mémoire d'environ 64 kibioctets. Elle était accessible en écriture, ce qui fait qu'il était parfaitement possible de reprogrammer le jeu d'instructions du processeur sans restrictions. Cela pouvait même se faire à l’exécution, ce qui pouvait servir à adapter le jeu d'instructions à un langage particulier, voire l'adapter temporairement à un objet que l'on était en train de manipuler. L'ensemble des instructions du processeur (son jeu d'instructions) était donc programmable ! Ce processeur possédait même une petite particularité : on pouvait, de par l'organisation de son micro-code, créer des instructions récursives ! Ainsi, les instructions de copie ou de recherche dans un arbre ou une liste présentes dans son jeu d'instructions étaient codées via ce genre d'instructions récursives.
 
Certaines des instructions du processeur étaient adaptées au paradigme objet et permettaient de gérer plus simplement les diverses fonctionnalités orientées objet au niveau du matériel. Ces instructions étaient toutes micro-codées, bien évidemment. Par exemple, il existait des instructions CREATE, chacune capable de créer un objet d'une certaine classe. Cette instruction n'était autre qu'un constructeur pour un certain type d'objet. Elle avait besoin de certaines données pour fonctionner (sa taille, son type et les valeurs initiales de ses attributs) qui étaient passés par la pile vue ci-dessus. Il existait aussi des instructions de transfert de messages entre objets (comme SEND), des instructions pour accéder à un champ d'un objet localisé sur la pile (GET), pour modifier un champ dans l'objet (PUT), et bien pire encore. On peut signaler que ces instructions ne pouvaient opérer que sur certains types d'objets : certaines instructions ne pouvaient ainsi manipuler que des objets d'une certaine classe et pas d'une autre.
 
Mais ce qui fait que Rekursiv était un processeur orienté objet ne vient pas seulement de son jeu d'instructions : le principal intérêt de Rekursiv tient dans son unité chargée de gérer la mémoire. Les capacités de ce processeur était codées sur 40 bits. Objekt, la MMU, se chargeait de convertir les capacités en adresses mémoires de façon transparente pour les instructions. La MMU stockait diverses informations sur chaque objet : ainsi, la MMU pouvait retrouver l'adresse mémoire de l'objet, son type, et sa taille à partir de l'identifiant. Ces informations étaient stockées dans la mémoire, dans une table segments dédiée. Du fait de l'usage de la segmentation, un objet gardait en permanence la même capacité. On pouvait déplacer l'objet dans la mémoire, son identifiant restait le même (alors que son adresse mémoire changeait). De même, la MMU pouvait décider de déplacer un objet sur le disque dur sans que le programme ne s'en aperçoive.
 
Objekt implémentait un Garbage Collector matériel assez simple, mais suffisamment efficace. Pour rappel, un garbage collector, ou ramasse-miettes, est un programme ou un système matériel qui se charge de supprimer de la mémoire les objets ou données dont on n'a plus besoin. Dans certains langages de programmation comme le C ou le C++ , on est obligé de libérer la mémoire à la main. Ce n'est pas le cas pour certains langages orientés objet, comme JAVA ou Lingo : un garbage collector permet de gérer la mémoire automatiquement, sans demander au programmeur de se fatiguer à le faire lui-même (du moins, en théorie). Ce garbage collector avait souvent besoin de déplacer des objets pour faire un peu de place en mémoire, et compacter les objets ensemble, pour faire de la place. Le fait que les objets soient manipulés avec une capability facilitait énormément le travail du garbage collector matériel.
 
Plus d’informations sur ce jeu d'instructions dans le lien suivant : http://www.ncl.ac.uk/computing/research/seminars/pdfs/chapters/129.pdf.