Inv- 02529 RR201

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

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

# FORTSIM :
UN SYSTÈME D'AIDE
A L'ÉCRITURE DE SIMULATEURS
EN FORTRAN

Marc BADEL - Michel VÉRAN

Rapport de Recherche N° 201

Décembre 1976

<figure><img src="image_2.png" /></figure>
FORTSIM : UN SYSTÈME D'AIDE A L'ÉCRITURE DE SIMULATEURS EN FORTRAN

M. Badel

IRIA-LABORIA

M. Véran

Centre Scientifique CII de Grenoble

Résumé :

Le système FORTSIM, réalisé par M. Véran du Centre Scientifique CII de Grenoble, est une bibliothèque de sous-programmes disponibles en FORTRAN sur les ordinateurs CII 10070 et IRIS 80. Ces sous-programmes facilitent l'écriture de programmes de simulation à évènements discrets. Leur emploi a été voulu aussi proche que possible de celui des primitives du langage SIMULA 67. Après quelques généralités sur la simulation à évènements discrets, nous décrivons successivement l'emploi du système FORTSIM, puis la façon dont il a été réalisé.

Abstract :

FORTSIM has been realized by M. Veran from the CII Scientific Center of Grenoble. It is a FORTRAN subprograms library available on CII Computers CII 10070 and CII IRIS 80. These subprograms are written in an ALGOL like assembly language, but they can be called from FORTRAN programs. Their purpose is to make easier to write discrete event simulation programs and their use is very close to the corresponding primitives in SIMULA 67. After some generalities on discrete event simulation, we describe successively how to use FORTSIM and the way it has been conceived.
# FORTSIM : un système d'aide à l'écriture de simulateurs en FORTRAN

M. BADEL

IRIA/LABORIA

M. VERAN

Centre Scientifique CII de Grenoble

## I - INTRODUCTION

FORTSIM est une bibliothèque de sous-programmes FORTRAN écrits en langage machine pour les ordinateurs CII 10070 et Iris 80. FORTSIM a pour but de faciliter l'écriture en FORTRAN de programmes de simulation par évènements et son emploi a été voulu aussi proche que possible de celui du langage SIMULA 67 [1, 2, 3]. Après de brefs rappels sur la simulation par évènements discrets, nous décrirons succinctement le langage SIMULA 67, de façon à faire ressortir les concepts repris par FORTSIM. Nous exposerons alors le système FORTSIM lui-même. Nous développerons d'abord l'emploi de ses primitives et nous donnerons un exemple comparatif de programmation en SIMULA 67 et en FORTSIM. Nous décrirons en dernier lieu la façon dont le système FORTSIM a été réalisé.

## II - RAPPELS SUR LA SIMULATION A EVENEMENTS DISCRETS

Le lecteur qui recherchera sur ce sujet des informations générales plus détaillées se reporter à [4] que nous reproduisons en partie pour ce très bref rappel.

### II.1 - Généralités

La simulation est la reproduction du fonctionnement au cours du temps du système physique étudié, représenté par un modèle. L'évolution du système dans le temps peut s'effectuer d'une manière continue ou discrète,
seul cas qui nous intéressera ici.

Par définition, un système à évolution discrète dans le temps est tel qu'entre deux instants $T_0$ et $T_1$, il existe une suite finie ou dénombrable d'instants $t_1, t_2, ..., t_i, ..., t_n$ tels qu'entre deux instants $t_{i-1}$ et $t_i$, le système n'évolue pas. Les instants $t_i$ de changement d'état du système seront appelés les occurences d'évènements et les changements d'états seront les évènements. Les évènements arrivant d'une façon discrète dans le temps, il est possible de les ordonner suivant un échéancier et de les simuler séquen-tiellement l'un après l'autre.

## II.2 - Langages utilisés pour la simulation

Tous les langages de programmation généraux sont utilisables pour la simulation comme nous le verrons avec le système FORTSIM lui-même. Différents langages ont cependant été développés et contiennent un certain nombre des outils nécessaires. Parmi les langages adaptés à la simulation par évènements discrets, citons GPSS [5, 6] diffusé par IBM, SIMSCRIPT [7, 8, 9] et SIMULA 67 [1, 2, 3]. Pour la simulation de phénomènes continus, nous pouvons citer DYNAMO [10].

## III - PRINCIPAUX CONCEPTS DU LANGAGE SIMULA 67

### III.1 - Généralités

Le langage SIMULA 67, dont les quelques primitives essentielles ont été transcrites dans FORTSIM, est une extension de l'ALGOL 60 comportant les notions de classes et d'objets. Le langage SIMULA 67 est ainsi un langage algorithmique général très puissant. Une classe d'objets particuliers, celle des processus, permet la simulation par évènements. Ceux-ci sont gérés par un échéancier. La programmation d'un évènement est effectuée au niveau de l'objet processus et est facilitée par la notion de coroutine dans le langage.

### III.2 - Objets et classes

