# Etude d'un reseau arborescent de microprocesseurs pour la gestion decentralisee de processus complexes en temps reel

Daniel Serain, G Signor

► To cite this version:

Daniel Serain, G Signor. Etude d'un reseau arborescent de microprocesseurs pour la gestion decentralisee de processus complexes en temps reel. [Rapport de recherche] IRIA-RR-216, IRIA. 1977, pp.59. hal-04716481

HAL Id: hal-04716481

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

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_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
IRIA

laboria

Institut de Recherche
d'Informatique
et d'Automatique

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

laboratoire de recherche
en informatique
et automatique

ÉTUDE
D'UN RÉSEAU ARBORESCENT
DE MICROPROCESSEURS
POUR LA
GESTION DÉCENTRALISÉE
DE PROCESSUS COMPLEXES
EN TEMPS RÉEL

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

D. SERAIN
G. SIGNOR

Rapport de Recherche N° 216
Février 1977
# ÉTUDE D'UN RÉSEAU ARBORESCENT DE MICROPROCESSEURS POUR LA GESTION DÉCENTRALISÉE DE PROCESSUS COMPLEXES EN TEMPS RÉEL

D. Serain

IRIA/LABORIA

G. Signor

T.I.T.N.

1, rue G. Eiffel, Morangis

## Résumé :

Nous étudions dans ce rapport les problèmes de communication entre mini-processeurs hétérogènes interconnectés suivant une structure réseau. Certaines raisons, présentées dans ce papier, conduisent à penser qu'il est intéressant d'utiliser des micro-processeurs comme interface de communication des mini-processeurs. Les mécanismes logiciels et les différentes structures matérielles d'interconnexion sont présentés.

## Abstract :

In this report we study the communication among interconnected mini-processors in a network structure. For some reasons, given in this paper, it appears interesting to use micro-processors as communication front-end to the mini-processors. Software mechanisms and different hardware structures are described.
# SOMMAIRE

## I - INTRODUCTION

## II - DESCRIPTION DES MECANISMES DE COMMUNICATION

1. Introduction

2. Les structures de communication : les liens

3. Les portes

4. Les primitives de communication

5. Les messages

6. Les paquets

## III - LE SYSTEME DE TRANSMISSION

1. Les microprocesseurs dans un réseau de transmission

2. Le couplage du satellite au réseau

3. Schéma de dialogue entre deux processeurs

4. Aspect métériel

a. les systèmes d'entrée-sortie courants sur les mini-ordinateurs

b. différentes structures de couplage

## IV - REMARQUES SUR LES ARCHITECTURES DE RESEAUX

## V - LE LANGAGE DE COMMANDE

1. Introduction

2. Définition des primitives de communication et de contrôle

3. Exemples d'utilisation des instructions

## VI - CONCLUSION
# I - INTRODUCTION

Ce document fait suite au rapport n°1 rédigé par TITN dans le cadre de la convention de recherche n° 75.132 qui était une analyse critique du système réalisé au CERN. L'étude approfondie du système CERN, ainsi que l'observation d'autres réseaux ont permis de montrer ce que les utilisateurs pouvaient attendre d'un réseau d'ordinateurs et comment cela a été réalisé dans un cas bien défini.

Le réseau CERN, est un réseau homogène, en ce sens que tous les ordinateurs utilisés, périphériques et organe de commutation, sont les mêmes. Cela élimine un certain nombre de problèmes mais constitue une hypothèse trop restrictive. Dans cette deuxième phase de l'étude, nous allons voir comment nous pouvons lever cette hypothèse en utilisant des interfaces banalisés qui seront des microprocesseurs.

La structure d'un réseau (étoile, arborescence, boucle...) dépend essentiellement des applications. Il faudra que l'interface puisse s'adapter aux différentes structures. Nous ne traiterons pas les problèmes liés aux commutateurs, c'est-à-dire en fait l'aiguillage des messages. Ces points seront vus par ailleurs.

Un autre point important dans un système d'ordinateurs hétérogènes est le langage commun de dialogue. Il est intéressant que le processeur interface puisse interprèter une partie de ce langage, au moins les instructions de communication. Nous verrons comment cela pourra être réalisé par le microprocesseur.

Mais d'abord, nous allons étudier les mécanismes de communication dans une structure réseau d'ordinateurs.
## II - DESCRIPTION DES MECANISMES DE COMMUNICATION

### 1. Introduction

Nous étudions les problèmes de communication inter-processus, et processus-fichiers, dans une structure réseau d'ordinateurs faiblement connectés (de quelques mètres à plusieurs kilomètres).

L'approche prise consiste à représenter l'ensemble des processus et des fichiers sous la forme d'un réseau logiciel. Chaque noeud de ce réseau est soit un processus, soit un fichier. Les connexions de ce réseau sont les voix de communication ou de contrôle (inter-processus), ou d'accès (processus-fichiers).

Cette approche a le mérite de bien mettre en évidence la structure logique du travail à accomplir, et de séparer nettement la fonction de communication des fonctions de traitement et de mémorisation.

Exemple de représentation

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

Le processus P 1 peut accéder au fichier F 1

Les processus P 1 et P 2 dialoguent par l'intermédiaire du lien L 1.
De cette représentation se déduisent les différents points constituant
la fonction de communication :

1°) **Les différentes structures de communication** : les liens (définition et description à l'aide d'instructions spéciales constituant l'établissement de la structure de communication),

2°) **Les portes** : elles sont associées aux processus et représentent des capacités à faire quelque chose. A ces portes viennent se connecter les liens. Lorsqu'il s'agit d'un lien connecté à un fichier, la porte représente la capacité qu'a le processus à accèder au fichier. Lorsque le lien est connecté à un autre processus (au niveau d'une porte), la porte représente une capacité à communiquer avec, ou à contrôler cet autre processus,

3°) **Les primitives de communication au niveau du code des processus** :
Ces primitives émettent et réceptionnent des messages à travers les voies de communication définies au 1°),

4°) **Les messages** : entités d'information échangée entre les composants du réseau ; leur structure et leur type, sont à définir. Ces messages contiennent le langage du réseau,

5°) **Notion de paquets** : un message est une entité logique composée d'entités physiques appelées paquets. Sur les voies physiques de communication sont transférés des paquets. A ce niveau, les problèmes de détection de panne et de reconfiguration sont à considérer.

2. Les structures de communication : les liens

Les liens permettent de décrire la structure de connection des modules
logiciels que sont les processus et les fichiers. Ils permettent d'af-
fecter des ressources logicielles à un processus donné et de spécifier
la nature de cette connection. Le problème d'allouer les ressources du
réseau physique à ce réseau logique n'est pas abordé ici.
On distingue deux types de liens. Les liens de données existants dans les couples (processus-fichier) ou (processus-processus). Dans ce dernier cas, à l'intérieur du lien circulent des messages contenant des données échangées par deux (ou plusieurs) processus. Dans le premier cas, le lien indique seulement la capacité d'accès au fichier. Il n'a pas de réalisation concrète proprement dite.

Les liens de contrôle existants seulement entre des processus sont utilisés pour échanger des messages de type "système", c'est-à-dire des messages de contrôle d'une autre entité (interrompre, détruire, etc.).

## Différentes structures des liens inter-processus

Il semble intéressant de prédéfinir certaines structures de communication très courante. Le problème peut être présenté comme suit :

Soit n processus émetteur + m processus récepteur

Ils communiquent par l'intermédiaire d'une file d'attente. (communication unidirectionnelle).

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

