<figure><img src="image_1.png" /></figure>

HAL
open science

# D'une architecture de machine a domaines

Claude Kaiser, Didier Lanciaux, Bernard Martin

► To cite this version:

Claude Kaiser, Didier Lanciaux, Bernard Martin. D'une architecture de machine a domaines. [Rapport de recherche] IRIA-RR-182, IRIA. 1976, pp.26. hal-04716380

HAL Id: hal-04716380

https://inria.hal.science/hal-04716380v1

Submitted on 1 Oct 2024

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_2.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
RIA

laboria

Institut de Recherche
d'Informatique
et d'Automatique

Domaine de Voluceau
Rocquencourt
B. P. 5 78150 - Le Chesnay
France
Tél.: 954 90 20

laboratoire de recherche
en informatique
et automatique

DÉFINITION
D'UNE ARCHITECTURE
DE MACHINE A DOMAINES

<figure><img src="image_3.png" /></figure>

Rapport de Recherche N° 182

Août 1976
# DÉFINITION D'UNE ARCHITECTURE DE MACHINE A DOMAINES

C. Kaiser*, D. Lanciaux, B. Martin

## Résumé :

Le partage des ressources dans un système nécessite des mécanismes qui permettent de contrôler le transfert d'information entre les utilisateurs. Généralement les mécanismes câblés nécessitent d'être complétés à l'aide de mécanismes programmés et ne permettent pas de résoudre de manière satisfaisante tous les problèmes de protection. Ce rapport propose des mécanismes basés sur les notions de descripteur et de type. Ils permettent d'assurer d'une manière uniforme le contrôle de l'accès à l'information et de construire le système par niveaux d'abstraction.

## Abstract :

Sharing of resources needs a set of mechanisms to control transfer of information among users. Generally the mechanisms proposed at the hardware level need to be completed by software and do not permit all the problems of protection to be solved in a satisfactory way. In this paper we propose some mechanisms based on the notions of type and descriptor. They allow access control to information to be assumed in a uniform way and the system to be constructed by levels of abstraction.

* également Maître de Conférences au CNAM.
# PLAN

1. But et définition des architectures à domaines

2. Eléments fondamentaux du système

2.1 Notion de descripteur

2.2 Type segment et type D-liste

2.3 Notion de domaine

2.4 Extension de type

3. Adressage des objets du contexte

3.1 Notion de contexte

3.2 Matérialisation du contexte

3.3 Rappel des schémas d'adressage existants

3.4 Schéma d'adressage proposé

3.5 Exemples d'utilisation de l'adressage

4. Gestion de la mémoire virtuelle et incidence sur le calcul d'ac

4.1 Segments en mémoire principale

4.2 Segments en mémoire secondaire

5. Exemple de code opération

5.1 Format des instructions

5.2 Opérations sur les descripteurs

5.3 Opérations de commutation de contexte

5.4 Opérations de branchement à l'intérieur d'un contexte
# 1. But et définition des architectures à domaines

La protection est le terme générique désignant l'action des mécanismes câblés et programmés qui ont pour rôle de contrôler l'accès aux entités présentes dans un système. Leur but n'est pas d'empêcher la production des erreurs, mais seulement d'empêcher leur incidence sur les entités protégées. Cet aspect est important car il permet la décomposition du système en sous-systèmes, tout en assurant que les erreurs qui peuvent survenir à un niveau donné n'auront pas d'incidences sur les autres niveaux. La limitation de la propagation des erreurs dans le système facilite donc le partage des informations et la localisation des erreurs. On appelle agents les entités du système capables de produire ou de propager des erreurs, et dont on veut contrôler les actions (exemple : les processus), et objets les entités dont on souhaite contrôler l'utilisation (exemple : les segments). L'ensemble des opérations qu'un agent peut effectuer sur un objet est appelé pouvoir de l'agent sur l'objet et définit la relation entre cet agent et l'objet. L'ensemble de toutes les relations permises entre agents et objets définit, à tout instant, l'état de protection du système.

Le problème du contrôle d'accès peut être résolu de deux façons selon que l'on emploie des listes de contrôle d'accès ou des descripteurs :

- la liste de contrôle d'accès qui associe à chaque objet la liste des agents et leur pouvoir sur cet objet,

- le descripteur (ou capability) qui pour un agent donné spécifie le pouvoir possédé par cet agent sur l'objet.

Le contrôle des objets par les descripteurs, qui est celui adopté, ici, permet une gestion décentralisée des modifications de l'état de protection du système.

La limitation de la propagation des erreurs qui est un des buts assignés à la protection est facilitée en restreignant à un instant donné l'ensemble des objets qu'un agent peut accéder. Si l'on considère un système utilisant les notions de processus et de procédure, nous sommes amenés à considérer des groupes de procédures et de données et à faire varier les droits d'utilisation des objets du système par un processus quand celui-ci passe d'un groupe à un autre au cours de son exécution. On appelle domaines de tels groupes.

L'expérience des systèmes de protection du type classique maître-esclave ou par anneaux comme Multics a montré les limitations d'une structure hiérarchique dans laquelle le pouvoir d'un processus était fonction du processus et de la procédure qu'il exécutait, en particulier pour résoudre le problème de la méfiance mutuelle entre processus. Au contraire dans les systèmes à domaines le pouvoir d'un processus à un instant donné peut être fonction uniquement du domaine dans lequel s'exécute le processus.

Les notions de descripteur et de domaine constituent les éléments de base de ces systèmes. Ils peuvent être implantés, soit au niveau du logiciel de base sur une machine classique [16] soit au niveau du câblage sur une machine à domaines [3, 5].

# 2. Eléments fondamentaux du système

## 2.1 Notion de descripteur [4]

Un objet est caractérisé par trois éléments : un nom unique qui est un indicatif permettant de définir l'objet sans ambiguïté dans le système, une représentation et une liste d'opérations. Dans le cas où l'objet est partagé entre plusieurs agents, chacun d'eux n'est pas autorisé à manipuler l'objet avec toutes les opérations définies sur celui-ci, mais seulement avec un sous-ensemble d'entre elles. C'est pour autoriser ce type de partage que nous introduisons la notion de descripteur. Un descripteur est une référence à l'objet, qui contient le nom unique de l'objet et des droits qui caractérisent le pouvoir conféré par la possession de ce descripteur.

L'accès à un objet du système par l'agent nécessite que celui-ci possède un descripteur de cet objet et est réalisé uniquement par l'intermédiaire de ce descripteur.
Le système détermine à l'aide de ce describeur si l'opération requise par l'agent est autorisée ou non et si elle l'est, fournit à partir du nom unique la localisation de l'objet. Dans un tel schéma, les describeurs apparaissent comme des éléments critiques en ce qui concerne la protection des objets du système. Pour cette raison, l'agent ne doit pouvoir créer ou modifier des describeurs que par l'intermédiaire du système de protection. A un instant donné, l'ensemble des objets auquel un agent peut faire accès est défini par l'ensemble des describeurs qu'il possède. Comme nous l'avons indiqué, la conservation de l'intégrité de ces describeurs est critique du point de vue de la protection, ceci conduit à distinguer les describeurs des autres éléments du système, la protection des seconds étant assurée par les premiers.