Un objet SIMULA 67 est un ensemble de variables (paramètres numériques, tables, références sur d'autres objets), de procédures et de code
exécutable. Le format d'un type d'objet est défini par une déclaration de classe avec la notion de sous-classe suivant un arbre hiérarchique pour des types d'objets de plus en plus particuliers.

Un nouvel objet est créé par un ordre NEW. Cet ordre provoque en outre l'exécution du code exécutable de l'objet s'il y a lieu. Le code exécutable d'un objet est une coroutine, c'est-à-dire que son exécution peut à tout moment être abandonnée, puis reprise en séquence. Ces propriétés sont utilisées par les procédures de gestion des processus.

### III.3 - Outils de simulation fournis par le système SIMULA 67

Les outils de simulation fournis par SIMULA 67 se présentent sous la forme de procédures et de classe fournies par le système. Ils comprennent :

- Les primitives de synchronisation des évènements

- Des primitives de manipulation de listes,

#### III.3.1 - Primitives de synchronisation

En SIMULA 67, les évènements portent sur des objets particuliers : les processus. Le code d'un processus est le code de l'objet associé (voir ci-dessus). Les procédures de synchronisation sont :

- ACTIVATE AT ou BEFORE ou AFTER ou DELAY pour activer un processus à une heure déterminée ou avant ou après un autre processus, où au bout d'un intervalle de temps déterminé.

- HOLD pour suspendre le processus actif pendant un intervalle de temps donné.

- PASSIVATE pour rendre passif le processus actif.

- REACTIVATE pour reprogrammer un processus dans l'échéancier.

- CANCEL pour rendre passif un processus quelconque.

- TERMINATE pour terminer un processus, notamment pour le détruire.

Les sous-programmes HOLD et PASSIVATE, qui interrompent le processus actif, rendent la main au programme de gestion des évènements. Lorsque le pro-
cessus est de nouveau actif, son code est repris en séquence derrière l'ordre
HOLD ou PASSIVATE. C'est donc dans la gestion des processus que la notion de
coroutine du langage SIMULA 67 prend tout son sens. D'autres fonctions permettent
de lire l'état d'un processus à un instant donné. Ce sont notamment IDLE pour
l'état suspendu ou non et EVTIME pour l'heure dans l'échéancier.

### III.3.2 - Manipulation de listes

Le langage SIMULA 67 offre des possibilités de gestion de listes
circulaires à double chaînage. Ceci est utile en particulier dans la simulation
de files d'attente. Les opérations sur les listes portent sur les types d'objets
tête de liste et lien. Ces opérations sont l'insertion ou le retrait d'un
objet d'une liste, l'accès au suivant ou au prédécesseur de l'objet pour le
parcours avant ou arrière de la liste, la détermination du nombre d'objets
de la liste.

## IV - LE SYSTEME FORTSIM

### IV.1 - Spécifications

Le système FORTSIM a été conçu comme une bibliothèque de sous-
programmes disponibles pour un programme FORTRAN, dont l'emploi a été voulu
aussi proche que possible de celui des primitives du langage SIMULA 67. Les
notions de SIMULA 67 transposées dans FORTSIM sont :

- La notion d'objet avec création dans une zone dynamique de mémoire.

- La notion de processus muni des propriétés de coroutine [ 11 ]
comme en SIMULA 67.

- La manipulation des listes circulaires à double chaînage.

Il a été adjoint à ces possibilités des manipulations de sémaphores.

### IV.2 - Nction d'objet en FORTSIM

En SIMULA 67, un type d'objet est défini par une classe. Les objets
se manipulent grâce à des variables de type référence. En FORTSIM, la notion de
référence est remplacée par celle d'indice. Les variables d'un objet doivent
donc être des éléments de tableaux.

Le format d'un objet est décrit en FORTSIM par une suite de
variables de tableaux consécutives. Une déclaration de classe se fait par
appel au sous-programme classe qui retourne un pointeur sur la classe nouvel-
lement crée.

Exemple :

1) En SIMULA 67

CLASS POINT

BEGIN

REAL X : REAL Y :

END

2) Equivalent FORTSIM

DIMENSION X(1), Y(1)

INTEGER CLASS

IPOINT = CLASS (X, Y)

La fonction CLASS reçoit en paramètres les variables extrêmes du
type d'objet décrit, d'où la nécessité d'utiliser des variables consécutives en
mémoire. Tout comme en SIMULA 67, la création d'un nouvel objet se fait par
un ordre NEW. Dans l'exemple précédent, on pourra continuer par :

1) En SIMULA 67

REF(POINT)IP

IP : NEW(POINT)

2) En FORTSIM

IP = NEW(IPOINT)

En SIMULA 67, les variables d'un objet se manipulent par notation
pointée à partir d'une référence sur cet objet. La notion de référence étant
remplacée par celle d'indice, l'initialisation des coordonnées du point de
l'exemple précédent se feront par :

1) En SIMULA 67

IP.X := A

IP.Y := B ;

2) En FORTSIM

X(IP) = A

Y(IP) = B
L'effet de l'appel à la fonction NEW est le suivant :