Les différentes structures de communication consistent à définir le nombre d'émetteurs, le nombre de récepteurs et la fonction effectuée sur la file d'attente. Les structures retenues (qui nous semblent les plus courantes) sont :
- *structure point-à-point* (ou simple)

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

Un processus A envoie des messages à un processus B. Chacun des
processus connaît le nom de l'autre.

- *structure de diffusion*

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

Chaque message émis par le processus A est reçu par tous les
processus $B_i$.

- *structure lecture multiple*

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

chaque message déposé par le processus A dans le file d'attente est reçu par un seul processus $B_1$. Le processus est celui qui a accédé le premier à la file d'attente.

- *structure écriture multiple*

<figure><img src="image_8.png" /></figure>
Tous les processus $A_1$ déposent leurs messages dans la même file d'attente. Ils savent donc le nom du récepteur $B_1$ (car il est unique), alors que le processus $B_1$ ne connaît pas le nom de l'émetteur d'un message (car il y a plusieurs émetteurs). On peut cependant distinguer les émetteurs en leur demandant de positionner un indicateur dans le message lui-même.

- structure de concentration

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

Un message n'est disponible pour $B_1$ que lorsque n messages ont été déposés dans la file d'attente.

Si le lien est de type **contrôle**, le message disponible pour $B_1$ est un signal (message **booléen**).

Syntaxe de déclaration d'un lien

- **syntaxe** : LIEN <nom-lien> , ({émetteur}→{récepteur}) , <capacité>,<type-lien> , <structure-lien> ;

EXEMPLE :

LIEN LI , (A→B) , P , DONNEES , SIMPLE ;

- remarque

Le fait de connaître à l'avance la structure de connection des
modules logiciels permet d'initialiser les tables du système
de communication appartenant au réseau matériel. Ce point sera
abordé au niveau de l'implémentation.
### 3. Les portes

Ce sont des entités associées aux processus qui représentent leurs capacités externes. Ce sont les capacités :

- d'accéder à un fichier,

- d'envoyer des données à un autre processus,

- de recevoir des données d'un autre processus,

- de contrôler un autre processus.

Les primitives de communication utilisées pour émettre et recevoir des messages utilisent les noms de portes et non pas les noms des entités avec lesquelles elles communiquent. Ceci permet d'écrire séparément le code des processus sans avoir à connaître le nom des autres entités avec lesquelles il va communiquer.

Sur une porte, se connectent au plus un lien d'entrée et un lien de sortie.

Nous verrons par la suite l'ensemble des fonctions associées à une porte au niveau de l'implantation (gestion des tampons de communication, etc.).

### 4. Les primitives de communication

Deux primitives de communication sont utilisées pour échanger des messages entre processus.

Pour émettre des messages sur les liens, les processus utilisent la primitive ENVOYER.
## Syntaxe

### ENVOYER

```
[<nom-porte>, <ad-message>, <nom-retour>, <L/R (fonction)>]
```

* `<nom-porte>` : nom de la porte à travers laquelle le message sera acheminé.

* `<ad-message>` : adresse mémoire où se trouve le message.

* `<nom-retour>` : nom du processus devant recevoir la réponse associée à ce message s'il elle existe.

* `<L/R (fonction)>`

: type du message. Si type = L (lent), il s'agit d'un message de données. Si le type = R (rapide), il s'agit d'un message de contrôle et une fonction lui est associée. Celle-ci est écrite à l'intérieur du message.

## Sémantique

Cette primitive permet d'émettre des messages de données et de contrôle. (Les messages de données circulent dans des liens de type données et les messages de contrôle dans des liens de type contrôle).

### Primitive de réception de message

#### Syntaxe

#### RECEVOIR

```
[<nom>, <ad>]
```

* `<nom-porte>` : nom de la porte à laquelle le lien "transportant" le message est rattaché.

* `<ad>` : adresse où est rangé le message
## Sémantique -

La primitive RECEVOIR permet de lire le premier message se trouvant dans la file d'attente associée à la porte nomporte. S'il n'y a aucun message, le processus exécutant cette primitive est désactivé. S'il y a un message, celui-ci est retiré de la file de communication par l'exécution de la primitive RECEVOIR. Ceci schématise d'un message de type donnée.

## 5- Les messages -

Les messages représentent l'information à véhiculer entre deux processus. Ils sont composés de deux parties. L'une fixe, contenant un descriptif du message et le corps qui contient l'information proprement dite.

### Description de l'entête -

- type du message données ou contrôle,

- fonction du message. C'est une fonction à réaliser sur ou par l'entité réceptrice. Cette fonction appartient au langage de commande.

