Les premiers pas

Le système d'exploitation CAP est destiné à fournir un environnement dans lequel les programmes des utilisateurs peuvent s'exécuter et dans lequel ils peuvent tirer pleinement parti des capacités matérielles de la machine. Il est également destiné à constituer en soi un exemple de l'exploitation de ces capacités.

Le système d'exploitation, comme tous les autres programmes du CAP, se compose d'un ensemble de procédures protégées avec des liens entre elles fournis par le microprogramme. En particulier, le microprogramme prend en charge l'instruction ENTER, par laquelle les procédures protégées sont entrées et sorties, et la pile C sur laquelle les paramètres de type capacité sont passés. Par convention, les paramètres numériques sont passés dans les registres B1 à B5 du processeur.

Chaque procédure protégée est un objet autonome et le microprogramme ne fait aucune supposition quant au langage de programmation dans lequel les diverses procédures protégées sont écrites. A condition qu'elles soient conformes à l'interface décrite ci-dessus, les procédures protégées constituant un programme complet peuvent être écrites dans une variété de langages de programmation. On a pensé à un moment donné que certaines des procédures constituant le système d'exploitation seraient écrites en ALGOL 68C et d'autres en BCPL ; en fait, comme il s'est avéré, elles sont toutes écrites en ALGOL 68C, bien qu'un certain nombre d'autres procédures protégées étroitement associées au système d'exploitation - comme un paginateur - soient écrites en BCPL. Du point de vue du microprogramme, toutes les procédures protégées ont le même état, celles constituant le système d'exploitation n'étant en aucune façon différenciables.

Comme les procédures protégées sont reliées entre elles par des instructions ENTER et RETURN et non par le mécanisme d'appel de procédure du langage dans lequel elles sont écrites, chaque procédure protégée est compilée comme un programme complet. Il faut trouver des moyens - par exemple en incluant des sections de code machine - pour effectuer la connexion. Une conséquence importante de l'affirmation ci-dessus selon laquelle les procédures protégées sont toutes des programmes distincts est que l'une d'entre elles peut être recompilée sans affecter les autres. Cela contribue grandement à la modularité du système résultant.

Le fait qu'il n'existe aucune exigence selon laquelle toutes les procédures protégées constituant un programme doivent être écrites dans le même langage de programmation de haut niveau signifie que les fonctions de vérification de type au moment de la compilation normalement disponibles dans ALGOL 68C (par exemple) ne sont pas disponibles pour les appels d'une procédure protégée à une autre. Étant donné que les interfaces entre les procédures protégées sont simples et clairement définies, ce manque n'a pas été ressenti de manière notable lors du débogage du système d'exploitation. En fait, les vérifications au moment de la compilation effectuées par le compilateur ALGOL 68C dans les procédures protégées individuelles et les vérifications au moment de l'exécution effectuées par le matériel de capacité fournissent ensemble un ensemble de vérifications beaucoup plus complet que celui dont bénéficie normalement un programmeur lorsqu'il développe un programme complexe.

Processus et leur gestion

Le système d'exploitation CAP prend en charge un nombre modéré et fixe de processus, dont certains fournissent des services du système d'exploitation et d'autres sont attribués aux utilisateurs. Les processus sont tous gérés par le coordinateur principal exécutant des fonctions de planification et de répartition, exécute certaines fonctions liées à la gestion des interruptions et prend en charge un système de messages interprocessus. Certains services du système d'exploitation sont fournis par des procédures protégées saisies par le processus utilisateur. D'autres sont fournis par des processus système activés par des messages. Étant donné que pour envoyer un message, un processus utilisateur entre dans une procédure protégée, l'interface est la même dans les deux cas et le programmeur n'a généralement pas besoin de savoir par quelle technique un service particulier est fourni. Tous les processus utilisateur et la plupart des processus système s'exécutent dans une mémoire virtuelle dans laquelle l'unité d'échange est le segment, à l'exception des segments très volumineux étant traités par une technique de fenêtrage. Les processus système ne s'exécutant pas dans la mémoire virtuelle sont ceux prenant en charge la mémoire virtuelle elle-même. Il existe un système de fichiers très intimement lié à la mémoire virtuelle. Les segments sont échangés vers et depuis leur emplacement de résidence dans le système de classement, plutôt que depuis une copie sur un disque logiquement séparé. Il en résulte que les notions de fichier et de segment sont équivalentes dans le même sens que dans MULTICS.