- Recherche en table de la classe référencée et allocation dynamique d'une
zone de mémoire égale à la taille de l'objet.

- Retour d'un indice pointant l'objet. Cet indice est égal à la différence des adresses en mémoire entre le début de l'objet nouvellement crée et la première variable déclarée de l'objet. Cet indice contient en outre en partie gauche une référence à la classe.

On voit donc que les variables d'un objet FORTSIM peuvent être
atteintes par un simple indiçage.

IV.3 - Transposition de la notion de processus

En SIMULA 67, les objets sur lesquels portent les évènements sont
les processus, définis par la classe système PROCESS. Un processus doit être
décrit par une sous-classe de PROCESS. En FORTSIM, la notion de sous-classe
n'existe pas. Les sous-programme PROCESS permet cependant de déclarer que la
dernière classe définie doit générer des processus et d'indiquer l'adresse de
début du code exécutable du processus.

En SIMULA 67, plusieurs objets processus identiques peuvent partager
le même code exécutable, ce qui pose, tout comme dans un système, des problèmes
de réentrance. La gestion de cette réentrance est automatique en SIMULA, un
objet étant considéré comme un bloc et ayant ses données propres. En FORTSIM,
cette fonction est remplie par la déclaration d'une variable dite de contexte.
Cette déclaration se fait par l'appel du sous-programme CONTEXT lors de la
première activation du processus. Chaque fois que le processus reprendra la
main, la variable de contexte sera rechargée avec le pointeur de l'objet associé.

Exemple de création d'un processus :

1) En SIMULA 67
PROCESS CLASS PROC
BEGIN
    Données et code du processus
END ;
FIN DE LA CLASSE PROC
IPROC : - NEW PROC ;
2) En FORTSIM :

INTEGER CLASS

EXTERNAL CODPROC

IPROC = CLASS (---,---)

CALL PROCESS (CODPROC)

C LA SUBROUTINE CODPROC REPRESENTE LE CODE DU

C PROCESSUS

SUBROUTINE CODPROC

INTEGER CONT

CALL CONTEXT (CONT)

C DANS LA SUITE, CONT SERVIRA A INDICER LES

C VARIABLES DU PROCESSUS LORSQU'IL EST ACTIF.

suite du code du processus.

Les sous-programmes de manipulation des processus sont approxima-
tivement les mêmes qu'en SIMULA 67. Ce sont :

- CALL ACTIVATE (pointeur processus) équivalent à REACTIVATE processus AFTER CURRENT en SIMULA, pour activer ou reprogrammer le processus à l'heure courante et après le processus courant.

- CALL PASSIVATE, équivalent au PASSIVATE du SIMULA, rend passif le processus courant.

- CALL HOLD (période), équivalent au HOLD (période) du SIMULA, suspend le processus courant pendant le temps spécifié.

- CALL REACTIV (processus, heure) équivalent à REACTIVATE processus AT heure en SIMULA, permet de reprogrammer le processus à l'heure indiquée quel que soit son état : actif, suspendu ou passif.

De même qu'en SIMULA, les fonctions EVTIME et IDLE permettent d'obtenir l'heure d'activation et l'état oisif ou non d'un processus. De même qu'en SIMULA, les processus FORTSIM sont des coroutines. En cas de réveil ou de nouvelle activation le processus reprend la main derrière l'appel au sous-programme HOLD ou PASSIVATE.
Les principales différences avec SIMULA sont :

- Gestion du temps comme une variable entière

- Adjonction d'opérations sur les sémaphores.

Un sémaphore FORTSIM se crée par un appel à la fonction NEWSEM.
Les sémaphores crées sont du type P et V (sous-programmes REQUEST et RELEASE).
Un processus peut se mettre en attente sur un sémaphore par un ordre CALL
REQUEST (sémaphore). Il peut être relancé par un ordre CALL RELEAse sur le
même sémaphore ou par un code CALL ACTIVATE (processus). La fonction SEMVALUE
permet d'obtenir la valeur courante d'un sémaphore.

### IV.4 - Manipulation des listes en FORTSIM

De même qu'en SIMULA, les listes manipulées en FORTSIM sont des
listes circulaires à double chaînage. En SIMULA 67, les objets mis dans une
liste appartiennent à des sous-classes de la classe LINK. En FORTSIM, le
sous-programme LINK permet de déclarer que la dernière classe définie doit
générer des objets de type lien et indique au système l'adresse du lien avant
(le lien arrière est pris automatiquement dans le mot suivant).

Exemple de déclaration :

1) En SIMULA 67

LINK CLASS OBJET

2) En FORTSIM

DIMENSION A(1), B(1),---, LIENAV(1), LIENAR(1),---
---Z(1)
INTEGER OBJET, CLASS
OBJET = CLASS(A, Z)
CALL LINK(LIENAV)

La classe OBJET génèrera des objets de type lien dont les attributs
liens seront LIENAV et LIENAR. Les différences avec SIMULA 67 sont :
- Une même liste ne peut contenir que des objets d'une même classe.

