« Fonctionnement d'un ordinateur/Les architectures à capacités » : différence entre les versions
Contenu supprimé Contenu ajouté
Ligne 36 :
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
==Conclusion==
| |||