Pour protéger les describeurs, on peut soit utiliser des mots préfixés, soit réaliser une partition de la mémoire ; la partition consiste à diviser la mémoire en deux espaces, l'un contenant des données, l'autre des describeurs. Ne disposant pas a priori d'une mémoire avec des mots préfixés, c'est la solution de la partition que nous avons retenue.

## 2.2 Type segment et type D-liste

Nous avons maintenant à définir l'objet du système considéré comme élémentaire du point de vue de la protection et du partage. Si l'on considère que le "mot" constitue l'information élémentaire du point de vue de l'unité centrale, l'introduction de la segmentation nous permet de regrouper un ensemble de mots dans un segment, chacun de ces mots ayant le même niveau de partage et de protection. Nous supposons que la machine considérée, dispose d'un adressage segmenté et nous dirons que le segment est un objet primitif du système dans la mesure où les opérations et les contrôles d'accès qui sont définis sur cet objet (lire, écrire, exécuter) sont réalisés par le câblage.

Parmi tous les objets d'un système, certains présentent des caractéristiques communes, en particulier du point de vue des opérations qui peuvent être réalisées sur eux. Nous dirons que des objets sont du même type, si les opérations définies sur ces objets sont les mêmes. Le type d'un objet est caractérisé dans le describeur de cet objet par une marque de type, qui définit sans ambiguïté le type dans le système. Les objets de même type ont la même marque de type.

La distinction introduite précédemment entre describeur et donnée nous conduit à distinguer deux types de segment, suivant que ce segment contient des données (segment de donnée) ou des describeurs (segment de describeurs ou D-liste). Par exemple, les opérations de lecture d'un segment de donnée ou d'une D-liste seront interprétées différemment par le câblage suivant le type de segment.

## 2.3 Notion de domaine

Si l'on considère l'exécution de l'agent processus, celle-ci s'effectue dans un contexte élaboré à partir de l'objet domaine. Chaque domaine constitue un mode d'exécution particulier pour lequel est défini un ensemble d'objets et l'ensemble des opérations qui peuvent être réalisées sur ces objets. L'exécution d'un processus se traduit par le parcours d'une succession de domaines. Le transfert d'un domaine vers un autre doit être contrôlé par le système de protection, dans la mesure où il implique une modification de l'état de protection du contexte dans lequel s'exécute le processus. Ce contrôle ne peut être réalisé que si l'entrée dans un domaine se fait en des points bien déterminés, appelés points d'entrée. Le passage d'un domaine dans un autre est réalisé par une opération *Call Domaine* dont les paramètres sont : le nouveau domaine d'exécution, un des points d'entrée de ce domaine et une liste d'objets du domaine appelant fournis comme paramètres au domaine appelé. Les points d'entrée sont conçus comme un ensemble de procédures que le processus peut exécuter dans le contexte défini par le domaine appelé. Ainsi l'on peut assimiler un domaine Dj à une D-liste lors de l'exécution d'un processus dans ce domaine. Par contre, la nécessité de posséder le describeur de Dj dans le domaine Di pour réaliser la commutation de domaine Di → Dj
nous conduit à introduire un type d'objet primitif particulier : le Domaine, qui ne peut être manipulé dans le domaine Di que par les opérations *Call Domaine* et *return* et qui interdit tout accès aux objets du domaine Dj par le processus s'exécutant dans Di autrement que par ces opérations.

## 2.4 Extension de type

La plupart des systèmes introduisent au niveau de la génération plusieurs types d'objets définis de façon statique. Le système proposé [5] permet la définition et le contrôle dynamiques de types. Pour cela on inclut dans un même domaine l'ensemble des opérations définissant un type et on associe à ces opérations des points d'entrée dans le domaine. La réalisation par un processus P s'exécutant dans un domaine Dj d'une opération op sur un objet de type Ti non primitif (c'est à dire que l'opération est réalisée par une procédure et non par le câblage) est faite par un appel du domaine D associé au type Ti.

La réalisation de cette opération programmée op sur l'objet de type Ti fait inter- venir une décomposition de cet objet en objets composants de types déjà existants (primitifs ou non) et est décrite en termes d'opérations réalisée sur ces composants. On montre dans [5] comment est réalisée cette décomposition ou transformation de type.

# 3. Adressage des objets d'un contexte

## 3.1 Notion de contexte

Fondamentalement l'objet domaine est un modèle : cet objet est partagé par tous les processus qui en possèdent un descripteur. Le partage de cet objet comme de tout objet du système est réalisé par recopie de son descripteur dans le contexte du pro- cessus qui a le droit de le partager. La notion de contexte par contre est propre à chaque invocation d'un domaine par un processus ou si l'on veut propre au couple {processus, domaine}. Le contexte est élaboré dynamiquement lors de l'appel de domaine en recopiant dans l'espace d'adressage associé au processus après commutation, un ensemble de descripteurs associés aux différentes classes d'objets mises en oeuvre :

- objets temporaires (ou locaux)

Ce sont des objets créés en principe pour la durée du traitement réalisé dans le domaine. Ils appartiennent au processus qui s'exécute dans le domaine et il en existe autant d'exemplaires que de processus utilisant le domaine et d'invocations de ce domaine par le processus.

- objets rémanents

Les rémanents sont des objets du processus créés lors de la première utilisation du domaine par le processus et dont la durée de vie est celle du processus. Ces objets sont conservés d'une utilisation à l'autre du domaine par le processus.

- objets privés du domaine

On appelle objet privé d'un domaine un objet partagé entre processus à travers ce domaine et dont la protection n'est définie que relativement à ce domaine et indépendamment des processus qui l'utilise. L'objet domaine tel que nous l'avons introduit peut être considéré principalement comme le regroupement de l'ensemble des objets privés associés à ce domaine.

- objets externes

Ce sont des objets pour lesquels la protection est fonction à la fois du processus et du domaine dans lequel s'exécute le processus. Pour cette raison ces objets ne peuvent pas apparaître dans le domaine, celui-ci pouvant être partagé entre plusieurs processus. Ces objets ne peuvent donc être définis que lorsque l'on connait le processus qui s'exécute dans le contexte.
- objets paramètres

Ce sont des objets capturés dans le contexte appelant par recopie des descripteurs dans le contexte appelé. Cette recopie a lieu lors de la commutation de domaine.

En résumé, un processus s'exécute non pas dans un domaine mais dans un contexte qui est élaboré lors des opérations "call domaine" à partir du modèle constitué par l'objet domaine.