- nom-retour : nom du processus auquel on doit retourner le message réponse associé à ce message. (facultatif : seulement s'il y a un message réponse).

- priorité : rapide/lent. On distingue deux vitesses de circulation des messages. Les messages rapides et les messages lents.

- descripteur de la partie corps : décrit des données contenues dans le corps du message (paramètres, instructions, mots d'erreur, fichiers).
- `<longueur du corps>` : longueur du corps du message. Si les messages sont de type "rapide" ils ont une longueur limitée (message dit "court").

### Remarque

Les messages n'ont pas de numéro (ce qui évite d'avoir un générateur de noms). Ceci peut poser un problème dans certaines configurations. Considérons l'exemple suivant qui représente la communication entre deux processus.

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

L'ordre des messages réponse pouvant être quelconque, on ne sait pas à l'arrivée d'un message à quelle question il est associé.

Mais dans la pratique il n'est pas très contraignant d'interdire de n'exécuter une seconde primitive ENVOYER sur un même lien que lorsque la réponse de la première primitive est revenue.

## 6. Les paquets

La notion de paquets existe au niveau des lignes physiques d'échange. Des procédures sont définies pour gérer le transfert de ces paquets. Un paquet est une chaîne de bits de longueur fixe. C'est l'entité minimale de transfert. Un message est décomposé en un ou n paquets, à un message court est associé un paquet.
III - LE SYSTEME DE TRANSMISSION

1. Les microprocesseurs dans un réseau de transmission

Dans un réseau de transmission , 3 emplacements sont possibles pour
des microprocesseurs.

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

- Organe de commutation

C'est le commutateur central d'un réseau en étoile, l'organe de contrôle de boucle (UCB) dans un anneau, un noeud dans un réseau arborescent ou de type général. Pour remplir cette fonction, des miniordinateurs sont utilisés dans les réseaux actuellement en fonctionnement (CII Mitra 15 pour Cigale, Honeywell DDP 516 pour A R P A, Nord 10 de Norskdata pour le CERN...) Fonctionnellement le rôle d'un microprocesseur serait identique, mais les performances de ces appareils ne permettent pas encore leur utilisation pour peu que les transmissions soient rapides ou les liaisons nombreuses. Ce problème n'est pas étudié dans ce rapport.
- satellite

Le microprocesseur doit alors remplir à la fois des fonctions de commutation et des fonctions propres aux périphériques qui lui sont connectés. S'il ne peut supporter seul cette charge, un deuxième microprocesseur lui sera associée et on se ramène à une structure de type (3).

- interface

Dans un réseau homogène, le protocole de transmission est géré par une logique câblée souvent assez lourde ou directement par le processeur satellite. Lorsque les ordinateurs connectés sont de types différents, la communication directe est impossible sans l'intermédiaire d'un matériel et d'un logiciel spécialisé. Les prix relativement bas et la grande souplesse des microprocesseurs doivent permettre de réaliser des interfaces dont les principales fonctions seront les suivantes :

* remplacement de la logique câblée qui gère les transmissions, gestion des interruptions, des entrées/sorties, des accès directs mémoire ; contrôle des erreurs en ligne (parité) et des temporisations.

* déchargement du satellite de certaines fonctions de communication, gestion des interruptions, formattage des paquets, gestion de l'ensemble des tampons libres.

* interprétation d'une partie du langage de commande de réseau et en particulier les commandes d'interaction.

L'intérêt du microprocesseur comme interface est donc de soulever le satellite d'une grande partie des fonctions de communication, et aussi de normaliser les transmissions si des ordinateurs de types différents sont connectés au réseau. C'est cet aspect du problème que nous allons étudier plus particulièrement.
## 2. Le couplage du satellite au réseau

Le satellite est relié au réseau par l'intermédiaire d'un microprocesseur. Il y a deux liaisons à considérer : vers l'aval du microprocesseur au satellite, vers l'amont du microprocesseur au réseau.

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

Vers l'amont, la différence essentielle entre les couplages est le nombre de lignes de transmission. On suppose que des lignes "full duplex" sont utilisées.

Souvent l'infrastructure existante ou le prix de location des lignes obligent l'emploi d'une seule ligne de transmission. Les commandes et les données sont différenciées par des octets de contrôle, ce qui nécessite une logique spéciale, généralement câblée. Si les vitesses de transmission ne sont pas trop grandes, ce rôle peut être confié au microprocesseur.

Pour les réseaux locaux à grande vitesse de transfert, il est intéressant de séparer physiquement les commandes et les données en les faisant transiter sur deux lignes différentes. Les données sont rangées directement dans la mémoire du satellite ou du microprocesseur, et les commandes agissent par interruption sur le microprocesseur.
<figure><img src="image_13.png" /></figure>

Interface
d'entrées-sorties

1 ligne "full duplex"

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

Interface
accès direct mémoire

2 lignes "full-duplex"

Vers l'aval, un certain nombre de solutions sont possibles suivant les vitesses de transmission demandées et les interactions micro-processeur-satellite.

Le plus simple est de se servir du système d'entrées-sorties programmées des deux processeurs. Mais cela nécessite une interruption pour chaque mot échangé et est évidemment coûteux en temps d'unité centrale du satellite. Ce procédé s'applique bien lorsque le terminal n'a pas de mémoire (imprimante, visu...).

Lorsque l'échange des données entre le réseau et le terminal se fait à grande vitesse l'accès direct mémoire s'impose. Il peut se faire soit dans la mémoire du micro, soit dans une mémoire commune qui serait celle du satellite. La première solution impose un coupleur supplémentaire entre les deux mémoires... l'accès par mémoire commune semble intéressant mais pose un certain nombre de problèmes, liés en particulier à la gestion de la mémoire du satellite par le microprocesseur.
<figure><img src="image_15.png" /></figure>

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

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

Nous allons étudier deux solutions particulières. La première lente pourrait s'appliquer à des lignes téléphoniques, la deuxième, plus rapide à des réseaux locaux. Mais auparavant, nous décrirons le schéma logique de dialogue entre deux Processus et les systèmes d'entrées-sorties les plus courants sur les miniordinateurs.
### 3. Schéma logique de dialogue entre deux processus

#### a. introduction

Soient deux processus $P_1$ et $P_2$ dialoguant à l'aide de messages déposés dans des files d'attente. Le schéma du dialogue peut se présenter comme suit :

<figure><img src="image_18.png" /><figcaption>figure 1</figcaption></figure>

L'envoi d'un message par le processus $P_1$ vers le processus $P_2$ s'écrit ainsi :

ENVOYER [ $p_1$ , <ad-message> , $P_1$ , L/R]

Un problème pouvant se poser est que la file d'attente $P_1$ soit pleine. Il n'est alors pas possible d'y déposer le message. Dans ce cas le processus est désactivé jusqu'à ce que la file de communication libère la place disponible.

Deux types de messages existent. Si le message est de type **rapide**, l'action de le déposer dans la file d'attente génère une interruption afin de connaître sa priorité. Si le processus $P_2$ n'est pas en cours d'exécution, une analyse du message est nécessaire afin de savoir ce qu'il représente, c'est-à-dire "demande d'activation", "arrêt du travail en cours", etc. Une unité doit donc faire cette
analyse. Cette entité est activée au moment du dépôt du message.

Si le message est de type *lent*, son dépôt dans la file d'attente ne doit pas perturber l'exécution du processus $P_2$ si celle-ci est en cours d'exécution. Cependant, si le processus $P_2$ n'est pas en cours d'exécution, c'est peut-être qu'il est en attente de ce message. Il est alors nécessaire de vérifier ce fait. Si cela est vrai, l'état du processus doit être changé afin de le rendre éligible pour être exécuté.

Un problème de recopie du message transféré apparaît. Le processus $P_1$ prépare le message dans sa zone mémoire. Lorsque celui-ci est prêt à être émis, le processus $P_1$ peut soit déposer dans la même file d'attente l'adresse du message ou le message lui-même. Le fait de déposer l'adresse du message présente plusieurs avantages :

- une adresse est de longueur fixe donc la structure et la gestion de la file d'attente est simplifiée,

- on évite une recopie du message dans la file d'attente, puis une autre recopie dans la mémoire du receveur $P_2$.

Cependant plusieurs inconvénients apparaissent :

- le processus $P_2$ va lire le message directement dans l'espace mémoire du processus $P_1$. Ceci est dangereux du point de vue de la protection,

- le processus $P_1$ ne sait pas quand sera libérée sa mémoire qui contient le message. La gestion mémoire devient alors très compliquée. (En effet, la fin d'exécution du processus $P_1$ n'implique pas que le processus $P_2$ ait lu le message).
Nous nous plaçons bien évidemment dans le cas où les deux processus sont implantés sur la même machine. Là, un problème de gestion mémoire existe. Afin de le résoudre, la stratégie suivante a été adoptée.

## b. gestion des files d'attente

La file d'attente en entrée d'un processus est gérée par ce processus lui-même. Elle fait partie intégrante de la porte à laquelle elle est connectée. Ainsi dans la figure 1, la file d'attente $F_1$ est gérée par l'entité porte $p_2$.

Le mécanisme est le suivant :

Le processus $P_1$ exécute la primitive ENVOYER sur la file d'attente $F_1$. Si un bloc est libre, le processus $P_1$ recopie son message dans le bloc. Il peut alors disposer de sa propre mémoire. Si la file d'attente est pleine, il positionne un indicateur signalant qu'il veut déposer un message et se désactive. Pour retirer un message sur la file d'attente $F_1$, le processus $P_2$ n'a pas à recopier le message. C'est lui-même qui décidera quand libérer la mémoire occupée. Cependant le processus $P_2$, lorsqu'il libère un tampon de la file d'attente, doit s'assurer que le processus $P_1$ n'est pas bloqué faute de place dans la file d'attente. Il doit donc tester le mot d'état.

Afin d'éviter tout problème de blocage, un processus lorsqu'il demande à recevoir un message doit s'assurer qu'il a la place mémoire pour le recevoir. Ainsi, si le processus $P_1$ envoie un message à $P_2$ afin de lui demander des informations, il doit s'assurer que la file d'attente $F_2$ possède au moins un tampon de libre pour recevoir ce message réponse.
- organisation d'une file d'attente

Une file d'attente doit permettre de conserver l'ordre des messages de même priorité. Aussi la structure prise est celle d'une liste circulaire à double chaînage :

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

Deux pointeurs sont utilisés :

pointeur TETE : pointe sur le premier bloc plein

pointeur QUEUE : pointe sur le dernier bloc plein

( les blocs pleins sont ajoutés à l'aide du pointeur QUEUE et les blocs sont vidés à l'aide du pointeur TETE ).
- algorithme de la primitive ENVOYER

ENVOYER [ p₁, <ad-message>, P₁, L/R (f) ]

<figure><img src="image_20.png" /></figure>
- *Algorithme de la primitive RECEVOIR* pour la réception d'un message lent

RECEVOIR [ <nom-porte> , <ad> ]
p_2

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

Remarque : cet algorithme est activé soit par l'exécution de l'instruction RECEVOIR décidée par le processus lui-même, soit sur une interruption.
- *Algorithme de la primitive RECEVOIR* pour la réception d'un
  message rapide

RECEVOIR [ <p2> , <ad> ]

ALGORITHM

<table>
  <tr>
    <td>lire message</td>
  </tr>
  <tr>
    <td>(avec libération</td>
  </tr>
  <tr>
    <td>du tampon)</td>
  </tr>
</table>

Remarques :

. cet algorithme est activé par l'interruption générée par le
dépôt du message dans la file d'attente,

. la file d'attente est supposée avoir une taille suffisante
pour qu'elle ne déborde jamais.

Généralement, cela est possible. Ainsi, au CERN, on sait qu'il
peut arriver au maximum un message d'interruption toutes les
millisecondes.
- Remarques

les primitives ENVOYER et RECEVOIR sont des primitives systèmes dont le code n'est pas accessible par l'utilisateur. Elles peuvent aussi aller écrire des messages dans l'espace des utilisateurs eux-mêmes,

les mécanismes d'interruption mis en oeuvre, l'activation de certaines routines, la gestion des tampons sont des activités particulières qui peuvent être regroupées au niveau de l'en-tité porte,

dans cette étude, nous considérons que les processus sont implantés sur le même ordinateur. Il convient de regarder la réalisation du mécanisme sur une structure réseau,

il existe en fait une file d'attente pour les messages rapides et une file d'attente pour les messages lents. Ceci afin d'homogénéiser le traitement des fonctions de dépôt et de retrait et surtout d'assurer que les messages rapides peuvent toujours passer. La figure 1 devient :

<figure><img src="image_22.png" /><figcaption>Figure 2
(ceci sera justifié également à posteriori).</figcaption></figure>
c. Dialogue entre deux processus ne résidant pas sur le même ordinateur.

Le dialogue présenté au paragraphe précédent supposait les deux processus implantés sur la même machine. Nous considérons le cas d'un réseau d'ordinateurs et nous voudrions que deux processus, quelque soit leur lieu d'implantation utilisent les mêmes protocoles de dialogue.

Indépendamment de la structure du réseau, il paraît intéressant d'implanter la fonction de communication d'un mini-ordinateur sur un microprocesseur. Ceci a l'avantage de libérer le mini de cette fonction et donc aussi de rendre le réseau hétérogène au niveau des mini utilisés. De plus, le microprocesseur peut également faire de l'interprétation sur ces messages.

Une telle organisation matérielle conduit à l'organisation logicielle très générale, suivante :

<figure><img src="image_23.png" /><figcaption>Figure 3</figcaption></figure>
Dans la figure 3, le processus D.M.A. (Direct Memory Access), dépose le message en provenance du réseau dans une file d'attente de la mémoire du microprocesseur. Le microprocesseur après un certain travail sur ce message le recopie dans la file d'attente du processus destinataire se trouvant dans la mémoire du mini-ordinateur.

Cette organisation va maintenant être étudiée en détails afin de voir comment on peut concilier les points suivants, tout en tenant compte de certains paramètres de l'architecture du matériel :

* réduire le nombre de recopies d'un message,

* messages lents et messages rapides,

* messages longs,

* possibilité d'interprétation des messages par le microprocesseur.

- Différienciation : message lent/message rapide

Si l'on se réfère à la figure 3, on voit qu'un message émis par un processus $P_1$ appartenant à un mini-ordinateur $T_1$, pour un processus $P_2$ appartenant à un mini-ordinateur $T_2$, transité au moins par quatre files d'attente. (Nous verrons comment ce nombre peut être réduit). Si l'on veut assurer qu'un message urgent puisse toujours circuler, donc qu'il y a toujours de la place dans les diverses files d'attente, il apparaît intéressant de faire des files d'attente séparées. (En effet, les messages lents étant de longueur très variable, on peut arriver à une saturation d'une file d'attente). La figure 3, en fait devient la structure de communication représentée par la figure 4.
<figure><img src="image_24.png" /><figcaption>Figure 4</figcaption></figure>

L = message lent

R = message rapide

- Les messages longs

Une file d'attente est composée de blocs de taille fixe. Un message est un ensemble de blocs. Un message court est un message qui ne comprend qu'un seul bloc.

Avec les messages longs des problèmes de blocage apparaissent. Considérons l'exemple suivant (réseau à structure étoilée):

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

Supposons que les satellites B et C veulent émettre simultanément un message long ($L_1$ pour B et $L_2$ pour C) pour le satellite A. Supposons que la file d'attente d'entrée de A possède cinq blocs. Si le noeud étoile du réseau, par où transitent tous les messages, émet vers A les blocs dans leur ordre d'arrivée, on peut avoir la séquence suivante :

$B_1, C_1, B_2, C_2, B_3$ (soit cinq blocs).
Afin d'éviter ce problème, le noeud étoile, lorsqu'il s'agit de messages longs, ne les réémet pas mélangés entre eux vers un autre noeud. Un noeud ne peut recevoir qu'un message long à la fois. Il ne semble pas bon de reconstituer les messages longs au niveau de l'étoile. En effet cela ralentit la transmission du message car le destinataire ne commence à le recevoir que lorsqu'il est arrivé en entier au niveau de l'étoile. Cela conduit également à un engorgement de l'étoile. Si plusieurs messages longs sont en cours de réception l'étoile n'en émettra aucun tant qu'il ne sera pas complet. Il faut alors un seuil au delà duquel la stratégie de l'étoile est de bloquer toutes les émissions vers elle, sauf celles relatives au message le plus long qu'elle est en train de reconstituer. Nous préferrons donc la stratégie qui consiste à émettre un message long au niveau de l'étoile, au fur et à mesure de son arrivée, en évitant d'insérer des blocs d'un autre message long. Nous autoriserons cependant l'insertion des messages courts au milieu des messages longs.

- *Implémentation des algorithmes de dépôt et de retrait des messages dans les diverses files d'attente*

* file d'attente entre D.M.A. et micro-processeur :

Un message en provenance du réseau est reçu par le coupleur D.M.A. qui doit le déposer dans la file d'attente du processeur.

Le mécanisme est le suivant :

Au D.M.A. est associé un tampon libre de la taille d'un bloc.

Le D.M.A. recopie le message en cours de réception dans ce tampon,

Les tampons sont gérés par le processeur. Lorsque le nombre de tampons libres descend en dessous d'un seul $s_1$, le D. M. A. envoie un message de contrôle à l'étoile lui signalant de stopper l'envoi des messages non urgents (sauf celui en cours) L'algorithme à la réception d'un message est le suivant
(D.M.A.)

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

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

µ Processeur

<figure><img src="image_28.png" /></figure>
## Remarque

Le traitement effectué sur le message par le processeur est un travail de mise en forme et d'interprétation. Lorsqu'il s'agit d'un message contrôle, il regarde s'il lui est destiné, sinon il l'interprète. (La séquence d'interprétation est directement accessible). Il exécute donc la séquence d'interprétation en y insérant les paramètres se trouvant dans le message.

## Algorithme d'émission d'un message

Le processus qui s'exécute sur le mini-processeur structure son message dans un tampon. La primitive d'émission ENVOYER s'exécute ainsi :

<figure><img src="image_29.png" /></figure>
### Remarque

La fonction ENVOYER doit créer l'entête du message. Pour cela elle a besoin de connaître le numéro de tâche du processus auquel elle appartient (pour le cas d'un message retour). Dans l'entête, elle doit indiquer le nom du destinataire, la priorité du message, l'adresse du corps du message, et le code fonction.

### µProcesseur

Le processeur interprète l'entête du message reçu. Il conserve certaines informations, met en forme et traduit le message dans le langage du réseau. Le message est alors inséré dans la file d'attente d'émission vers le réseau.

## 4. Aspect matériel

### a. les systèmes d'Entrées/Sorties courants sur les mini.

#### - Unibus

Unibus est un chemin de données valable pour les transferts sous le contrôle de l'unité centrale (mode programme, sur

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

L'unibus est un chemin de données valable pour les transferts sous le contrôle de l'unité centrale (mode programme, sur
interruption) et par accès direct à la mémoire. Ce type de bus comprend en général un nombre de lignes assez élevé :

• données unidirectionnelles ou bidirectionnelles,

• lignes d'adresse,

• lignes d'interruption,

• lignes de service.

- bus_programme et bus mémoire

Type Mitra 15

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

Le système de gestion de bus mémoire permet 4 accès hierarchisés en simultanéité apparente. L'unité d'échanges multiplexés (U. E. M.) travaille par une méthode de boîte à lettres dans une partie de la mémoire commune avec l'unité centrale.

Le minibus est utilisé pour les échanges avec l'unité centrale en mode programme ou par canal microprogrammé.

- généralisation du cas précédent - Mitra 125

<figure><img src="image_32.png" /></figure>
3 processeurs d'entrée - sortie (I. O. P.) sont possibles

les I. O. P. travaillent par accès direct à la mémoire avec lecture de table et comportent un microprocesseur pouvant réaliser des traitements.

- canal multiplexé

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

commandes, lectures d'état, interruptions

- le système d'entrées - sorties du 8080 (Intel)

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

8 niveaux d'interruption sont directement possibles. A chaque niveau correspond une zone mémoire de 8 octets. Il existe des boîters permettant de multiplexer les interruptions.

une ligne "hold" donne lieu à un blocage de l'unité centrale quand elle est maintenue. Ceci peut permettre une synchronisation pour l'accès à la mémoire d'un périphérique.
## b. Différentes structures de couplage

### - solution lente (figure 1)

Le microprocesseur gère la ligne c'est-à-dire qu'il acquiert ou transmet les messages sur la ligne aussi bien les commandes que les données, vérifie que la transmission est correcte sinon, il redemande une transmission ou fait les corrections. A partir du message reçu qu'il a mis dans sa mémoire, il fait un prétraitement éventuellement (élimination de caractère de synchronisation, etc.) et constitue un buffer pour l'envoyer vers la mémoire du mini.

Le microprocesseur contrôle également le transfert mémoire-mémoire c'est-à-dire qu'à partir de données que lui fournit le mini par une liaison programmée (adresse du début du buffer dans la mémoire du mini, compte de mots), il transmet ces informations à la logique de transfert mémoire-mémoire et il donne l'autorisation du transfert. Le transfert s'effectue de manière transparente pour le microprocesseur. A la fin du transfert le microprocesseur reçoit un compte rendu permettant en cas d'erreur, de recommencer, sinon, il prévient le mini par la liaison programmée que le transfert s'est correctement passé.

### Réception d'un message

Le message est transmis caractère par caractère. A chaque caractère, le microprocesseur reçoit une I.T., et il range les caractères les uns à la suite des autres dans sa mémoire. Il vérifie qu'il n'y a pas d'erreur de parité horizontale, qu'il n'a pas perdu de caractère. A la fin de la réception du message, il vérifie que la transmission s'est effectuée correctement : pas d'erreur de parité verticale, pas de manque de caractère.
Si tout s'est bien passé, il doit signaler à l'émetteur que la transmission est correcte. A partir de ce moment pour ce message, le problème de transmission est terminé, le message est rangé en mémoire dans un buffer.

A partir de ce buffer, il en constitue un deuxième qui sera celui qui sera envoyé à la mémoire du mini. Le microprocesseur peut faire un prétraitement du message reçu (élimination éventuelle de caractère, transcodage, etc.) Une fois que son traitement est fini, il prévient le mini par la liaison programme qu'il a reçu un message avec éventuellement certaines caractéristiques du message (signification, longueur...).

Le mini lui renvoie en réponse l'adresse où il doit aller implanter le message.

Une fois reçu ces données, le microprocesseur initialise le transfert mémoire-mémoire en donnant l'adresse de son buffer dans sa mémoire, l'adresse d'implantation dans la mémoire du mini et le compte de mots à transférer. A partir de cela, le transfert s'effectue sans intervention du microprocesseur ni du mini.

La logique vient prendre deux octets dans la mémoire du microprocesseur en D.M.A. pour en faire un mot de 16 bits, fait une demande d'accès mémoire au mini qui une fois acceptée entraînera l'écriture du mot de 16 bits à l'adresse indiquée par la logique. On recommencera ce cycle jusqu'à ce que le compte de mots soit nul.

Un fois le transfert terminé la logique de transfert fera une I.T. au microprocesseur lui signalant la fin du transfert. Le microprocesseur vérifie que le transfert s'est bien passé
sinon il recommence le transfert.

Si cela s'est bien passé, le microprocesseur par la liaison programmée, prévient le mini que le transfert est terminé et que le message est dans sa mémoire.

## Emission d'un message

L'émission d'un message peut être à l'initiative du microprocesseur (sur réception d'un message) ou du mini. Supposons que ce soit le mini.