- Il n'existe pas d'objet spécial tête de liste. Ce rôle est tenu par un objet particulier de la classe considérée dont on n'utilise que les attributs liens.

Un lien sur un objet est égal à l'indice permettant d'atteindre cet objet. Par définition, un objet libre chaîne sur lui-même. Les ordres de manipulation des listes sont CALL { INBEFORE } (objet 1, objet 2) pour insérer l'objet 1 avant ou après l'objet 2 dans la même liste, CALL OUT (objet) pour la libération d'un objet. Les fonctions NEXT et PREVIOUS permettent d'atteindre le suivant ou le précédent d'un objet donné (ce qui est également possible par utilisation directe des attributs liens). Enfin la fonction CARDINAL permet le comptage des éléments d'une liste.

## IV.5 - Tirage de lois aléatoires

Les programmes de simulation utilisent fréquemment des tirages aléatoires suivant des lois de probabilité données. Nous avons inclus dans le système FORTSIM un générateur aléatoire uniforme entre 0 et 1 et des fonctions de tirage pour les lois les plus usuelles. Le générateur aléatoire utilisé, congruentiel à l'origine, a été remplacé par un générateur fondé sur la théorie des registres à décalages [12, 13, 14, 15]. Ce type de générateurs se caractérisent par de très bons résultats aux différents tests, et par des périodes particulièrement grandes ($2^{98}$ pour le générateur utilisé). Afin d'améliorer la qualité de la suite de nombres aléatoires utilisés, ce générateur a été entremélé [16] au moyen d'un générateur congruentiel et d'une table à 128 entrées. Les fonctions de tirage suivant des lois aléatoires sont construits à partir du générateur précédent. Elles permettent le tirage booléen avec une probabilité donnée, les tirages des lois exponentielle négative de moyenne donnée, gaussienne de moyenne et d'écart-type donnés, d'Erlang de moyenne et d'ordre n donnés, hyperexponentielle avec les trois paramètres de la loi donnés.

## IV.6 - Autres primitives de FORTSIM

Le sous-programme SIMUL, à appeler avant toute autre opération, initialise toutes les tables du système, en particulier les tables de classes
et le noyau de synchronisation des évènements. Le sous-programme ENDSIMUL met fin à la simulation et édite l'heure d'arrêt.

# V - EXEMPLE DE PROGRAMMATION COMPAREE EN SIMULA 67 ET EN FORTSIM

## V.1 - Présentation du modèle simulé

Le système proposé (figure 1) est un système fermé à deux serveurs et à deux files d'attente. Des clients en nombre fixe N circulent indéfiniment d'une file à l'autre. Chaque serveur sert à tour de rôle le premier client de sa file d'attente suivant le principe premier arrivé-premier servi. Les temps de service sont aléatoires suivant des lois exponentielles de moyennes respectives $XM1$ et $XM2$. A la fin d'un service, le client servi est renvoyé dans la file d'attente de l'autre serveur. Nous supposerons qu'à l'instant initial 0, les N clients se trouvent dans la file d'attente du serveur 1. Nous simulerons le système proposé pendant un temps TMAX. Nous mesurerons pour chaque serveur son taux d'utilisation TAUXUT (rapport de son temps d'activité au temps total simulé). Pour chaque client, nous effectuerons le comptage du nombre de passages par chaque serveur dans le tableau NBSERV.

## V.2 - Description du programme

La description suivante est valable à la fois pour le programme SIMULA 67 et le programme FORTSIM. Les serveurs du modèle seront décrits comme des processus. Les clients seront des objets type lien et les files d'attente des serveurs seront représentées par des listes. Les variables du programme seront :

### 1) Variables communes

- TABSERV table des références sur les serveurs,

- $XM1$ et $XM2$ destinés à initialiser les temps de service moyens de chaque serveur,

- N nombre de clients dans le système,

- TMAX temps total simulé,

- IU variable entière servant à initialiser le générateur aléatoire.
Pour le programme FORTSIM, le système gérant le temps comme une variable entière, nous définirons également la variable ECHLTIME, facteur d'échelle de temps.

## 2) <u>Variables propres à chaque serveur</u>

- NUMERO numéro du serveur,

- XM temps de service moyen du serveur,

- TAUXUT variable servant à cumuler les temps d'activité du serveur et permettant de calculer les taux d'utilisation,

- DEBSERV heure de début du service courant, utilisée pour calculer les temps d'activité,

- FILE référence sur la file d'attente du serveur.

## 3) <u>Variables propres à un client</u>

- NBSERV tableau de dimension 2 utilisé pour compter le nombre de services à chaque serveur,

- En FORTSIM, nous définirons de plus la table LIEN, de dimension 2, pour les chaînages avant et arrière des clients.

Le fonctionnement d'un serveur sera le suivant :

- Le serveur examine si sa file d'attente est vide. Si oui, il s'endort. Sinon, il traite un début de service : l'heure de début de service est remise à jour avec l'heure courante ; un temps de service est tiré au hasard ; le serveur se suspend durant ce temps de service.