## 3.2 Matérialisation du contexte

Nous ne nous intéressons ici qu'aux objets du type segment. Nous faisons l'hypothèse que la gestion de la mémoire se base sur le découpage en segments. La dissociation au niveau de la mémoire entre segment de données (incluant le code) et segment de descripteurs, nous conduit d'une façon analogue à distinguer les registres contenant des données, de ceux contenant des descripteurs. La désignation d'un objet par son nom unique, nous permet de considérer le descripteur comme un invariant quant à la localisation de la représentation de l'objet (mémoire principale ou mémoire secondaire).

Tout élément d'un segment est désigné par un nom de la forme (i,d) où i désigne le descripteur du segment considéré.

Dans les systèmes utilisant la segmentation, une table des segments (ou descriptif) décrit l'ensemble des objets visibles d'un processus ; i est alors un nom dans cette table propre au processus et est appelé nom du segment. Dans notre structure l'ensemble des objets visibles du processus se décrit dans une arborescence de D-listes dont la racine est constituée par la D-liste que forment les registres de descripteurs.

La structure de liste de l'ensemble des objets visiblés suggère l'adoption d'un mécanisme câblé qui permette de réaliser automatiquement l'accès aux éléments de cette structure. Cette solution est exclue dans la mesure où les éléments terminaux de cette structure ne sont pas nécessairement des segments de données et dans la mesure où elle implique une complexité trop grande des mécanismes câblés d'adressage. Aussi nous considérons qu'à un instant donné, seul un sous-ensemble des objets visibles est accessible par le processeur ; nous appelons ce sous ensemble le contexte du processus. Il est matérialisé à l'aide des registres de descripteurs.

La définition des objets du contexte donnée en 3.1 suggère que celui-ci soit représenté à l'aide d'autant de D-listes qu'il contient de classes. Cependant, une telle solution nécessiterait que l'accès aux objets se fasse systématiquement par indirection et compliquerait le parcours de l'arborescence des objets visibles. Afin de permettre une accélération des accès, nous distinguons deux groupes de registres de descripteurs : les registres de contexte et les registres de travail.

Les registres de contexte décrivent les différentes classes d'objets du contexte. Ils sont sauvegardés lors des changements de contexte provoqués par l'appel de domaine.

Les registres de travail sont librement utilisables pour définir un ensemble d'objets directement accessibles et permettre ainsi le parcours de l'arborescence. Ils sont également utilisés pour réaliser la transmission des paramètres entre contextes.
<figure><img src="image_4.png" /><figcaption>Figure 1 : Structure des contextes</figcaption></figure>

### 3.3 Rappel des schémas d'adressage existants

3.3.1 Dans une machine telle que la Chicago Magic Number [17], le descripteur d'un segment est composé de : la nature du descripteur, les droits d'accès, l'adresse d'implantation et sa taille. La nature du descripteur spécifie si le segment est ou non en mémoire. Si le segment est en mémoire le descripteur est dit "in form" et l'adresse de base est une adresse mémoire, s'il n'est pas en mémoire le descripteur est dit "out form" et l'adresse de base est une adresse en mémoire secondaire. Les descripteurs "in form" ne se trouvent jamais en mémoire secondaire ; ils sont toujours transformés en "out form" avant d'être renvoyés en mémoire secondaire. Seul un descripteur "in form" permet d'accéder au segment.

Si le descripteur utilisé pour accéder au segment est "out form", il en résulte une trappe calculée. Cette organisation a pour inconvénient d'imposer au système la conversion permanente des descripteurs de la forme "out form" en "in form" et réciproquement. Cette conversion est rendue nécessaire par le fait que le couple (adresse de base, taille) est spécifié explicitement dans le descripteur. Plus grave encore est la nécessité de rechercher l'ensemble des descripteurs relatifs à un segment quand celui-ci est renvoyé en mémoire secondaire ou lorsque sa taille est modifiée. L'expérience a mis en évidence les difficultés de la conversion des descripteurs "in form" en "out form".

3.3.2 La Plessey 250 [3, 12] résoud partiellement ce problème en utilisant non pas ce couple mais un invariant qui est l'index d'entrée dans un table (SCT : System Capability Table) où sont spécifiées l'adresse de base et la taille du segment. Toute modification du couple (adresse de base, taille) d'un segment est alors répercutée dans la SCT seulement et n'implique aucune modification des descripteurs relatifs à ce segment puisque l'accès vers ce segment se fait par indirection. Nous appellerons descripteur explicite tout descripteur où sont spécifiées l'adresse de base et la taille d'un segment et descripteur implicite tout descripteur qui introduit un ou plusieurs niveaux d'indirection pour les spécifier. Le schéma par indirection de la Plessey ne résoud que partiellement le problème dans la mesure où la table des couples (adresse de base, taille) des segments est de taille limitée. Il en résulte que l'index dans cette table ne constitue pas la seule méthode de dénomination des objets et que lors du rejet d'un couple (adresse de base, taille) relatif à un segment de la SCT on est ramené au problème précédent.
Néanmoins cette organisation permet de limiter la fréquence des transformations "in form" ↔ "out form". Notons en ce qui concerne la machine Plessey que la transformation de descripteur implicite en descripteur explicite n'est pas faite entièrement par cablage et que la structure des registres de descripteur où les descripteurs sont spécifiés sous une forme explicite permet d'accélérer le calcul d'adresse en évitant une indirection systématique dans la SCT.

Une opération se présente sous la forme $op i,j,d$ où j est le numéro d'un registre de descripteurs, d un déplacement dans le segment spécifié par le registre précédent et i le numéro d'un registre de données si l'objet est un segment de données ou d'un registre de descripteurs si l'objet est une D-liste. D'une façon générale l'accès au mot d'un segment de données S nécessite une instruction de chargement du descripteur de S spécifié sous une forme implicite dans une D-liste dans un registre de descripteurs où il est alors spécifié sous une forme explicite, puis une instruction d'accès au mot du segment spécifié par le registre précédent.

La transformation du descripteur implicite en descripteur explicite par la SCT n'est réalisée que dans le cas d'un chargement d'un élément d'une D-liste dans un registre de descripteur. La transformation inverse ne peut être réalisée simplement par la SCT, car cela supposerait la recherche dans cette table d'une correspondance entre les adresses d'implantation en mémoire. Ce problème est résolu dans la machine Plessey 250 par la conservation permanente (dans la pile des processus) d'une image mémoire de la forme implicite des descripteurs contenus dans les registres. La mise à jour de ces images en mémoire est réalisée à chaque chargement d'un registre de descripteurs.

<figure><img src="image_5.png" /><figcaption>Figure 2 : Association des descripteurs implicite et explicite</figcaption></figure>

<figure><img src="image_6.png" /><figcaption>Figure 3 : Chargement et rangement d'un registre de descripteur</figcaption></figure>
## 3.4 Schéma d'adressage proposé