Le mini par la liaison programmée envoie un ordre signifiant au microprocesseur de transférer un bloc sur la ligne (éventuellement seulement dans la mémoire), le microprocesseur répond qu'il est prêt et le mini lui donne l'adresse du bloc et son compte de mots.

Le microprocesseur initialise la logique de transfert en donnant l'adresse du bloc dans la mémoire du mini, le compte de mots et l'adresse du bloc dans la mémoire du microprocesseur. Le transfert commence, et il est transparent pour le microprocesseur.

La logique de transfert lit un mot dans la mémoire du mini puis vient l'inscrire dans la mémoire du microprocesseur (éventuellement en plusieurs fois, si les longueurs des mots mémoires sont différentes). Quand il n'y a plus de mots à transférer, la logique de transfert fait une I.T. au microprocesseur qui vérifie que le transfert s'est bien passé (sinon il recommence). Le microprocesseur prévient le mini que le transfert est terminé (cas mémoire à mémoire).
Le micro traite le bloc pour en faire un buffer qui sera émis
sur la ligne : adjonction de mots, de contrôle et de mots
de commande, etc.

Il commence le transfert mot par mot, une I.T. étant générée
à chaque envoi de mots.

Quand il a fini la transmission, il attend le compte rendu
du récepteur pour savoir si la transmission s'est bien passée.