Il a été dit plus haut que les fonctions disponibles pour un processus sont toutes représentées dans sa liste de ressources de processus (PRL). L'état du processus, tant au niveau matériel que logiciel, est enregistré dans le segment appelé base de processus pour lequel il existe une capacité placée par convention en première position dans la PRL. Les modifications apportées aux ressources du processus ou à son état impliquent des changements soit de sa PRL, soit de sa base de processus, soit des deux. Chaque processus possède une capacité d'entrée pour sa propre instance d'une procédure protégée appelée ECPROC ayant le privilège requis pour effectuer ces changements. ECPROC fournit également une interface aux fonctions du coordinateur maître. Le client d'ECPROC n'a pas besoin de savoir si un service particulier est exécuté dans ECPROC ou si ECPROC appelle le coordinateur maître. La politique a été de fournir des services entièrement dans ECPROC chaque fois que cela était possible, puisque le coordinateur maître lui-même est sérialisé et ne peut exécuter des services que pour un processus à la fois. De plus, le coordinateur est incapable de prendre des pièges de mémoire virtuelle et ne peut donc toucher que des éléments dont on sait qu'ils se trouvent dans la mémoire principale. L'ECPROC n'est pas soumis à cette restriction.

Certains services de coordination (cette expression sera utilisée indifféremment pour désigner ceux fournis par ECPROC ou par le coordinateur proprement dit) sont accessibles à tous les appelants. D'autres, comme la création de nouvelles capacités, sont hautement privilégiées et ne sont disponibles que dans un ou deux domaines de protection. En général, tout appel à ECPROC doit être supporté par la présentation d'une capacité logicielle donnant l'autorité de demander un service particulier. Conformément à l'usage courant, les appels à ECPROC seront parfois qualifiés de primitives.

Gestion des capacités

L'architecture CAP est telle que diverses opérations sur les capacités sont effectuées de manière pratique par le coordinateur. ECPROC fournit une interface adaptée à ces opérations. Le processus de présentation doit posséder la capacité logicielle appropriée et il est pratique de faire référence à ces capacités en tant que capacités d'autorisation. Les opérations sur les capacités effectuées par le coordinateur sont la création de capacités, la modification de capacités existantes et l'extraction à partir de capacités existantes d'informations au-delà de celles étant normalement disponibles pour les utilisateurs. De plus, il existe une opération qu'ECPROC peut effectuer au nom du système de permutation ayant pour effet de désactiver toutes les instances d'une capacité pour un segment étant sur le point d'être permuté, ou inversement, de les rétablir après son permuté. Ce service est une fonction de gestion d'entreposage plutôt qu'une fonction de gestion des capacités.

Communication interprocessus

Le système de communication interprocessus concerne le transfert d'informations et la synchronisation entre les processus. Il existe des primitives WAIT et WAKE-UP de type habituel ainsi que des dispositions pour transmettre des messages d'un processus à un autre. Les messages sont de quatre types : messages nuls, messages de données, messages de segment et messages complets. Un message nul consiste simplement en un signal de synchronisation. Un message de données contient quatre mots de données. Un message de segment contient une capacité pour un segment de mémoire. Un message complet contient à la fois quatre mots de données et également une capacité pour un segment de mémoire. Les messages autres que les messages nuls peuvent exiger une réponse. Si un processus est en état d'attente, il sera réveillé lorsqu'un message lui sera adressé.

L'envoi et la réception de messages sont assurés par une structure de données appartenant au coordinateur et appelée canal de messages. Chaque canal contient une déclaration sur le type de message pour lequel il peut être utilisé et les autres types de messages ne peuvent pas être envoyés ou reçus sur ce canal particulier. ECPROC est responsable de la configuration et de la suppression des canaux. Cependant, l'utilisateur n'utilise généralement pas ECPROC directement à ces fins, mais passe plutôt par une autre procédure protégée appelée SETUP. L'avantage de procéder de cette manière est que SETUP est responsable de l'administration d'un schéma externe de noms de canaux de messages inconnu du coordinateur principal.