L'adressage proposé reprend le schéma suggéré par Dennis et Van Horn [1] suivant
lequel un nom unique est associé à chaque segment. Le nom unique est assigné par le
système au moment de la création d'un segment et reste inchangé durant toute la durée
de vie du segment.

Il existe ainsi une représentation unique du descripteur d'un segment, le couple (adresse de base, taille) étant désigné par le nom unique qui est un invariant du système.

Le calcul d'adresse doit alors permettre de définir à partir d'un nom unique donné, l'adresse de base et la taille du segment référencé. Un descripteur est défini par le couple (droits d'accès, nom unique). Dans notre schéma, nous ajoutons un autre élément qui est le type de l'objet. Notons qu'en ce qui concerne les machines précédemment présentées, la notion de type y est implicite, puisque l'on distingue les segments de données des segments de descripteurs. Dans le cas de la machine Plessey 250 cette distinction se traduit par une partition des droits d'accès spécifiés dans le descripteur.

### 3.4.1 Rôle des registres de descripteurs

Le schéma proposé implique que tout accès à un élément d'un segment soit réalisé par référence au descripteur de ce segment. La transformation du nom unique défini dans le descripteur en son adresse de base est réalisée par le cablé. La spécification du descripteur par le programmeur peut être faite différemment suivant que l'on considère les registres de descripteurs comme explicites (accessible par le programmeur) ou implicites.

- adressage par registres explicites (cas de la machine Plessey 250)

Tout élément d'un segment s est désigné par un nom de la forme (i,d) où i est le numéro d'un registre du processeur contenant le descripteur de s. L'initialisation du registre i est réalisée par le chargement dans ce registre de l'élément (j,d') où j est le numéro du registre contenant le descripteur d'une D-liste et d' l'adresse du descripteur de s dans cette D-liste. Un des registres de descripteurs est spécialisé et contient le descripteur de l'environnement du domaine.

Le chargement de ce registre est effectué lors de la commutation de domaine.

<figure><img src="image_7.png" /><figcaption>figure 4 : Adressage par registres explicites</figcaption></figure>
Les registres de descripteurs définissent l'ensemble $E_a$ des objets accessibles par le
processeur. Cet ensemble est élaboré à partir de l'ensemble $E_d$ des objets accessibles
par le processus quand celui-ci s'exécute dans le domaine $D$.

Tout accès par le processeur à un élément $i \in E_d$ implique nécessairement pour qu'il
soit réalisé que $i \in E_a$. Les registres de descripteurs qui ne sont pas associés aux
classes d'objets peuvent alors être considérés comme des registres de travail pour
réaliser les fonctions d'accès aux objets du contexte.

Cette structure simplifie donc considérablement le mécanisme cablé realisant la fonction
d'accès, puisque le descripteur de l'objet est toujours présent dans un des registres
Par contre la définition de l'ensemble $E_a$ est à la charge du programmeur qui doit
assurer la gestion des registres de descripteurs.

- adressage par registres implicites (cas de la machine CAP [14])

Les registres de descripteurs sont transparents à l'utilisateur. L'adresse virtuelle
segmentée $(s,d)$ est spécifiée sous la forme $(ad,d)$ ou ad est l'adresse du descripteur
de s dans la D-liste racine du domaine. L'accès à l'élément $(s,d)$ requiert un minimum
de deux accès mémoire, l'un pour accéder au descripteur, l'autre pour accéder à
l'élément $d$ du segment $s$.

<figure><img src="image_8.png" /><figcaption>figure 5 : adressage par registres implicites</figcaption></figure>

Ce mode d'adressage qui peut être considéré comme indirect, nécessite pour des raisons
de performance, que soit utilisée une mémoire associative pour accélérer les accès aux
éléments du segment $s$. Ce mécanisme d'adressage peut être assimilé à celui des machines
admettant l'adressage segmenté [2]. La D-liste racine du domaine est alors considérée
comme un descriptif. En réalité nous avons vu qu'à un contexte étaient associés des objets
regroupés en classes. Dans ces conditions, l'adresse virtuelle segmentée $(s,d)$ est
spécifiée sous la forme $(i,ad,d)$ ou $i$ est le numéro d'un registre de descripteur dési-
gnant la D-liste qui regroupe les objets de la classe considérée.

### 3.4.2 Description des différents modes d'adressage

Afin de limiter le champ adresse des instructions, nous considérons que l'adressa-
ge est à deux opérandes, l'un des deux opérandes étant nécessairement un registre du
processeur. Le mécanisme d'adressage impose le respect de la cohérence des opérandes,
c'est à dire que si le second opérande est un descripteur, le premier opérande est
nécessairement un registre de descripteur, de même pour les données.

Le descripteur d'un segment $S$ est désigné dans l'instruction par un numéro de
registre $r$. Si $r$ est le nom d'un registre de descripteur, celui-ci contient le des-
cripteur du segment $S$ lui-même, si c'est un registre de données, celui-ci contient le
numéro du registre de descripteur associé au segment $S$
<figure><img src="image_9.png" /><figcaption>figure 6: Les deux chemins d'accès à un segment S</figcaption></figure>

L'instruction peut alors être écrite sous la forme :
opération, R, mode (r,D), X.

R numéro du registre du premier opérande

X numéro du registre d'index

r numéro du registre utilisé pour désigner le descripteur du segment
auquel appartient le second opérande

D adresse du second opérande dans le segment désigné par r
mode mode d'adressage du second opérande :
immédiat, registre, mémoire par registre de descripteur direct ou
indirect, mémoire par registre de donnée direct ou indirect.

## Système de notation

Le calcul de l'adresse réelle d'un élément d'un segment en fonction du mode d'adressage défini dans l'instruction est exprimé sous la forme d'instructions d'un langage du type Pascal. Les éléments qui apparaissent dans l'instruction op, R, mode (r,D), X

sont désignés comme des variables (italique) et les registres de descripteur et de données comme des tableaux dont les noms sont respectivement RD et RB. Le descripteur d'un segment permet le calcul de l'adresse physique du premier élément de ce segment, on considère dans la suite que cette adresse est définie dans l'un des champs du registre qui le contient. On utilise la notation RD(i).j ou RB(i).j pour désigner le champ j du registre i.

- adressage par registre de descripteur (RD) en mode direct (D)

adresse ← RD[r].adresse+D+RB[x]

<figure><img src="image_10.png" /></figure>
- adressage par registre de descripteur (RD) en mode indirect (D*)

$$
\begin{align*}
\text{RB}[\text{tampon}] &\leftarrow \text{mémoire}[\text{RD}[r].\text{adresse}+D] \\
\text{adresse} &\leftarrow \text{RD}[\text{RB}[\text{tampon}].i].\text{adresse}+\text{RB}[\text{tampon}].d+\text{RB}[x]
\end{align*}
$$

<figure><img src="image_11.png" /></figure>

- adressage par registre de donnée (RB) en mode direct (D)
  adresse → RD[RB[r].i].adresse + RB[r].d + D+RB[x]

<figure><img src="image_12.png" /></figure>

- adressage par registre de donnée (RB) en mode indirect (D*) à travers un segment de donnée

$$
\begin{align*}
\text{RB}[\text{tampon}] &\leftarrow \text{mémoire}[\text{RD}[\text{RB}[r].i].\text{adresse} + D + \text{RB}[r].d] \\
\text{adresse} &\leftarrow \text{RD}[\text{RB}[\text{tampon}].i].\text{adresse} + \text{RB}[\text{tampon}].d + \text{RB}[x]
\end{align*}
$$

<figure><img src="image_13.png" /></figure>
- adressage par registre de donnée (RB) en mode indirect (3*) à travers une D-liste

$$
\begin{align*}
\text{RD}[\text{tampon}] &\leftarrow \text{mémoire } [\text{RD}[\text{RB}[r].i].\text{adresse} + \text{RB}[r].d] \\
\text{adresse} &\leftarrow \text{RD}[\text{tampon}].\text{adresse} + D + \text{RB}[x]
\end{align*}
$$

<figure><img src="image_14.png" /></figure>

3.5 Exemples d'utilisation de l'adressage

- adressage par registres de descripteur en mode direct.

L'exemple qui suit montre comment le contexte du processus peut évoluer par
capture d'un objet dans l'une des classes accessibles depuis un registre de contexte et
rangement de son descripteur dans un registre de travail.

<figure><img src="image_15.png" /><figcaption>figure 7: capture d'un segment dans un registre de descripteur</figcaption></figure>

- adressage par registres de donnée en mode direct

Par rapport à l'adressage par registre de descripteur en mode direct, il permet
de spécifier un sous segment dans un segment. Il est à noter que pour permettre la
protection de structures telles que tableaux ou vecteurs, le registre de base devrait
contenir également une spécification de la taille du sous segment. La taille limitée
des registres de données nous contraint à éliminer cette possibilité. De la même façon
on peut utiliser un adressage uniforme par registre de donnée et ne pas utiliser
l'adressage par registre de descripteur. Néanmoins, l'utilisation de ces derniers
permet de limiter le nombre de registres de données utilisés.

Nous donnons à titre d'exemple la gestion d'une pile pour les appels et retour de
procédure dans un même domaine.
<figure><img src="image_16.png" /><figcaption>Figure 8: gestion des appels de procédures dans un domaine : adressage de la pile</figcaption></figure>

<figure><img src="image_17.png" /></figure>

procédure appelée :

Chargement du registre R (adresse de retour dans la pile)

mise à jour du pointeur de pile (+ 2)

décrémentation du pointeur de pile (- 2)

chargement de l'adresse de retour dans un registre R

chargement du pointeur de pile de la procédure appelante dans le registre

pointeur de pile courant

branchement à l'adresse de retour de la procédure appelante.

Remarque : tous les éléments d'un espace de la pile associé à une procédure sont accessibles dans cette procédure par des instructions de la forme :

accès B (r, D)
- adressage en mode indirect à travers un segment

Dans le cas où l'opérande est un élément d'un segment, son adresse dans le segment est généralement spécifiée par le champ D de l'instruction. L'adressage en mode indirect, qu'il soit réalisé par un registre de donnée ou de descripteur, permet de sauvegarder une adresse de la forme (i,d) dans un segment de donnée et de réaliser l'accès à cet élément en une seule instruction. Nous donnons à titre d'exemple le passage de paramètre par référence dans le cas des appels de procédure à l'intérieur d'un même domaine.

<figure><img src="image_18.png" /><figcaption>figure 9 :passage de paramètres entre procédures d'un domaine</figcaption></figure>

- adressage en mode indirect à travers une D-liste

C'est le mode d'adressage normal pour accéder aux éléments du contexte défini par les registres de contexte. Chaque registre de donnée faisant référence à l'un de ces registres de descripteur spécifie ainsi le descripteur d'un segment dans le descriptif associé à l'une des classes d'objets.

<figure><img src="image_19.png" /><figcaption>figure 10 :accès aux objets du contexte par adressage indirect</figcaption></figure>
## 4. Gestion de la mémoire virtuelle et incidence sur le calcul d'adresse

Le repérage d'un segment par son nom unique, nous conduit à définir une mémoire virtuelle unique pour l'ensemble des processus existant dans le système et à spécifier pour chacun des éléments de la hiérarchie de mémoire, des tables réalisant la transformation d'adresse virtuelle en adresse réelle dans la mémoire du niveau considéré. Nous rappelons que nous nous sommes placés dans les hypothèses :

a) d'une mémoire segmentée non paginée