Quand la transmission est correcte, il prévient le mini que
la transmission est terminée.
MINI

bus microprocesseur

<figure><img src="image_35.png" /><figcaption>FIGURE 1</figcaption></figure>
# Solution rapide

Le microprocesseur gère la ligne de commande (émission, réception des commandes, traitement éventuel des erreurs de transmission). La transmission se fait mot par mot sans interruption.

Le µP gère la ligne de données (émission, réception des données, traitement éventuel des erreurs de transmission). L'échange entre la logique de serialisation vers la ligne et le buffer contenu dans la mémoire du microprocesseur se fait en accès direct mémoire, c'est-à-dire que le C.P.U. initialise le transfert en accès direct mémoire (compte de mots, adresse du début du buffer). A partir de l'initialisateur, le transfert est transparent pour le C.P.U. A la fin du transfert, le contrôleur D.M.A. envoie une I.T. au C.P.U. qui doit vérifier que le transfert s'est passé correctement.

Le µP permet des échanges mode programmés avec le mini, ces échanges se font sans interruption.

Le µP gère le transfert mémoire Mini, mémoire µP. Cet échange côté µP se fait par accès direct mémoire. Le µP initialise le transfert en donnant l'adresse de début du buffer dans la mémoire du mini, l'adresse de début du buffer dans la mémoire du µP, et le compte de mots à échanger. A partir de l'initialisation, le transfert se fait de manière transparente pour le µP. A la fin du transfert, la logique de transfert envoie une I.T. au µP qui doit vérifier que le transfert s'est bien déroulé, sinon il recommence.
Réception d'un message