Les messages en transit sont enregistrés dans un segment de tampon unique étant commun à tous les processus. ECPROC peut utiliser ce segment pour le compte de tous les processus, soit pour y insérer un message, soit pour en supprimer un, sans nécessiter de verrouillage spécial. Cela a été réalisé grâce à une utilisation prudente d'instructions machine indivisibles. À l'extrémité réceptrice du canal, une fonction de recherche est fournie pour permettre à un processus de déterminer combien de messages entrants attendent d'être acceptés. Une erreur est signalée si une tentative d'acceptation d'un message est faite alors qu'il n'y en a pas ; il incombe au programme récepteur d'utiliser la primitive WAIT lorsque cela est approprié. Aucune mesure n'est prise pour garantir qu'un processus destinataire est réveillé uniquement si le message envoyé est un message pour lequel il est connu pour avoir une capacité de réception dans son domaine de protection actuel ; les processus doivent donc être prêts à être réveillés dans des circonstances où ils n'ont aucune action à entreprendre.

Dans le cas de messages nécessitant une réponse, cela dépend de l'entrée ECPROC utilisée si le processus émetteur est immédiatement arrêté pour attendre la réponse, ou s'il continue à s'exécuter ; dans ce dernier cas, il effectuera probablement une demande ultérieurement et passera peut-être en état d'attente. Dans le cas de messages sans réponse, ce choix n'existe pas. Les messages sans réponse sont largement utilisés dans des circonstances où une action de nettoyage ou une action visant à préserver la cohérence est requise, mais dans lesquelles la progression ultérieure de l'expéditeur ne dépend pas du résultat.

Réservation de segments et verrouillages

Certains segments sont accessibles à un nombre considérable de processus, généralement au moyen d'instances de la même procédure protégée. Par exemple, dans le système de classement, un segment contenant un répertoire de fichiers est traité de cette manière. Le coordinateur principal fournit une fonction de réservation pour contrôler l'accès aux segments partagés. Cela repose sur un mécanisme de recherche autorisant plusieurs lecteurs d'un segment mais un seul rédacteur. La primitive de réservation standard provoque le blocage du processus appelant si le segment requis est déjà réservé par un autre processus, mais un appel alternatif est disponible réservant le segment si possible et sinon, donnera un code de retour sans arrêter le processus. Il existe une règle de programmation selon laquelle les segments partagés doivent être réservés avant d'être consultés, mais cette règle n'est pas appliquée par le logiciel ou le matériel. Cela ne s'est pas avéré présenter un risque sérieux dans la pratique car les processus en compétition pour un segment partagé s'exécutent généralement dans le même morceau simple de code partagé.

Gestion des interruptions périphériques

Le coordinateur est chargé de réveiller le processus approprié lorsqu'une interruption périphérique se produit. L'utilisation des périphériques est contrôlée par des capacités mais, pour réclamer les interruptions d'un périphérique particulier, le détenteur de la capacité appropriée doit informer le coordinateur principal qu'il la possède ; sinon, le coordinateur principal ne sait pas où envoyer les interruptions. Si une capacité d'accès à un périphérique particulier devait être possédée par plus d'un processus, une confusion en résulterait. On évite cela en plaçant les capacités des périphériques sous la garde de procédures protégées appropriées.

Gestion des interruptions, des erreurs et des attentions.

Les interruptions sont essentiellement des interruptions internes et sont générées dans le microprogramme. Les erreurs sont générées dans un programme. Dans le système CAP, les interruptions et les erreurs - collectivement appelées défauts - sont traitées de manière très similaire par une routine faisant partie d'ECPROC. En cas d'erreur, le programme entre dans ECPROC en exécutant une instruction ENTER avec un paramètre approprié. Dans le cas d'un piège, une entrée dans le coordinateur maître est effectuée directement par le microprogramme qui entre alors dans ECPROC, mais le code est écrit de manière à simuler l'effet d'une entrée de manière normale au moyen d'une instruction ENTER.