b) d'un minicalculateur microprogrammable.

### 4.1 Segments en mémoire principale

L'ensemble des segments présents en mémoire sont représentés dans une table (H-table) qui pour chacun d'entre eux contient : le nom unique, l'adresse de base en mémoire, des bits de gestion, la taille du segment et un compteur indiquant le nombre de descripteurs qui référent ce segment. Lorsqu'un accès est requis vers un segment, une recherche associative (microprogrammée ou câblée) est faite dans la H-table pour déterminer si le nom unique du segment est présent dans cette table. Si une correspondance est trouvée, l'adresse du segment en mémoire principale peut être déterminée. Sinon le segment est en mémoire secondaire et une interruption pour défaut de mémoire est générée.

- accélération du calcul d'adresse

- cas de l'adressage en mode direct

La recherche du nom unique du segment dans la H-table s'avère une opération coûteuse si elle est réalisée à chaque exécution d'une instruction. Pour accélérer ce calcul d'adresse, on utilise la propriété qu'en mode direct les descripteurs des segments référencés sont nécessairement chargés dans un registre et donc que l'ensemble des segments désignés par ces descripteurs ont une forte probabilité d'être référencés. On réalise donc un couplage entre les registres de descripteur contenant les attributs type, droits et nom unique et des registres de donnée contenant l'adresse en mémoire du segment, sa taille et des bits de gestion. Ces registres de données sont inaccessibles à l'utilisateur et uniquement gérés par le microprogramme.

<figure><img src="image_20.png" /><figcaption>Figure 11 : organisation des registres de descripteur</figcaption></figure>
- adressage en mode indirect (à travers une D-liste)

L'adressage indirect à travers une D-liste est utilisé systématiquement pour les objets d'une classe donnée. Il nécessite un minimum de deux accès mémoire (un pour le descripteur, l'autre pour l'objet lui-même) et un minimum d'une recherche en mémoire du segment. Pour limiter le temps d'accès, on définit une petite mémoire associative gérée par câblage ou par microprogramme.

<figure><img src="image_21.png" /><figcaption>figure 12 : accélération des accès indirects à travers les D-listes du contexte</figcaption></figure>