- A la fin du temps de service, le serveur remet à jour TAUXUT, total des temps d'utilisation, fait le comptage des nombres de service pour le client servi, et envoie celui-ci à la file d'attente de l'autre serveur. Puis il retourne au début de son code.

Le programme principal comportera dans l'ordre :

- Initialisation du modèle, ainsi que des classes utilisées dans le programme FORTSIM,
- Suspension pendant le temps TMAX simulé,

- Mise à jour des mesures de taux d'utilisation en fin de programme.

## V.3 - Programmation en SIMULA 67

BEGIN

SIMULATION BEGIN

$ DESCRIPTION DE LA CLASSE CLIENT $

LINK CLASS CLIENT;

BEGIN

INTEGER ARRAY NBSERV(1:2);

END;

$ DESCRIPTION DE LA CLASSE SERVEUR $

PROCESS CLASS SERVEUR;

BEGIN

$ DECLARATION DES DONNEES DU SERVEUR $

INTEGER NUMERO;

REAL XM,DEBSERV,TAUXUT;

REF(HEAD)FILE;

INTEGER I;

$ INDICE AUXILIAIRE $

$ CODE DU SERVEUR $

DEBUTSERVICE:IF FILE EMPTY THEN

PASSIVATE;

$ CAS OU LA FILE EST VIDE $

DEBSERV:=TIME;

HOLD(NEGEXP(1./XM; IU));

$ ON VIENT DE SE SUSPENDRE POUR UN TEMPS DE SERVICE ALÉATOIRE EXPONENTIEL $

$ MISE A JOUR DE TAUXUT $

TAUXUT:=TAUXUT+TIME-DEBSERV;

$ OPERATIONS SUR LE CLIENT $

INSPECT FILE.FIRST QUA CLIENT DO BEGIN

NBSERV(NUMERO):=NBSERV(NUMERO)+1;

I:=3-NUMERO;

$ I:=NUMERO DE L'AUTRE SERVEUR $