ECPROC vérifie d'abord si un piège de mémoire virtuelle ou un piège résultant d'une tentative d'entrée dans une procédure protégée venant d'être récupérée du système de fichiers et nécessitant une génération s'est produit. Ces pièges se produisent de manière routinière et doivent être traités efficacement. ECPROC lance l'action nécessaire et, en temps voulu, rend le contrôle directement au programme de manière à ce que l'instruction fautive soit réexécutée. Dans le cas d'autres erreurs, ECPROC place une marque dans le cadre de la pile C appartenant à la procédure dans laquelle l'erreur s'est produite et dépose une description de l'erreur dans un emplacement standard. Il exécute ensuite une instruction RETURN, après avoir modifié au préalable le lien dans le cadre de la pile C de manière à ce que le contrôle passe à un emplacement spécifique dans le premier segment de programme de la procédure défaillante. On suppose que le programmeur y aura placé une routine capable de traiter de manière appropriée toutes les erreurs pouvant survenir. Il incombe également à cette routine de supprimer la marque placée sur la pile et elle le fait en faisant un appel approprié à ECPROC.

La description ci-dessus est incomplète car il peut arriver que, lorsque ECPROC vient marquer la trame appartenant à la procédure défaillante, il découvre que celle-ci est déjà marquée. Ce sera le cas si la panne s'est produite alors qu'une panne antérieure était en cours de traitement. Dans ces cas-là, ECPROC descend dans la pile jusqu'à trouver une trame non marquée. Il la marque puis modifie les liens sur la pile de sorte que, lors de l'exécution de l'instruction RETURN, le contrôle passe à la procédure correspondant à la trame venant d'être marquée, en contournant les procédures intermédiaires. Ainsi, si une procédure ne peut pas gérer une panne survenue en son sein, une panne est générée dans la procédure qui l'a appelée ; si cette procédure ne peut pas gérer la panne, alors une panne est générée dans son propre appelant, et ainsi de suite.

On se souviendra que les pièges de mémoire virtuelle ne peuvent pas être traités lorsque le coordinateur maître est en cours d'exécution. Afin d'éviter que la pile C ne soit résidente en permanence, il est prévu que, lorsque l'entrée dans ECPROC a lieu à partir du coordinateur principal, l'espace prévu à cet effet dans la base de processus soit utilisé pour le cadre de la pile C. Il y a de la place pour trois cadres de ce type dans chaque base de processus et il peut être démontré que c'est le nombre maximum qui sera nécessaire.

Les attentions sont générées par un utilisateur tapant un caractère spécifique sur un terminal, ce caractère étant reconnu pour ce qu'il est par le processus responsable de ce terminal. Les attentions provoquent un transfert obligatoire du contrôle vers un endroit spécifié dans la procédure en cours d'exécution lorsque l'attention est générée. L'implémentation est très similaire à celle utilisée pour les défauts.

Les attentions ont des degrés de gravité variables. Elles peuvent être réinitialisées par un appel à ECPROC. Cet appel doit être pris en charge par une capacité d'autorisation suffisamment puissante pour permettre la réinitialisation de l'attention en question. La procédure dans laquelle les processus utilisateur s'exécutent initialement, à savoir STARTOP, dispose d'une capacité d'autorisation permettant de réinitialiser toute attention. Les programmes de commande ont une capacité d'autorisation légèrement moins puissante et les programmes exécutés sous eux ont des capacités encore moins puissantes. Si une procédure tente de réinitialiser une attention avec une capacité d'autorisation insuffisamment puissante, le contrôle revient à l'appelant de cette procédure qui peut alors à son tour tenter de réinitialiser l'attention. Finalement, une procédure sera atteinte avec une capacité d'autorisation suffisamment puissante pour réussir. Dans le cas d'une attention de gravité maximale, il s'agira de STARTOP et l'effet sera de mettre fin à la session de l'utilisateur.

Le système de mémoire virtuelle