Le message se compose de commandes et de données. Les commandes sont reçues ou émises caractère par caractère sans interruption et les données sont transférées par accès direct mémoire.

Le microprocesseur reçoit les commandes caractère par caractère, il vérifie que la transmission est correcte (pas d'erreur de parité, pas de perte de caractère, structure des commandes correctes) sinon, il redemande la transmission. Une fois que la transmission est bonne, il décode le message et il initialise en conséquence la logique d'accès direct mémoire pour les données (adresse de début du buffer compte de mots) puis il envoie un message sur la ligne de commande pour signaler à l'émetteur qu'il peut envoyer ses données.

Le transfert des données se fait.

Un fois le transfert terminé, la logique fait une interruption. Le µP vérifie alors que le transfert s'est effectué sans erreur.

Le µP traite alors le bloc commande + données pour faire le buffer qu'il enverra dans la mémoire du mini (élimination éventuelle de caractère, etc.).

Le µP signale, par la liaison programmée, au mini qu'il a reçu un message, en lui donnant les caractéristiques (signification, taille du message).

Le mini, par la liaison programmée envoie au µP l'adresse du début du buffer dans sa mémoire.
Le µ P initialise la logique de transfert mémoire-mémoire
(adresse du buffer dans la mémoire du mini, adresse du début
du buffer dans la mémoire du µ P, compte de mots à transferrer).
Le transfert s'effectue sans intervention ni du microprocesseur
ni du mini.

La logique du transfert vient prendre deux octets dans la mémoire du µ P en D.M.A., en fait un mot de 16 bits pour le mini, fait une demande d'accès mémoire au mini qui, quand elle est acceptée, déclenche l'écriture du mot de 16 bits à l'adresse commande du buffer mémoire du mini. On recommence jusqu'à ce que le compte de mots soit nul.

Quand le transfert est terminé, la logique fait une interruption
au µ P. Qui vérifie qu'il n'y a pas eu d'erreur de transfert
(sinon on recommence le transfert).

Quand il n'y a plus d'erreur le µ P signale au mini que le message est dans sa mémoire.

Emission d'un message

L'émission d'un message peut être à l'initiative du mini ou du
µ P (sur réception d'un message précédent). Surposons que ce soit
le mini.

Le mini par la liaison programmée signale au µ P qu'il doit
transferrer un message sur la ligne. Le micro répond quand il est
prêt et le mini lui donne l'adresse du buffer à transferrer ainsi
que sa taille.

Le micro initialise la logique de transfert mémoire-mémoire
(adresse buffer mini, adresse buffer µ P, compte de mots). Le
transfert s'effectue de manière transparente pour le µ P et le
mini.
A la fin du transfert, une I.T. est générée, le µP vérifie que le transfert s'est correctement effectué (sinon on recommence le transfert). Il prévient le mini que le buffer a été transféré de sa mémoire.

Il envoie le buffer commande sur la ligne, caractère par caractère, sans interruption, et il attend la réponse du récepteur lui signalant qu'il peut envoyer les données.

Lorsque la réponse lui parvient, il initialise le transfert D.M.A. (compte de mots, adresse buffer) et le transfert s'effectue. A la fin, le µP reçoit une I.T., il vérifie que le transfert s'est effectué correctement, et il signale au mini que le transfert sur la ligne est terminé.
<figure><img src="image_36.png" /><figcaption>FIGURE 2</figcaption></figure>
## IV - REMARQUES SUR LES ARCHITECTURES DE RESEAUX

Dans le premier rapport, nous avons décrit et donné les caractéristiques d'un certain nombre de réseaux de communication. Les structures les plus utilisées sont :

- l'étoile (type CERN)

- les boucles :

- avec unité de contrôle de boucle qui interroge les ordinateurs connectés ou dans d'autre cas est interrogée par eux,

- sans unité de contrôle de boucle, chaque satellite, à tour de rôle fait alors office d'U.C.B.

- l'arborescence.

Ces trois architectures sont caractérisées par le fait qu'il existe au plus un chemin entre deux périphériques du réseau (sauf pour certaines boucles bidirectionnelles),

- le réseau général (ARPA par exemple)

Ce dernier est en théorie celui qui permet les meilleures performances. Mais c'est aussi le plus complexe si l'on tient compte des problèmes de routage des paquets, de déroutements en cas de panne ou saturation, etc. Il semble intéressant de comparer les trois autres structures et de voir les différents points permettant au concepteur de faire un choix.

### Le débit

Dans le cas d'une structure étoilée, on est limité par les performances du commutateur central. Le temps de l'accès direct mémoire permet de déterminer le débit maximum de l'ordinateur central. Mais le nombre de mots reçus ou émis par seconde dépend d'autres paramètres. En particulier du temps de traitement d'un message et de la capacité de stockage du commutateur.
**Arborescence** : si tous les messages passent par le niveau le plus haut, on se ramène au cas de l'étoile à quelques variantes près (possibilité de stockage dans les mémoires des ordinateurs des niveaux intermédiaires). Par contre, il peut y avoir des messages entre éléments d'une même branche.

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

Une telle structure permet de grouper sur une même branche des processus échangeant beaucoup de messages.

**Boucle** : les périphériques sont reliés à la boucle par un interface qui permet en général de stocker un message. Dans certaines configurations l'interface vérifie si le message est pour le satellite hôte. Si oui, il envoie un accusé de réception vers l'émetteur, si non, il réémet le message dans la boucle. De telles configurations permettent des débits assez élevés et le débit croit avec le nombre de périphériques connectés.

## Le délai de transmission

Il dépend du temps de transmission sur les lignes et de la durée du transit d'un paquet à l'intérieur du réseau. On définit le délai à vide (le paquet étant le seul reçu par le réseau), et le temps maximum en période de pointe pour le paquet le plus court et le plus prioritaire.

Le délai de transmission à vide pour un destinataire quelconque est minimum pour l'étoile, le nombre de noeuds à traverser étant toujours égal à l'unité. Pour les autres configurations, le problème se complique.
Cela dépend essentiellement des positions respectives de l'émetteur et du récepteur. Une structure arborescente permet encore de favoriser les liaisons entre certains périphériques particuliers.

## Sécurité - fiabilité

L'étoile et la boucle unidirectionnelle ne sont pas très sûres. Dans les systèmes où une grande fiabilité et une grande disponibilité sont demandées, il est conseillé de doubler le commutateur central, ou d'utiliser des boucles bidirectionnelles.

La panne d'un des noeuds d'une arborescence n'affecte qu'une partie du réseau. Mais le chemin entre un émetteur et son destinataire est là aussi unique. C'est donc dans cette configuration que les risques de coupure entre deux satellites quelconques sont les plus grands.

## Possibilité d'évolution future

Elle est limitée pour l'étoile. L'accroissement du nombre de périphériques accroît la charge du commutateur central et il arrivera un moment où celui-ci ne pourra plus suivre.

L'arborescence permet des développements plus grands. Il est toujours possible d'ajouter une branche ou de créer un niveau supplémentaire dans la hiérarchie.

Il est simple d'agrandir une boucle en particulier si celle-ci ne possède pas d'unité de contrôle. Mais cela ne peut se faire qu'au détriment du délai de transmission.

## Coût - complexité

La boucle est en général plus simple à mettre en oeuvre et à gérer. Le logiciel de l'arborescence est plus complexe. Un traitement doit se faire au niveau de chaque noeud. En outre, le matériel utilisé dans ce dernier cas est plus important.
## Généralité

- **Changement d'ordinateurs** : c'est une caractéristique à priori du réseau. Les interfaces microprocesseurs que nous avons défini, peuvent s'adapter à n'importe quelle structure et peuvent donc permettre d'utiliser des ordinateurs différents,

- **Changement d'applications** : la structure dépend pour beaucoup de l'application et du nombre de périphériques mis en jeu. Si le nombre d'éléments est relativement petit, une étoile ou une boucle s'impose. Dans le cas contraire, il faudra choisir l'arborescence ou la boucle en fonction des paramètres précédemment définis (débit, délai de transmission, etc.).

Si les traitements sont hiérarchisés, une arborescence s'impose, une centralisation des résultats peut conduire à une étoile. La boucle est très intéressante pour des systèmes ou les périphériques sont nombreux et banalisés, et où les délais de transmission ne sont pas contrai-gnants (lecture de badges, etc.).

# V - LE LANGAGE DE COMMANDE

## 1. Introduction

Un point important dans un système informatique structuré sous la forme d'un réseau d'ordinateurs hétérogènes, est la notion de langage commun de dialogue. Que doit-être ce langage, et que doit-il faire ?

On peut considérer qu'un langage informatique possède trois fonctions qui sont :

- la communication,

- la commande et le contrôle,

- le calcul.
Ces trois fonctions doivent être nécessairement satisfaites par le réseau. Les composant actifs de celui-ci étant les mini et micro-processeurs, il reste à définir qui fait quoi.

Afin d'appuyer nos reflexions sur du concret, considérons le langage NODAL défini sur le réseau du CERN. Ce langage est unique sur le réseau, et rempli les trois fonctions énoncées ci-dessus.

L'équipe du CERN a voulu que ce langage soit suffisamment explicite pour qu'il puisse être utilisé par des non informaticiens. Elle l'a voulu de type interprétatif de façon à ce qu'une commande puisse être immédiatement exécutée et interprétée.

Le réseau est homogène. L'interpréteur est donc le même pour tout le réseau, à quelques variantes près, certains satellites ne possédant pas toutes les fonctions (traitement de chaînes de caractères en particulier).

Ce langage unique impose que tous les programmes soient écrits en NODAL. Les programmes déjà existants, écrits en FORTRAN sont donc inutilisables.

L'interpréteur prend beaucoup de place en mémoire vive des NORD 10 (environ 6 K) transposé dans un microprocesseur de 8 bits tel que le 8080, il en occuperait vraisemblablement plus du double : différence dans la puissance des instructions, etc.)

L'interpréteur du langage NODAL est lent, chaque appel nécessite un décodage de la chaîne appelante et une recherche de type lexico-graphique dans des tables. Pour un microprocesseur non spécialisé dans le traitement des chaînes de caractères, le rapport de temps moyen peut atteindre 25 avec un mini-ordinateur tel que le Mitra 15.

Un certain nombre de sous-programmes ne sont pas résidents en mémoire centrale du satellite. Ils se trouvent sur des fichiers externes (disques, tambours, etc.), ceux-ci sont directement accessibles par le
mini-ordinateur. Dans notre architecture, l'exécution par le microprocesseur de ces sous-programmes, nécessite un dialogue mini-micro. Cela ne peut qu'alourdir et retarder le système.

Ces quelques remarques tendent à prouver que l'implantation d'un interpréteur d'un langage complet sur un microprocesseur interface n'est pas facilement réalisable et pénaliserait fortement les performances en temps du système.

Il faut également remarquer que presque tous les miniprocesseurs existants sur le marché possèdent un software de base assez complet. (compilateurs des langages FORTRAN, BASIC, etc.). Se priver de tels outils logiciels est assurément un handicap.

Dans la structure de réseau, la position du microprocesseur que nous avons choisi, à savoir interface de communication, correspond à une exécution de la fonction de communication par le microprocesseur. Il apparaît intéressant de faire exécuter les fonctions de commande et de contrôle inter-processus également par les microprocesseurs. Ceci, parce que ces fonctions sont en nombre réduit et peuvent donc être interprétables au niveau des microprocesseurs interfaces.

L'idée est donc de définir un ensemble de primitives de communication et de contrôle, communes à tout le réseau. Chacune de ces primitives est interprétée au niveau des satellites, par le microprocesseur, en termes du langage système propre au satellite. Ces primitives sont insérées dans le code des programmes sous forme de macro-instructions.

Ainsi, n'importe quel langage de programmation est autorisé. La seule modification, consiste à leur ajouter ces macro-instructions de communication et de contrôle.
## 2. Définition des primitives de communication et de contrôle

### a. Primitives de ce type existant dans NODAL.

Les primitives de communication et de contrôle existant dans le langage NODAL sont au nombre de quatre :

- EXECUTE. (X), Y, A, B,

**Sémantique** : exécuter sur le processeur X la séquence d'instructions notée Y, à l'aide des paramètres A, B.

- IMEX (5) , <COMMANDE>

**Sémantique** : exécuter immédiatement sur le processeur 5 la commande donnée en paramètre (cette commande appartient au langage NODAL)

- REMIT A, B

**Sémantique** : retourne le résultat du programme déclenché par une instruction EXECUTE, au programme ayant demander l'EXECUTE.

- WAIT (X)

**Sémantique** : attendre des informations du processeur X.

### Exemple de programme NODAL

Soit le programme suivant écrit en NODAL :

1.1 SET A = 1

1.2 SET B = 2

1.3 EXECUTE (5), 2, A, B / * exécuter dans l'ordinateur 5, la séquence 2 avec les paramètres A et B * /
1.4 WAIT (5) A

/* attendre la réponse : valeur de
A */

2.1 SET A = CAMAC (B)

/* lire la valeur de A sur le
périphérique B */

2.2 REMIT A

/* retourner la valeur de A */

2.3 END

## Remarques

Il nous apparaît nécessaire de distinguer plus nettement les fonctions de communication et de contrôle, et de les structurer mieux. Ceci est fait dans les primitives décrites ci-dessous qui constituent le langage de communication et de contrôle.

## b. les primitives de communication

Les primitives de communication sont au nombre de deux. Ce sont les primitives ENVOYER et RECEVOIR.

## Syntaxe

ENVOYER [<nom-porte>, <ad-message>, <nom-retour>, <L/R (fonction)>]

RECEVOIR [<nom-porte>, <ad>]</

La sémantique de ces deux primitives a été présentée dans le chapitre II.

L'implantation de ces deux primitives sur une structure réseau, avec un microprocesseur en frontal, est décrite dans le chap. III.
## Remarque

La communication inter-processus doit se faire, au niveau même du code des processus, de façon standard, c'est-à-dire, indépendamment du fait que les processus soient implantés sur la même machine ou non. Or, ceci impose d'autres modifications des langages de programmation existants. Ainsi, en FORTRAN, les ordres d'entrée/sortie BUFFER IN et BUFFER OUT doivent être remplacés par les instructions RECEVOIR et ENVOYER. L'utilisation des ordres BUFFER IN et BUFFER OUT, suppose en effet un adressage local. Notre désir est de pouvoir faire une ENTREE/SORTIE n'importe où dans le réseau, donc il est nécessaire d'éliminer ces cas particuliers, si on veut un périphérique quelconque du réseau.

## c. les primitives de contrôle

Les primitives de contrôle permettent de modifier la structure du réseau de processus (réseau logiciel) au niveau des noeuds (créer, tuer), et de modifier leur état (exécuter, suspendre, réveiller).

### - la primitive CREER

syntaxe : CREER ( <nom-porte>, <entier>, <paramètre> *)

La primitive CREER est exécutée par un processus $P_1$ et permet d'introduire un (ou plusieurs) noeud(s) dans le réseau dynamique du processus.

<nom-porte> : nom de la porte appartenant au processus $P_1$ à laquelle sera rattaché le nouveau noeud crée.

<entier> : cet entier indique le nombre d'occurences du noeud que l'on veut générer

<paramètre>* : liste des paramètres nécessaires à la phase de création.
Un paramètre spécifie, quand cela est nécessaire, l'implantation physique du processus. Il indique sur quel processeur sera exécuté ce processus.

L'exécution de la primitive CREER provoque un appel vers le système d'exploitation et celui-ci se charge de générer le(s) noeud(s) concerné(s). Ceci peut aller jusqu'à la phase d'exécution si les paramètres appropriés sont fournis.

- la primitive TUER

Syntaxe : TUER ( <nom-porte>)

l'exécution de cette primitive par un processus ($P_1$) permet de supprimer un (ou des) noeud(s) du réseau dynamique de processus.

Si le noeud à supprimer est un processus et s'il est en cours d'exécution, il est alors interrompu et supprimé.

Dans le cas où des messages sont en attente dans ces liens d'entrée, ces messages sont détruits. A tout message auquel est associée une réponse ( Ceci est indiquée dans le corps du message), un message retour signalant la destruction du noeud est renvoyé.

Si le noeud à supprimer est un fichier, cette suppression est équivalente à une "déallocation" dynamique.

- la primitive EXECUTER

Cette primitive provoque l'exécution du processus sur lequel elle s'applique. Pour cela, ce processus a dû être auparavant crée et ses paramètres d'expansion et d'initialisation fournis.
syntaxe : EXECUTER ( <nom-porte> , <paramètre> )

L'exécution de cette primitive EXECUTER résulte en l'activation
et l'exécution du processus connecté par un lien à la porte
nom-porte. Les paramètres d'activation, d'initialisation et
d'expansion sont donnés par cette primitive sous forme d'un
message rangé dans la file d'attente associée au lien. L'arrivée
de ce message n'interrompt pas le processus récepteur s'il est
en cours d'exécution. Un paramètre indique si l'on veut une
exécution immédiate ou non.

- la primitive SUSPENDRE

Syntaxe : SUSPENDRE [ <nom-porte> , <paramètre> ]

Un processus P₁ peut suspendre l'exécution d'un autre processus
P₂ en exécutant la primitive SUSPENDRE sur ce processus. Si le
processus P₂ est en cours d'exécution, il est alors suspendu
immédiatement. Sinon, le message est mémorisé. Dans le cas où
le processus est déjà dans l'état suspendu, cette nouvelle
suspension est ignorée.

Un message de type SUSPENDRE ne peut malheureusement pas être
utilisé pour briser une étreinte fatale. Ceci est montré sur
l'exemple suivant

<figure><img src="image_38.png" /></figure>
Dans la figure ci-dessus, le processus $P_1$ est en attente d'un message du processus $P_2$ et le processus $P_2$ est en attente d'un message du processus $P_1$.

L'envoi d'un message SUSPENDRE sur l'un quelconque des liens $L_3$, $L_4$, $L_5$ ou $L_6$ est sans effet.

Le fait d'émettre un message de type SUSPENDRE dans un lien de type *simple* n'est pas ambigue car il n'y a qu'un seul receveur. Mais, dans le cas d'un lien de type DIFFUSION, tous les processus en sortie de ce lien sont suspendus.

- la primitive REVEILLER

Syntaxe : REVEILLER nom-porte

La fonction REVEILLER est utilisée pour redémarrer un processus interrompu par une fonction SUSPENDRE.

L'exécution du processus recommence à l'adresse où la suspension a eu lieu, et l'état du processus est restauré. La fonction REVEILLER n'a pas de paramètre.

Si le processus récepteur est déjà actif, cette primitive devient sans effet. Dans l'éventualité d'une action simultanée, des primitives REVEILLER et SUSPENDRE, la primitive SUSPENDRE est prioritaire.

La fonction REVEILLER est différente de la fonction EXECUTER. En effet, cette dernière fonction n'agit qu'en certains points d'un processus et celui-ci ne la prend en compte que lorsqu'il le désire. La fonction EXECUTE implique également une réinitialisation du processus, ce qui n'est pas le cas pour la fonction REVEILLER.
### 3. Exemples d'utilisation des instructions introduites précédemment

a. L'équivalent de l'instruction `EXECUTE` de NODAL est la fonction `CREER`. Ainsi, à l'aide des paramètres suivants, l'on obtient :

`CREER` ($P_1$, 1, { $ad_1$`, $p_1$`, exécuter} )

On rattache au lien connecté à la porte $P_1$, un processus dont le code se trouve à l'adresse $ad_1$. On précise l'emplacement physique $P_1$ (nom du processeur), et l'on demande son exécution.

b. La fonction IMEX de NODAL est un cas particulier de la fonction `EXECUTER` introduite précédemment, en effet :

`EXECUTER` $P_1$, <A, B, C, I>

Cette primitive demande l'exécution du processus se trouvant connecté à la porte $P_1$, à l'aide des paramètres A, B, C. Le paramètre I indique une exécution immédiate. Il s'agit donc de produire une interruption et de spécifier le processus à exécuter à la suite de cette interruption.

## VI CONCLUSIONS ET PERSPECTIVES

A chaque satellite, nous avons associé un microprocesseur, et ceci sans faire d'hypothèses sur la nature du périphérique connecté ou sur la structure du réseau. Une telle configuration devrait permettre de concevoir des réseaux hétérogènes. On peut se poser la question pourquoi vouloir relier entre eux des ordinateurs de types différents ? Dans beaucoup d'applications de type conduite de processus industriels, ce besoin ne s'est pas fait ressentir. Les mini-ordinateurs utilisés sont en général suffisamment puissants pour accomplir les fonctions demandées.
Les microprocesseurs, pour être vraiment efficaces, devront être très spécialisés. L'un dans le traitement des chaînes de caractères, l'autre dans le traitement du signal... Ils ne seront pas forcément compatibles et il faudra les connecter à un réseau de façon à ce que toutes les fonctions soient accessibles par les utilisateurs.

L'étude que nous avons faite montre que ceci est possible en utilisant un interface banalisé qui peut être un microprocesseur particulier bien adapté à cette fonction. Un langage commun à tous les satellites doit être défini. Ce dernier dépend pour beaucoup des besoins des utilisateurs, mais il comportera nécessairement des primitives de communication qui pourront être interprétées par le processeur interface. La cohérence des données traversant le réseau sera ainsi assurée.

========