Toute modification du descripteur dans le registre i ou dans la i-liste référencée par i doit entrainer l'invalidation de l'entrée correspondant à (i,d) dans la mémoire associative.

- Algorithme de calcul d'adresse

§ définition de la structure du processeur §

TYPE

registre_descripteur=RECORD

ttype: 0..nb_tynes;

droits: ARRAY[0..nb_operations]OF BOOLEAN

nom_unique: 0..nb_segments;

adresse: 0..taille_memoire;

valid: BOOLEAN; {indique si l'adresse mémoire est ou non valide}

ecriture: BOOLEAN; {indique si un accès en écriture a été réalisé}

taille: 0..taille_segment

END;

registreTBstruction=RECORD

code_op: 0..127;

mode: 0..3;

reg_dest: 0..15;

reg_index: 0..7;

reg Operande: 0..15;

deplacement: 0..4096

END;

htable_entry =RECORD

nom_unique: 0..nb_segments;

adresse: 0..taille_memoire;

taille: 0..taille_segment;

compteur: 0..nb_descripteurs; {indique le nombre de descripteurs qui référencent le segment}

ecriture: BOOLEAN; {interdit tout accès lorsqu'un transfert disque mémoire est en cours}

verrou: BOOLEAN;

END;

mot

= § structure du mot de la machine §
§ définition des différents composants du processeur §

VAR
RD : ARRAY[0..nb_registre_descripteur]OF registre_descripteur;
RB : ARRAY[0..nb_registre_donnee]OF mot;
htable : ARRAY[0..nb_entree_htable]OF htable_entry;
RI : registreTB instruction;

§ procédure de calcul d'adresse §

PROCEDURE calcul_adresse(a: INTEGER; VAR adresse: INTEGER);
BEGIN
  IF (RD[a].valid) THEN recherche_htable(a) {on recherche si l'adresse mémoire est
    ou non validée}
  IF RD[a].valid
    THEN IF RD[a].droits klasseOperation(RI code_op)
      THEN IF RI.deplacement≤RD[a].taille
        THEN adresse:=RD[a].adresse+RI.deplacement
      ELSE erreur(depassement_taille)
        ELSE erreur(operation_interdite)
      ELSE trappe(défaut_mémoire)
    END;

PROCEDURE recherche_htable(a: INTEGER);
VAR i: INTEGER;
BEGIN
  i:=0;
  WHILE (RD[a].nom_unique≠htable[a].nom_unique)^(i≤nb_entree_htable)
    DO i:=i+1;
  IF i≤nb_entree_htable
    THEN BEGIN
      WITH RD[a] DO BEGIN
        adresse:=htable[i].adresse;
        taille:=htable[i].taille;
        verrou:=TRUE
      END;
      WITH htable[i] DO compteur:=compteur+1 { incrémentation du compteur de descrip-
        teurs car on a chargé un nouveau
        descripteur}
    END;
END;

4.2 Segments en mémoire secondaire

Quand un segment est créé dans le système, on lui associe une entrée dans une
table décrivant l'ensemble des segments du système et où sont spécifiés les attributs
du segment (adresse de base sur disque, taille,...).
Cette table que nous appelons table de noms uniques (TNU) est de taille limitée et
cela pose le problème de la réaffectation des entrées. Quand un segment est détruit on
doit pouvoir réallouer le nom unique pour un nouveau segment et interdire toute réfé-
rence à l'ancien segment. Plusieurs solutions sont envisageables :
1. Quand un segment est détruit une procédure du système invalide tous les descripteurs qui référent ce segment par un algorithme de ramasse miettes.

2. Le nom d'un segment est constitué d'un couple (valeur unique, index dans la table des noms uniques). Quand un segment est créé, on lui alloue une valeur d'index qui est une entrée dans la table et une valeur unique pour toute la durée de vie du système qui peut être une valeur d'horloge. Les attributs du segment qui sont rangés dans cette table incluent cette valeur unique. Tout accès à une entrée de la table des noms uniques par l'intermédiaire de la valeur d'index nécessite un contrôle de la validité de l'attribut valeur unique. Cette solution permet lors de la destruction d'un segment de libérer l'entrée de la TNU qui lui correspond sans avoir à invalider l'ensemble des descripteurs associés à ce segment. Ceci peut conduire néanmoins à définir une procédure d'invalidation des descripteurs dans la mesure où l'on peut arriver à une saturation de l'espace virtuel par des descripteurs de segment qui ont été détruits.

3. Le nom unique d'un segment n'est réalloué à un nouveau segment que si l'ensemble des descripteurs relatifs à l'ancien segment ont été détruits.
La destruction d'un segment positionne dans l'entrée correspondante de la TNU un bit qui indique la destruction d'un segment, mais elle n'entraîne pas nécessairement la possibilité de réallouer cette entrée pour un nouveau segment. Cette solution que nous choisissons pour éviter un balayage systématique de la mémoire et limiter la taille des descripteurs présente néanmoins l'inconvénient de nécessiter un attribut compteur de descripteurs et n'exclut pas totalement le nettoyage dans la mesure où la table des noms uniques et la mémoire peuvent être saturées. Dans cette hypothèse l'entrée dans la table des noms uniques (TNU) constitue un nom unique pour les segments.
L'importance de la table des noms uniques exclue l'hypothèse d'une table résidente en mémoire et contenue dans un seul segment. Cette contrainte ralentit considerablement la phase de calcul d'adresse, deux transferts mémoire secondaire → mémoire rapide pouvant s'avérer nécessaire pour transférer le segment référencé en mémoire.
La table des noms uniques est éclatée en plusieurs tables (qui sont des segments) et cet ensemble de tables est adressé par une hypertable résidente en mémoire principale. Pour conserver l'unicité du traitement d'adresse, on introduit une convention sur les noms de segments. Le nom unique nu peut être interprété comme un doublet (p,q) où p est une entrée dans l'hypertable qui désigne le segment de TNU contenant les informations relatives au segment nu.

<figure><img src="image_22.png" /><figcaption>figure 13 : organisation de la table des noms uniques</figcaption></figure>
<figure><img src="image_23.png" /></figure>

nota : le nom unique nu est divisé en nu = (p, q)

a) le segment a déjà été utilisé dans le contexte courant, son adresse est dans le registre de descripteur : cas du segment (p₁, q₁)

b) le segment est en mémoire principale, il est connu dans la H.table : cas du segment (p₁, q₁)

c) le segment est en mémoire secondaire, mais la TNU correspondante est en mémoire principale : cas du segment (p₂, q₂)

d) la TNU correspondante n'est pas présente, elle est connue dans la HTNU et le segment est en mémoire secondaire : cas du segment (p₃, q₃)

figure 14 : les différentes formes de localisation d'un segment
## 5. Exemple de code opération

### 5.1 Format des instructions