INTO(TABSERV(I(I).FILE);

$ LE CLIENT A ETE ENVOYE A L'AUTRE SERVEUR . $

$ SI CELUI-CI EST ENDORMI ,ON LE REVEILLE $
IF TABSERV(I).IDLE THEN ACTIVATE TABSERV(I) AFTER CURRENT;
GOTO DEBUTSERVICE;
END;
END;
$ PROGRAMME PRINCIPAL $
$ DONNEES $
INTEGER N, IU;
REAL TMAX, XM1, XM2;
REF(SERVEUR) ARRAY TABSERV(1:2);
$ VARIABLES AUXILIAIRES $
INTEGER I, J;
REF(CLIEN) RCLI;
$ INITIALISATIONS $
IU:=53;
N:=5; XM1:=0.5; XM2:=1. ; TMAX:=10000. ;
$ CREATION DES SERVEURS $
FOR J:=1 STEP 1 UNTIL 2 DO BEGIN
  TABSERV(J):-NEW SERVEUR;
  INSPECT TABSERV(J) DO BEGIN
    NUMERO:=J;
    TAUXUT:=0;
    FILE:-NEW HEAD;
    END;
    END;
  TABSERV(1).XM:=XM1;
  TABSERV(2).XM:=XM2;
  $ CREATION DE N CLIENTS DANS LA FILE D'ATTENTE DU SERVEUR 1 $
FOR I:=1 STEP 1 UNTIL N DO BEGIN
  RCLI:-NEW CLIENT;
  INSPECT RCLI DO BEGIN
    FOR J:=1 STEP 1 UNTIL 2 DO NBSERV(J):=0;
    INTO(TABSERV(1).FILE;
    END;
    END;
  $ LANCEMENT DE LA SIMULATION $
FOR I:=1 STEP 1 UNTIL 2 DO ACTIVATE TABSERV(I) AFTER CURRENT;
HOLD(TMAX);

$ FIN DE SIMULATION ET RELEVE DES TAUX D'UTILISATION $

FOR I:=1 STEP 1 UNTIL 2 DO BEGIN
INSPECT TABSERV(I) DO BEGIN

IF NOT IDLE THEN TAUXUT:=TAUXUT+TIME-DEBSERV;

TAUXUT:=TAUXUT/TMAX;

OUTTEXT('TAUX UTILISATION SERVEUR NO');

OUTINT(1,5);

OUTTEXT('=');

OUTFIX(TAUXUT,4,10);

OUTIMAGE;

END;

END;

END;

END

#

## V.4 - Programmation en FORTSIM

Les variables propres à un client et à un serveur seront décrites dans chaque sous-programme par des communs. Le code d'un serveur sera décrit par la subroutine SERVCODE. Dans celle-ci, une variable de contexte IS devra être déclarée pour pointer le serveur courant. La notion de pointeur d'objet sera remplacée par celle d'indice. D'autre part, l'heure courante est une variable système entière à prendre dans le commun étiqueté SYSDATA.

SUBROUTINE SERVCODE

CODE D'UN SERVEUR

LONNEES DU CLIENT ET DU SERVEUR

COMMON/CLIENT/NBSERV(2),LIEN(2)

INTEGER FILE

COMMON/SERVEUR/NUMERO(1),XM(1),DEBSERV(1),TAUXUT(1),FILE(1)

DECLARATION DU TEMPS

INTEGER TIME

COMMON/SYSDATA/TIME
C VARIABLES COMUNES DU MODELE

INTEGER TABSERV

COMMON/MODELE/TABSERV(2),ECHLTIME,IU

REAL NEGEXP

LOGICAL IDLE

C DECLARATION DU CONTEXTE

CALL CONTEXT(IS)

C CODE DU SERVEUR . DEBUT DE SERVICE

100 I=FILE(IS)

IF(LIEN(I).EQ.I)CALL PASSIVATE

C UNE FILE VIDE CHAINE SUR ELLE MEME

C ET LA FILE EST ICI UN FAUX CLIENT

DEBSERV(IS)=TIME/ECHLTIME

IDORT=NEGEXP(1./XM(IS),IU)*ECHLTIME

CALL HOLD(IDORT)

C FIN DE SERVICE

TAUXUT(IS)=TAUXUT(IS)+TIME/ECHLTIME-DEBSERV(IS)

C OPERATIONS SUR LE CLIENT

I=FILE(IS)

I=LIEN(I)

J=NUMERO(IS)+I-1

NBSERV(J)=NBSERV(J)+1

C J EST L'INDICE DANS LA TABLE NBSERV PROPRE AU CLIENT POINTE PAR 1 .

C IL FAUT POUR L'OBTENIR SOMMER DES INDICES

K=3-NUMERO(IS)

C ON CHERCHE ENCORE LA FILE DE L'AUTRE SERVEUR

K=TABSERV(K)

I=FILE(K)

CALL INBEFORE(I,L)

C POUR METTRE EN QUEUE D'UNE LISTE CIRCULAIRE

C ON INSERE DEVANT LA TETE DE LISTE

IF(IDLE(K))CALL ACTIVATE(K)

GO TO 100

END
C PROGRAMME PRINCIPAL

C RAPPEL DES DONNEES ET COMMUNS

COMMON/CLIENT/NBSERV(2),LIEN(2)

INTEGER FILE

COMMON/SERVEUR/NUMERO(1),XM(1), DEBSERV(1),TAUXUT(1),FILE(1)

INTEGER TIME

COMMON/SYSDATA/TIME

INTEGER TABSERV

COMMON/MODELE/TABSERV(2),ECHLTIME,IU

INTEGER CLASS

LOGICAL IDLE

EXTERNAL SERVCODE

C INITIALIZATIONS

IU=53

XM1=0.5

XM2=1

TMAX=10000.

N=5

ECHLTIME=1000.

C CREATION DES CLASSES

CALL SIMUL.

KLIENT=CLASS(NBSERV,LIEN(2))

CALL LINK(LIEN)

KSERV=CLASS(NUMERO,FILE)

CALL PROCESS(SERVCODE)

C CREATION DES SERVEURS

DO 10 I=1,2

J=NEW(KSERV)

TABSERV(I)=J

NUMERO(J)=I

TAUXUT(J)=0

10 FILE(J)=NEW(KLIENT)

C LA FILE EST EN FORTSIM UN CLIENT PARTICULIER

J=TABSERV(1)

XM(J)=XM1
J=TABSERV(2)

XM(J)=XM2

C CREATION DE N CLIENTS DANS LA FILE DU SERVEUR 1

DO 20 I=1,N

J=NEW(KLIENT)

DO 30 K=1,2

L=J+K-1

30 NBSERV(L)=0

M=TABSERV(1)

M=FILE(M)

20 CALL INBEFORE(J,M)

C LANCEMENT DE LA SIMULATION

DO 40 I=1,2

40 CALL ACTIVATE(TABSERV(I))

ITMAX=TMAX*ECHLTIME

CALL HOLD(ITMAX)

C FIN DE LA SIMULATION . RELEVE DES TAUX D'UTILISATION

DO 50 I=1,2

J=TABSERV(I)

IF(IDLE(J))GO TO 60

TAUXUT(J)=TAUXUT(J)+TIME/ECHLTIME-DEBSERV(J)

60 TAUXUT(J)=TAUXUT(J)/TMAX

WRITE(6,1)I,TAUXUT(J)

1 FORMAT('TAUX UTILISATION SERVEUR NO',I5,' = ',F10.4)

50 CONTINUE

CALL ENDSIMUL

END

VI - PRINCIPES DE REALISATION DU SYSTEME FORTSIM

VI.1 - Classes et objets

VI.1.1 - Classes

Lors d'un appel au sous-programme CLASS, une nouvelle classe est
mise dans les tables du système. Les données relatives à une classe sont:
- L'adresse du premier attribut des objets à créer (donné comme premier argument d'appel à la fonction CLASS)

- La longueur en mots des objets à créer

- Une tête de chaîne des objets détruits

- L'adresse de l'attribut lien éventuel (ou zéro)

- L'adresse du premier attribut processus des objets crées s'il s'agit de processus.

- L'adresse de début du code du processus associé (ou zéro)

Une création de classe entraîne l'allocation d'une nouvelle zone de description en mémoire dynamique. Le pointeur sur cette zone est mis en table.

Les tables de classes (256 classes possibles) sont initialisées par l'appel au sous-programme SIMUL (ainsi que la partie gestion des processus).

## VI.1.2 - Objets

Les objets FORTSIM sont crées (ainsi que les descripteurs de classes) dans une zone de mémoire dynamique. Un nouvel objet est créé par un appel à la fonction NEW. Les effets de cet appel sont :

- Allocation en mémoire dynamique d'une zone égale à la taille de l'objet (suivant la taille mentionnée dans la classe référencée).

- Calcul et retour d'un pointeur (indice) sur l'objet. Le pointeur aura pour valeur la différence des adresses en mémoire entre la zone allouée en mémoire dynamique et le premier attribut de l'objet. Le pointeur porte en outre en partie gauche du mot machine la référence à la classe. La zone mémoire occupée par un cojet est récupérée lors d'un ordre DELETE pour la création d'un objet de même nature. A cet effet, une chaîne des objets détruits, pointée par la classe, est constituée.
# VI-2 - Listes et liens

L'adresse de l'attribut lien des objets d'une classe est mise dans le descripteur de classe lors de l'appel au sous-programme LINK. Les liens avant et arrière d'un objet contiennent les pointeurs (au sens d'indices FORTRAN comme précisé plus haut) des objets liés. Par convention, un objet lié chaîne sur lui-même.