Un processus appelé le gestionnaire de magasin d'entreposage (Real Store Manager) est responsable de l'introduction des segments dans la mémoire principale lorsqu'ils sont nécessaires et de la décision des segments à échanger afin de leur faire de la place. Il existe une capacité pour chaque segment échangeable dans l'un des segments de capacité du coordinateur principal. Dans le cas d'un segment chargé dans la mémoire principale, la capacité a sa forme normale. Si le segment n'est pas dans la mémoire principale, la capacité a une forme spéciale et est alors connue sous le nom de capacité de sortie. Si un processus tente d'utiliser le segment, une interruption se produit pendant le cycle de chargement de la capacité lorsque la capacité de sortie est rencontrée. L'interruption est signalée au coordinateur principal en informant ECPROC. ECPROC découvre que l'interruption est due à un segment hors de la mémoire principale et envoie un message au gestionnaire de la mémoire réelle pour lui demander de le charger. Le processus d'envoi attend dans ECPROC qu'une réponse soit reçue, puis réessaye l'instruction ayant échoué. Étant donné que le véritable responsable du magasin aura désormais chargé le segment manquant et converti la capacité de sortie en une capacité normale, l'instruction réussira. Inversement, lorsque le véritable responsable du magasin provoque l'échange d'un segment afin de faire de la place pour un autre segment, il convertit la capacité du premier segment en capacité de sortie et invalide ainsi toutes les entrées dépendantes pouvant se trouver dans le magasin de capacités.

L'adresse de disque d'un segment n'étant pas dans la mémoire principale est enregistrée dans la capacité de sortie le représentant. Il existe en outre une structure de données dans laquelle sont enregistrés le début, la fin et l'adresse de disque de chaque segment actuellement dans la mémoire principale. A la réception d'un message indiquant qu'un piège de mémoire virtuelle s'est produit, le gestionnaire de magasin réel inspecte cette structure de données afin de déterminer s'il y a de la place pour introduire le segment manquant sans remplacer aucun autre segment ; si tel est le cas, il le fait et met à jour la structure de données en conséquence. S'il n'y a pas de place, le gestionnaire de magasin réel consulte un algorithme pour obtenir des instructions sur le ou les segments à remplacer. Des informations sont disponibles pour savoir si un segment a été écrit pendant qu'il se trouvait dans la mémoire principale ; si ce n'est pas le cas, la copie sur le disque est inutile et l'opération de remplacement ne revient pas à rendre l'espace occupé par le segment disponible pour réutilisation. Les opérations d'écriture d'un segment sur le disque et de lecture du segment à partir du disque sont effectuées par une procédure protégée appelée par le gestionnaire de magasin réel. Cette procédure dispose d'une carte de disque dont la gestion sera décrite ci-dessous. Le fonctionnement du gestionnaire de magasin réel est suspendu jusqu'à ce que le transfert du disque soit terminé.

Le plus grand segment unique que le gestionnaire de magasin réel est prêt à gérer est long de 32 000 mots. Il est possible d'accéder à des segments plus grands par fenêtrage. Le fenêtrage fournit essentiellement une fonction par laquelle un segment peut être assimilé à une partie d'un autre segment ou, pour le dire plus naturellement, à une partie d'un fichier. L'accès séquentiel à de longs fichiers est obtenu en ouvrant une succession de fenêtres sur eux. Cela se fait généralement en ayant deux fenêtres existantes à la fois afin de fournir l'effet de double mise en mémoire tampon.

Le gestionnaire de magasin réel fournit un certain nombre de fonctions diverses. L'une d'entre elles permet au programmeur de s'assurer qu'à un moment donné la copie sur disque d'un segment spécifié est à jour ; si le segment n'est pas dans la mémoire principale, cela n'implique aucune action de la part du gestionnaire de magasin réel, mais s'il est dans la mémoire principale et a été écrit, une nouvelle copie doit être faite. Cette fonction est principalement utilisée en relation avec les répertoires de fichiers et les objets similaires. Une autre fonctionnalité permet au programmeur de provoquer l'échange d'un segment, par exemple lorsqu'il sait que le segment ne sera plus nécessaire dans un avenir proche.

Comme mentionné ci-dessus, le gestionnaire de magasin réel conserve une structure de données dans laquelle sont enregistrées l'adresse du disque, la taille et les détails d'accès de chaque segment concerné. Cette table est mise à jour à partir des informations reçues du gestionnaire de magasin virtuel décrit dans la section suivante.

Gestionnaire de magasin virtuel

Le gestionnaire de magasin réel a pour tâche, comme nous venons de le décrire, de gérer l'échange de segments actuellement utilisés vers et depuis le disque. Les segments peuvent être, et sont souvent, partagés entre différents processus. La condition pour retirer un segment du régime du gestionnaire de magasin réel est qu'aucun processus actuel ne possède de capacité pour celui-ci. Ce niveau d'administration est du ressort du gestionnaire de magasin virtuel.