L'instruction écrite sous la forme `op`, `R mod(r,d)` est une instruction à deux opérandes. Le second opérande est situé dans un segment (de données ou de descripteurs), dans un registre ou est une valeur immédiate.

<table><tr><td>OP</td><td>M</td><td>R</td><td>X</td><td>r</td><td>D</td></tr><tr><td>0</td><td>6</td><td>7</td><td>8</td><td>9</td><td>12</td><td>13</td><td>15</td><td>16</td><td>19</td><td>20</td></tr></table>

OP code opération

M mode d'adressage (par registre de descripteur/ de donnée, direct/ indirect)

R numéro du registre contenant le résultat de l'opération

X numéro du registre d'index. Si X = 0 il n'y a pas d'indexation. Si X = 15 le second opérande n'est pas situé dans un segment, mais dans un registre où est une valeur immédiate.

Seuls les registres `RB[1]`, ..., `RB[6]` peuvent être utilisés comme des registres d'index.

r, D les champs r et D sont interprétés différemment suivant le mode d'adressage.

figure 15 : format d'une instruction

Nous ne décrivons ensuite que les instructions caractéristiques de l'architecture proposée, c'est-à-dire :

- les instructions sur descripteurs

- les instructions de commutation de contexte

- les instructions de branchement

### 5.2 Opérations sur les descripteurs

#### 5.2.1 Structure des descripteurs

Nous introduisons deux interprétations des champs d'un descripteur suivant que le type spécifié dans le champ `TYPE` est `TRANSIT` ou différent de `TRANSIT [5]`.

8 bits 8 bits 16 bits

<table><tr><td>Type</td><td>droits</td><td>nom unique</td></tr></table>

figure 16 : taille du descripteur (32 bits)

Les objets du type `TRANSIT` sont utilisés pour contrôler les opérations de transformation de type. Si le type `Tj` est élaboré à partir du type `Ti`, ils permettent de réaliser les transformations `Ti → Tj` et `Tj → Ti`. Les objets du type `TRANSIT` contiennent les informations suivantes : le type `Ti`, les droits minimum requis sur un objet `Ti` pour être transformé en un type `Tj`, le type `Tj` et les droits définis sur l'objet `Tj`.
Soit `(Ti, di, Tj, dj)` cet ensemble d'informations.

Etant donné la petite taille de l'objet de type `TRANSIT`, on peut définir la représentation de l'objet `TRANSIT` dans le champ `nom unique` du descripteur de l'objet. Cette solution présente l'inconvénient d'introduire une taille de descripteur supérieure à celle définie pour les autres types et de multiplier dans le cas d'un domaine de définition de type les descripteurs de type `TRANSIT`. En effet, dans ce cas, les points d'entrée du domaine définissent l'ensemble des opérations qui peuvent être réalisées sur des objets de type `Tj`. Le contrôle de la transformation de type `Tj → Ti` est réalisé à chacun des points d'entrée et implique que l'objet de type `TRANSIT` associé à cette transformation contienne l'ensemble des droits `dj` représentant le minimum requis pour réaliser l'opération définie au point d'entrée. Ceci conduit donc à définir autant de descripteurs de type `TRANSIT` que de points d'entrée dans le domaine. Si d'autre part on remarque que pour tout `Tj` l'ensemble `(Ti,di)` est invariant, on peut adopter la solution suivante :
<figure><img src="image_24.png" /><figcaption>figure 17 : représentation des objets de type Transition</figcaption></figure>

A chaque objet de type TRANSIT on associe implicitement un couple (Ti,di). Tous les couples (Ti,di) sont regroupés dans un segment appelé segment des types. Le champ nom unique du descripteur de type TRANSIT est utilisé pour accéder au couple (Ti,di) correspondant dans le segment des types.

### 5.2.2 Opérations de transferts des descripteurs

Pour toutes ces instructions le mode immédiat est interdit.