# VI.3 - Gestion des processus

## VI.3.1 - Généralités

De même qu'en SIMULA 67, les processus FORTSIM sont ordonnés par heure d'activation suivant un échéancier. Dans la version actuelle, cet échéancier est une liste explorée séquentiellement. Parmi les autres organisations possibles, citons l'utilisation d'arbres balancés ou de listes indexées [17].

## VI.3.2 - Description des processus et de la gestion des évènements

Le système ordonne les processus suivant un échéancier organisé en liste linéaire. Les variables du système sont :

- L'heure courante, incrémentée dès qu'un processus rend la main (à la suite d'un HOLD, PASSIVATE ou REQUEST (sémaphore)) et que le contrôle est donné à un nouveau processus.

- Un pointeur sur le processus courant.

- Une tête de chaîne des processus suspendus et en attente d'activation.

- Pour des raisons d'efficacité, la tête d'une seconde chaîne doublant la précédente pour les processus à activer immédiatement après le processus courant (à la suite d'un ordre ACTIVATE ou RELEASE (sémaphore)).

Les variables d'un processus sont placées en tête de l'objet processus et en avant de l'adresse pointée par l'indice d'objet retourné à l'utilisateur. Elles comportent :

- Le lien de chaîne du processus vers le processus courant dans l'échéancier (ou dans la file associée à un sémaphore).
- L'heure d'activation du processus.

- Une variable d'état, permettant de connaître l'état, actif, suspendu, passif ou bloqué sur sémaphore, du processus. Cette variable d'état pointe sur la tête de chaîne à laquelle le processus appartient (tête de chaîne des processus suspendus, ou sémaphore suivant le cas). Par convention, un processus passif pointe sur lui-même.

- L'adresse de la variable de contexte associée au processus. Cette variable sera chargée dès que le processus reprendra le contrôle. Cette adresse est initialisée par l'appel au sous-programme CONTEXT.

- La valeur de la variable de contexte du processus. Cette valeur est celle du pointeur (indice) de l'objet associé.

- L'adresse programme courante où le processus doit reprendre la main lorsqu'il sera de nouveau actif. Cette adresse, remise à jour lors d'un appel aux sous-programmes HOLD, PASSIVATE et REQUEST (sémaphore) est rendue égale au registre de retour du sous-programme appelé.

Le coeur du système de gestion des évènements est constitué par le sous-programme DISPATCH. Ce sous-programme reçoit la main à la fin de chaque sous-programme suspendant le processus courant (HOLD, PASSIVATE, REQUEST (sémaphore), REACTIV sur le processus courant). Il est responsable de l'avancement du temps et de l'activation des processus.

Lors du démarrage de la simulation, la gestion des évènements est initialisée (après la table des classes) par le sous-programme SIMUL. Celui-ci crée un descripteur de processus pour le programme principal, considéré alors comme processus courant (les processus de l'utilisateur pourront ensuite prendre la main après un appel à HOLD ou PASSIVATE dans le programme principal). Un processus de garde est également mis en place : son heure d'activation est la plus haute possible et son rôle est la mise en erreur du programme dès qu' aucun processus n'est plus en attente.
## VII - CONCLUSIONS

Le système FORTSIM est un système permettant d'écrire en FORTRAN des programmes de simulation très proches de programmes en SIMULA 67. Une partie du système FORTSIM (gestion des objets et des classes) se prêterait également à l'allocation dynamique de mémoire en FORTRAN.

Pour la mise en oeuvre de FORTSIM, une connaissance préliminaire de SIMULA 67 nous semble souhaitable. Les avantages propres à FORTSIM par rapport à SIMULA 67 nous semblent être :

- La possibilité de réaliser un système FORTSIM sur un machine ou dans un centre où SIMULA 67 est indisponible (à notre connaissance, SIMULA 67 est disponible sur les machines IBM série 360, UNIVAC 1107/1107, CDC 6600 et CII 10070 et Iris 30).

- La rapidité d'exécution. En particulier, nos propres résultats font apparaître un facteur de 15 entre un programme FORTSIM et son équivalent en SIMULA 67 sur CII Iris 30, mais ce résultat est dû en partie à ce que l'exécution du SIMULA 67 CII est interprétative. Des renseignements sommaires recueillis laisseraient espérer un facteur de gain de 2 à 3 par rapport à un SIMULA entièrement compilé.

Les inconvénients de FORTSIM sur SIMULA 67 nous semblent être en revanche la mise au point plus délicate des programmes de simulation. La protection contre les erreurs, notamment de pointeurs, est beaucoup plus délicate. Signalons aussi pour mémoire toutes les autres erreurs, telles qu'erreurs de types de variables, dues aux principes de FORTRAN, contrairement à un langage de type ALGOL.

Nous rappellerons pour terminer les nombreuses difficultés de mise au point des programmes de simulation, lorsque les phénomènes simulés sont aléatoires. Quels que soient les principes choisis, le programmeur à tout intérêt, à notre avis, à utiliser un système de synchronisation des évènements existant, ou à en construire un indépendamment de son problème d'application.
Les facilités de modification interne du système FORTSIM permettent
son utilisation expérimentale, par exemple pour des projets de recherche ou
d'évaluation d'algorithmes de synchronisation (ce qui serait difficile avec
SIMULA 67).
REFERENCES

[1] DAHL O.J., NYGAARD K. - "SIMULA - an Algol based simulation language" - CACM - Vol. 9, no 9 - September 1966.

[2] DAHL O.J., MYRHAUG B., NYGAARD K. - "SIMULA 67 Common Base Language" - Publication nº 5-2 - Norwegian Computing Center - Oslo 3 - NORWAY - May 1968.

[3] BIRTWISTLE G. - "Notes on the SIMULA Language" - Publication nº 5_3 - Norwegian Computing Center - Oslo 3 - NORWAY - April 1969.

[4] LEROUDDIER J., PARENT M. - "Discrete Event Simulation Modelling of Computer System for Performance Evaluation" - Rapport de recherche n° 177 - IRIA/LABORIA - Juin 1976.

[5] HERSCOVITCH H., SCHNEIDER T.H. - "GPSS III - An Expended General Purpose Simulator" - IBM System Journal - Vol. 4, no 3 - 1955.

[6] IBM Corp. - "General Purpose Simulation System 360 - Users Manual" - IBM Corp. - H20-0326-0 - 1967.

[7] DIMSDALE B., MARKOWITZ H.M. - "A Description of the SIMSCRIPT language" - IBM Syst. Journal 3, 1 - 1964.

[8] MARKOWITZ H.M., HANSNER B., KARR H. - "SIMSCRIPT" - Prentice Hall - Englewood Cliffs - N.J. - 1964.

[9] MARKOWITZ H.M. - "Simulating with SIMSCRIPT" - Management Science - Vol. 12, n° 10 - June 1966.

[10] FORRESTER J.W. - "Industrial Dynamics" - M.I.T. Press Student's Edition - 1963.

[11] KNUTH D.D. - "The Art of Computer Programming" - Vol. 11.

[12] TAUSWORTHE R.C. - "Random Numbers Generated by Linear Reurrence Modulo Two" - Math. Comp. 19 - 1965.

[13] LEWIS P.A.W., GOCDMAN A.S., MILLER J.M. - "A Pseudo-Random Generator for the System 360" - IBM System Journal n° 2 - 1969.

[14] LEWIS T.G., PAINE W.H. - "Generalized Feedback Shift Register Pseudo-Random Number Algorithm" - Journal of ACM, Vol. 20, no 3 - July 1973.
[15] STONE H.S. - "Discrete Mathematical Structures and their Applications" - Science Research Associates - Palo Alto - 1973.

[16] Mac LAREN M.D., MARSAGLIA G. - "Uniform Random Number Generators" - Journal of ACM - Vol. 12, n° 1 - January 1965.

[17] VAUCHER J.G., DUVAL P. - "A Comparison of Simulation Event List Algorithms" - CACM - Vol. 18, n° 4 - April 1975.

[18] VERAN M. - "FORTSIM : Manuel d'utilisation" - Centre Scientifique CII de Grenoble 1975.