Chaque fois qu'il est nécessaire d'émettre un processus avec une capacité pour un segment, un message contenant le nom à long terme du segment tel qu'il est utilisé par le système de classement est envoyé au gestionnaire de magasin virtuel. Le gestionnaire de magasin virtuel découvre si le segment se trouve dans la mémoire virtuelle actuellement active, c'est-à-dire si une capacité pour celui-ci existe déjà dans l'un des segments de capacité du coordinateur. Dans le cas contraire, le gestionnaire de magasin virtuel appelle le gestionnaire de magasin réel pour provoquer la construction et l'insertion d'une capacité (outform). Dans les deux cas, le gestionnaire de magasin virtuel renvoie à son appelant le spécificateur de la capacité en question.

Le gestionnaire de magasin virtuel associe à chaque segment dont il est responsable un décompte de référence étant simplement un décompte du nombre de processus possédant une capacité pour le segment. Le gestionnaire de magasin virtuel incrémente le décompte de référence d'une unité chaque fois qu'un nouveau processus reçoit une capacité pour le segment et le décrémente d'une unité chaque fois qu'il reçoit un message indiquant qu'une capacité n'est plus requise par l'un des processus l'utilisant. Ce message ne nécessite pas de réponse, mais si le résultat est que le décompte de référence devient nul, alors le système de gestion à long terme est contacté pour vérifier si le segment lui est connu. Si ce n'est pas le cas, des mesures sont prises pour éliminer toute connaissance du segment du système.

Le gestionnaire de magasin réel doit nécessairement résider en permanence dans la mémoire principale. Le gestionnaire de magasin virtuel n'a pas besoin d'être résident en permanence. Dans la mise en oeuvre originale du système d'exploitation CAP, les fonctions du gestionnaire de magasin virtuel et du gestionnaire de magasin réel ont été combinées. Leur séparation a réduit de manière significative la quantité de matériel devant résider en permanence.

Gestion à long terme

Noms internes du système. Aucune des informations détenues par le gestionnaire du magasin réel ou le gestionnaire du magasin virtuel ne persiste d'une exécution du système à l'autre. La gestion du matériel persistant est entre les mains d'une procédure protégée connue sous le nom de gestionnaire de noms Eternel du système (SINMAN). Les noms internes du système sont des entiers restant associés aux objets qu'ils représentent tant que ces objets existent. Pour des raisons pratiques, le nom interne du système d'un objet est considéré comme l'adresse à laquelle l'objet commence sur le disque.

Afin de discuter du fonctionnement de SINMAN, il est d'abord nécessaire de considérer les types d'objets permanents que le système prend en charge. Il en existe trois : les segments, étant simplement à ce niveau des blocs d'informations non interprétées ; les segments de répertoire, reliant les noms de texte aux noms internes du système ; les blocs de description de procédure, étant des modèles pour la construction de procédures protégées et contenant les noms internes du système des objets allant les constituer.

Les répertoires et les blocs de description de procédure ont tous deux la propriété que l'occurrence d'un nom interne du système dans l'un d'entre eux est une raison suffisante pour maintenir l'existence de l'objet correspondant. La tâche principale de SINMAN est de maintenir une liste de ces noms, ainsi que les noms d'autres objets devant également être maintenus en existence parce qu'ils se trouvent dans la PRL d'un processus du système. Parallèlement à cela, il doit supprimer de la liste les objets cessant d'appartenir à l'une des catégories ci-dessus. La liste est connue sous le nom de répertoire SIN. Elle est indexée par le nom interne du système et contient des compteurs de références (indiquant le nombre de références à chaque nom interne du système dans les répertoires ou les blocs de description de procédure) ainsi que des informations sur le type et la taille de l'objet concerné. Le répertoire SIN est mis à jour lorsque de nouveaux objets sont créés, lorsque des capacités pour des objets sont insérées dans des répertoires ou des blocs de description de procédure, ou lorsqu'ils sont supprimés.