**LDC, R mod(r,D) chargement d'un descripteur dans un registre.**
Si l'adressage est en mode registre, on réalise le transfert du registre de descripteur RD[R] dans le registre de descripteur RD[R]. Si l'adressage est en mode mémoire, l'élément accédé doit être une D-liste qui doit pouvoir être lue et est chargé dans RD[R] (adressage double mot). Le comptage des descripteurs inclut les descripteurs contenus dans les registres. Ceci permet d'éviter une mise à jour de ces compteurs lors des opérations CALL et RETURN.
Lors de l'exécution de LDC, le compteur associé à l'objet dont le descripteur est initialement dans le registre RD[R] est décrémenté (s'il y a lieu) et le compteur associé à l'objet dont le descripteur est à transférer dans RD[R] est incrémenté (s'il y a lieu).

**CDLC, R mod(r,D) chargement d'un descripteur non nul.**
Elle est identique à la précédente, mais le chargement d'un descripteur nul provoque une erreur et la non-exécution de l'instruction.

**LDP, R mod(r,d) chargement d'un descripteur dans un registre de données.**
Le descripteur sous sa forme implicite (nom unique, droits, type) est chargé de la mémoire ou d'un registre de descripteur dans les deux registres de données RB[2p] et RB[2p+1] (p = R/2). Ceci permet de lire le contenu d'un descripteur, mais ne permet pas d'utiliser ce contenu pour accéder à un objet. On notera qu'il n'y a pas d'opération de chargement d'une donnée dans un registre de descripteur.

**MASQ, R mod(r,d) masquage d'un descripteur.**
On réalise une diminution des droits définis dans le champ droits du descripteur désigné par le second opérande. L'opération effectue un ET logique entre un masque défini dans RB[R] et le champ droits du descripteur.
STC, R mod(r,d) chargement d'un descripteur.

Le mode direct registre est interdit. Les champs (type, droits, nom unique) du registre RD[R] sont chargés dans le segment référencé par le second opérande.

Ce segment doit être une D-liste. Les opérations d'incrémentation et décrétention des compteurs de descripteurs d'objets sont analogues à celles introduites dans l'instruction LDC.

### 5.2.3 Opérations sur les types

Les objets du système sont typés et l'on définit deux fonctions f et g qui permettent de transformer le type Ti d'un objet en un type Tj et réciproquement

f : ti → Tj ; g : Tj → Ti

Les fonction f et g admettent deux arguments : le descripteur de l'objet Tj à transformer, le descripteur de l'objet de type TRANSIT qui spécifie la transformation à effectuer.

SEAL, R mod(r,d) composer

Les champs type et droits d'accès du descripteur défini dans RD[R] sont modifiés en fonction des informations contenues dans le second opérande (descripteur de type TRANSIT)

<figure><img src="image_25.png" /><figcaption>figure 18 : composition de type</figcaption></figure>

L'instruction SEAL réalise les opérations suivantes :

- accès au second opérande. On vérifie qu'il s'agit d'un descripteur du type TRANSITION et que l'on possède le droit SEAL.

- on vérifie que Ti = T'i et que d'i ⊂ di

- les champs type et droits de RD[R] sont chargés par Tj et RB[R].
UNSEAL, R mod(r,d) décomposer
C'est la transformation inverse de la précédente.

AUDIT, R mod(r,d) contrôler
Cette instruction réalise le contrôle du type et des droits possédés sur un objet. Cette opération ne modifie pas les données introduites.

### 5.3. Opérations de commutation de contexte

A chaque processus est associée une pile qui décrit l'imbrication des appels de domaines. Cette pile est décrite par un registre de donnée qui définit le numéro du registre contenant le descripteur de la pile et le pointeur du sommet de pile. Cette pile est mise à jour automatiquement lors des opérations de commutation du contexte.

<figure><img src="image_26.png" /><figcaption>figure 19 : pile des contextes</figcaption></figure>

Remarque : le segment support de la pile est un segment mixte qui contient des descripteurs et des données. Ce segment est considéré comme un segment de donnée et n'est manipulé en général que par les opérations CALL et RETURN.

CALL, R mod(r,d) appel de domaine.
Le contexte courant est sauvegardé dans la pile et le nouveau contexte est établé à partir du domaine spécifié par le second opérande.

Le second opérande doit nécessairement être un descripteur du type DOMAINE. Ce descripteur est chargé dans le registre de contexte RD[0], le champ type est transformé de domaine en D-liste et le champ droit est initialisé à lecture.

Les autres registres de contexte sont remis à zéro.

Le champ R de l'instruction est utilisé pour définir le point d'entrée dans le domaine.

La recopie dans la pile des descripteurs contenus dans les registres n'entraîne pas une mise à jour des compteurs qui leur sont associés. En effet, le nombre des descripteurs n'est pas modifié car les registres sont remis à zéro après cette recopie.
<figure><img src="image_27.png" /><figcaption>figure 20 : appel de domaine</figcaption></figure>

RETURN Retour de Domaine

Cette instruction sans argument réalise la commutation du contexte appelé en contexte appelant. Ce nouveau contexte est élaboré à partir des informations contenues dans la pile associée au processus. Les opérations suivantes sont réalisées :

- mise à zéro des registres de contexte et décrémentation des compteurs qui leur sont associés.

- chargement des registres de descripteurs du contexte à partir de la pile du processus.

- chargement du compteur ordinal.

- mise à jour du pointeur du sommet de la pile du processus.
### 5.4 Opérations de branchement à l'intérieur d'un contexte

Dans la structure de domaine introduite, le descripteur du segment de code est défini non pas dans un registre, mais dans une D-liste. Ceci provient du fait que les domaines admettent plusieurs points d'entrée et que lors de la commutation de contexte, le segment de code courant est défini par son descripteur dans la D-liste d'environnement. La fonction d'accès à l'instruction courante réalisée par le processeur doit être telle que le chemin d'accès suivi soit identique à celui défini par la structure du contexte dans lequel s'exécute le processus. Le mécanisme général d'accès aux objets du système s'applique donc à l'objet particulier qu'est le segment de code courant. Le compteur ordinal est constitué par un double registre de données. L'un des registres définit le descripteur du segment de code, l'autre est un registre d'index donnant l'adresse de l'instruction courante dans ce segment.

Si RB [courant] et RB [courant + 1] sont les deux registres, l'accès à l'instruction courante est simulé par :

$$ \text{accès } \mathcal{B}^* (\text{courant}, 0), (\text{courant} + 1) $$

Une instruction de branchement avec rangement du contenu du compteur ordinal dans un double registre de donnée permet la réalisation des appels et retours de procédure dans un domaine.

<figure><img src="image_28.png" /><figcaption>figure 21 : accès à l'instruction courante</figcaption></figure>

Dans les instructions de branchement, le second opérande définit l'adresse de branchement et réalise la mise à jour du compteur ordinal. Si l'adressage est en mode immédiat, registre ou direct, le branchement se fait à l'intérieur du segment de code courant. Si l'adressage est en mode indirect, le branchement peut être réalisé dans un autre segment que celui dans lequel l'instruction a été définie. Le contrôle du type et des droits sur le segment est réalisé uniquement lors des accès au segment de code.

<footnote>**Remarque** : Les registres associés au compteur ordinal ne peuvent être spécifiés dans le champ de l'instruction. La mémoire associative utilisée lors des accès indirects contient toujours (excepté lors des ruptures de séquence) l'adresse réelle en mémoire du segment de code.</footnote>
BIBLIOGRAPHIE

[1] J.B. Dennis, E. Van Horn
Programming semantics for multiprogrammed computations
Comm. ACM 9,3 (March 1966) p 143-155

[2] R.C. Daley, J.B. Dennis
Virtual memory, process, and sharing in Multics
Comm. ACM 11,5 (May 1968) p 306-312.

[3] D.M. England
Architectural features of system 250
Infotech State of the Art Report on Operating System, (1972)

[4] R.S. Fabry
Capability base addressing
Comm. ACM 17,7 (July 1974), p 403-411

[5] J. Ferrié, C. Kaiser, D. Lanciaux, B. Martin
An extensible structure for protected system's design
International Workshop on Protection in Operating Systems, IRIA (August 13-14, 1974)

[6] E.A. Feustal
On the advantages of tagged architecture
IEEE Trans. on computers C-22,7 (July 1973), p 644-656

[7] C. Kaiser, D. Lanciaux
Un modèle pour le traitement des erreurs dans un système à domaines
Note de travail LABORIA

[8] J. Gray, B. Lampson, B. Lindsay, H. Sturgis
The control of an operating system
IBM Research RC 3949 (July 1972)

[9] J.K. Iliffe
Basic machine principles
American Elsevier, New York, 1968

[10] B.W. Lampson
Protection
Proc. Fifth annual Princeton Conference on Information Sciences and Systems
Princeton University (March 1971), p 437-443

[11] R.M. Needham
Protection Systems and protection implementations
Proc. AFIPS 1972, FJCC, Vol 41, AFIPS press, Montvale, J.Y. p 572-578

[12] Plessey Company
System 250, Central processor general purpose reference manual report n° 97/73/37/TR

[13] S.H. Saltzer
Protection and the control of information sharing in Multics
Comm. ACM 17, 7 (July 1974), p 388-402

[14] R.D.H. Walker
The structure of a well protected computer
PhD University of Cambridge, (December 1973)
[15] M.V. Wilkes
Time-sharing computer systems
2nd ed., American Elsevier, New York, 1972

[16] B. Wulf, E. Cohen, D. Jefferson, T. Lane, R. Levin, F. Pollack
Hydra User's manual
Dept. Computer Science, Carnegie Mellon University, (November 1974)

[17] V.H. Yngve
The Chicago Magic Number Computer
ICR Quart. rep. 18 (November 1968)
ICR University of Chicago, sec. 1-B