SINMAN a une fonction secondaire étant logiquement indépendante de la fonction principale venant d'être décrite et ayant peut-être pu être mieux exécutée par une procédure séparée. Il s'agit d'émettre des capacités pour des objets particuliers de la liste lorsqu'un client dûment autorisé le demande. De telles demandes sont faites en citant le nom interne du système. Certaines capacités, par exemple celles des segments du système d'exécution ALGOL 68C, sont utilisées par de nombreuses procédures protégées, mais pas toutes. Il est donc tout à fait possible que lorsqu'un processus demande une capacité pour un objet, il en possède déjà une dans sa PHL. Pour chaque processus, un index est maintenu reliant les entrées de la PRL aux noms internes du système. Lorsqu'un nom interne du système lui est présenté et qu'on lui demande une capacité pour l'objet correspondant, la première chose que fait SINMAN est de consulter l'index ; si le nom de l'objet s'y trouve, il fournit la capacité appropriée. Si ce n'est pas le cas, SINMAN envoie un message au responsable du magasin virtuel pour lui demander des informations permettant de construire la capacité. Si le responsable du magasin virtuel n'a aucune connaissance de l'objet, il demandera alors au responsable du magasin réel de générer les informations requises. Dans tous les cas, le gestionnaire du magasin virtuel renvoie les informations à SINMAN procédant à la construction de la capacité, en consultant le répertoire SIN pour savoir si l'objet est un segment, un répertoire ou un bloc de description de procédure.

SINMAN supprime immédiatement du répertoire SIN sans autre formalité tout objet de type segment dont le compteur de référence tombe à zéro et ne se trouvant pas dans la mémoire virtuelle actuellement active. Les objets de type répertoire ou de type bloc de description de procédure peuvent contenir en eux-mêmes des références à d'autres objets. Avant de les supprimer, il est donc nécessaire de les analyser et de décrémenter les compteurs de référence de tout autre objet référencé. Même ainsi, l'effet de la suppression peut être de laisser une ou plusieurs boucles détachées. La seule façon de détecter l'existence de telles boucles détachées et de récupérer l'espace qu'elles occupent est d'utiliser une forme de ramasse-miettes à analyse. En conséquence, un processus séparé a été fourni implémentant un algorithme de ramasse-miettes et s'exécutant lentement en arrière-plan.

Au fur et à mesure qu'un processus s'exécute, il est susceptible de demander de temps à autre la création de nouveaux segments et sa PRL aura tendance à se remplir. Un processus peut cependant perdre l'accès aux segments pour lesquels il a des capacités dans sa PRL. Cela se produit, par exemple, si toutes les capacités contenues dans les segments de capacité appartenant au processus et définies en termes d'une capacité particulière dans la PRL sont écrasées par des instructions MOVECAP. Dans ce cas, l'emplacement du PRL peut être réutilisé. Cependant, la seule façon de savoir si cela est possible est d'effectuer une opération de récupération de place. Cette opération est tout à fait différente de la récupération de place décrite dans le dernier paragraphe et est effectuée par une procédure appelée PRLGARB. PRLGARB est automatiquement entré si le PRL est pleine, mais ses services peuvent être demandés explicitement. Il identifie tous les emplacements du PRL n'étant référencés dans aucun des domaines de protection représentés sur la pile C. PRLGARB a accès à l'index reliant les entrées de la PRL aux noms internes du système et supprime les entrées de celui-ci si nécessaire ; il communique également par message avec le gestionnaire de magasin virtuel pour indiquer que certaines capacités ne sont plus utilisées dans le processus.

Programme de commande et interface utilisateur

Il a été indiqué qu'il existe un nombre fixe de processus utilisateur. Ceux-ci sont créés lors de la génération du système et sont équipés de toutes les fonctionnalités standard requises pour l'exécution des processus utilisateurs. Au départ, chaque processus s'exécute dans sa propre instance d'une procédure protégée appelée STARTOP. STARTOP a accès à divers canaux de messages et à une capacité lui permettant d'accéder au répertoire de fichiers maître. Lorsque le système est initialisé, chaque instance de STARTOP envoie un message à un processus appelé Initiator demandant une tâche à effectuer, puis s'arrête en attendant une réponse. Initiator est en communication avec l'ensemble des processus gérant les terminaux interactifs et, lorsqu'un utilisateur tape un caractère particulier sur un terminal inactif, Initiator reconnaît l'action comme une demande de connexion. Il est alors en mesure de répondre à l'un des messages d'une instance de STARTOP, en supposant qu'il y en ait un en attente. La réponse comprend le numéro du terminal concerné et STARTOP obtient une capacité d'entrée pour une procédure protégée par laquelle il peut communiquer avec ce terminal. Il envoie ensuite un prompt à l'utilisateur lui demandant son identificateur. Muni de celui-ci, il entre dans une procédure protégée appelée LOGIN, demandant à l'utilisateur de saisir son mot de passe.

LOGIN vérifie alors que l'identificateur de l'utilisateur et le mot de passe qu'il vient de saisir se trouvent dans le fichier des utilisateurs autorisés et récupère dans ce même fichier le nom du programme de commande à saisir. Il s'agit normalement du programme de commande standard du système. LOGIN rend la main à STARTOP récupérant dans le répertoire de fichiers maître une capacité pour le programme de commande et une autre pour le répertoire de fichiers de l'utilisateur. STARTOP entre dans le programme de commande, en passant cette dernière capacité en paramètre. L'utilisateur est alors en état de commande et tout ce qu'il tape est traité comme une commande.

Certains processus système s'exécutent exactement comme s'il s'agissait de processus utilisateur. Le processus de désembouage est l'un d'entre eux ; il possède un programme spécial appelé DESPOOL lui étant associé de la même manière que le programme de commande à un utilisateur ordinaire. Le processus de désembouage est cependant activé automatiquement par Initiator.

Il existe à la disposition de tous une procédure protégée appelée RUN permettant à un processus utilisateur d'activer directement Initiator. Il est ainsi possible pour un processus utilisateur de démarrer un processus indépendant s'exécutant initialement dans une procédure protégée pour laquelle le processus utilisateur fournit une capacité.

Le programme de commande standard est basé sur une vue particulière des fonctions qu'un tel programme doit exécuter. Il appellera des commandes dont les noms sont tapés par l'utilisateur et leur transmettra le résidu de la ligne de commande sous forme de chaîne de paramètre. Il est également capable de réinitialiser toutes les attentions que l'utilisateur du terminal peut avoir créées, lui permettant ainsi de forcer un retour à l'état de commande. Normalement, lors de la recherche du programme pour exécuter une commande, le programme de commande va d'abord dans le répertoire de fichiers de l'utilisateur, puis dans la bibliothèque de commandes, mais il est possible de modifier cela et d'inclure d'autres répertoires dans la séquence.

On a pensé que si le programme de commande devait toujours décoder le paramètre d'une commande, une rigidité indésirable serait imposée au format des lignes de commande. Il est néanmoins souhaitable d'avoir une certaine normalisation de fait et le compromis suivant a été adopté. Le programme de commande entre dans la procédure exécutant la commande ayant été appelée, en passant comme paramètres une capacité pour un segment contenant la ligne de commande complète et une capacité d'entrée pour une procédure protégée connue sous le nom de PARMS. PARMS fournit une variété de fonctionnalités pour le décodage de la ligne de commande ; il peut rechercher des paramètres de position et de mot-clef, effectuer une conversion décimale en binaire et ouvrir des fichiers. Il est entièrement à la discrétion de l'auteur d'un programme d'exécuter une commande particulière s'il utilise ou non PARMS, mais en pratique il est rare qu'il ne le fasse pas.

Il est souvent pratique pour les programmes exécutant des commandes de recevoir leurs paramètres dans des registres machine plutôt que sous la forme de chaînes de caractères. La plupart de ces programmes sont, en fait, capables d'accepter des paramètres de l'une ou l'autre manière. Une convention a été établie selon laquelle le contenu d'un registre particulier indique quelle méthode est utilisée.

A la fin d'une commande, le contrôle revient au programme de commande et l'utilisateur est de nouveau en mode commande. Il faut se rappeler que le programme de commande est une procédure protégée ayant été initialement saisie à partir de STARTOP. Lorsque l'utilisateur tape une commande LOGOUT, le programme de commande est amené à exécuter une instruction RETURN renvoyant le contrôle à STARTOP. STARTOP envoie un message approprié au terminal enregistrant le fait que la session est terminée. Il envoie ensuite un message à l'initiateur demandant un travail supplémentaire et, après avoir effectué une récupération de mémoire de sa propre PRL, redevient inactif jusqu'à ce qu'il reçoive une réponse.