Écriture de systèmes d'exploitation portables pour mini-ordinateurs

(1)

Thesis

Reference

Écriture de systèmes d'exploitation portables pour mini-ordinateurs

THALMANN, Daniel

Abstract

L'écriture de logiciel en langage d'assemblage pour un mini-ordinateur est généralement un travail fastidieux. Les problèmes d'adressage ou de sauvetage des registres font rapidement perdre de vue les algorithmes de base et, par conséquent, la conception générale. Un système d'exploitation, écrit en langage d'assemblage, est rarement bien documenté; les modifications sont pénibles à implanter et sont souvent la source d'erreurs : on assiste ainsi à une dégradation du système. Enfin, les systèmes ne sont pas portables d'un type de mini-ordinateur à un autre. Nous avons voulu montrer qu'il est possible d'utiliser la puissance d'une grosse machine et un langage de haut niveau adéquat pour produire un système d'exploitation pour plus d'un mini-ordinateur. SPIP est en lui-même une démonstration. Les programmeurs peuvent l'utiliser pour écrire tout un système d'exploitation ou un simple module ou pour changer une requête au moniteur, dans un langage lisible et clair qui assure une grande sécurité. Le générateur produit un code optimisé qui libère les programmeurs des problèmes d'adressage et [...]

THALMANN, Daniel. Écriture de systèmes d'exploitation portables pour mini-ordinateurs. Thèse de doctorat : Univ. Genève, 1977, no. Sc. 1807

DOI : 10.13097/archive-ouverte/unige:155420

Available at:

http://archive-ouverte.unige.ch/unige:155420

Disclaimer: layout of this document may differ from the published version.

1 / 1

(2)

D'INFORMATIQUE PROFESSEUR B. LEYRAT

ECRITURE D·E SYSTEMES

D'EXPLOITATION PORTABLES POUR MINI-ORDINATEURS

THÈSE

PRÉSENTÉE A LA FACULTÉ DES SCIENCES DE L'UNIVERSITÉ DE GENÈVE

POUR OBTENIR LE GRADE DE DOCTEUR ÈS SCIENCES MENTION INFORMATIQUE

PAR Daniel THALMANN

de Genève

THÈSE N° 1807

Genève Imprimerie des Bergues

1977

(3)

(4)

D'INFORMATIQUE PROFESSEUR B. LEYRAT

ECRITURE DE SYSTEMES

D'EXPLOITATION PORTABLES POUR MINI-ORDINATEURS

THÈSE

PRÉSENTÉE A LA FACULTÉ DES SCIENCES DE L'UNIVERSITÉ DE GENÈVE

POUR OBTENIR LE GRADE DE DOCTEUR ÈS SCIENCES MENTION INFORMATIQUE

PAR Daniel THALMANN

de Genève

THÈSE N° 1807

Genève Imprimerie des Bergues

1977

(5)

ordinaire (Centre universitaire d'informatique) et P. ZANELLA, docteur ès sciences (CERN), autorise l'impression de la présente thèse, sans exprimer d'opinion sur les propositions qui y sont énoncées.

GENEVE, le 14 mars 1977

Le Doyen : Jean lfüLLER

Thèse 1807

(6)

(7)

Writing software in assembly code for a minicomputer' is very fastidious work. Addressing and register allocation problems tend to hide basic algorithms and general conception.

Operating systems written in assembly code are rarely well documented, modifications are hard to implement and of ten turn out as a source of errors : thus improvements may result in an actual degradation. Furthermore, systems are not portable from one minicomputer to another.

We wanted to demonstrate that it is possible to use the power of a big computer and an appropriate high level language to generate an operating system for more than one minicomputer.

SPIP is in itself such a dernonstration. Programmera can use it to either write an entire operating system or a single module, to change a monitor request in a readable language, and to ensure much more reliability. The generator will produce an optimized code which will free the progrannner from addressing and register allocation problems, hopefully providing increased efficiency.

SPIP is written in Pascal, in the present implementation on our Univac-1108 it can produce operating systems for Nova and PDP-11 minicomputers.

A single-user operating system,

s.o.s.

has been completely written.

It allows the processing of files (create, read, write, delete, edit), the compiling in Pascal-Sand the execution by interpre- tation.

(8)

Je tiens à remercier très chaleureusement le professeur Bernard Levrat, directeur de cette thèse, dont j'ai apprécié tout particulièrement le dynamisme, les idées et l'ouverture d'esprit.

Mes remerciements vont également au professeur Jürgen Harms pour la lecture très consciencieuse du manuscrit et pour les discussions enrichissantes que j'ai eues avec lui.

Je remercie le docteur Paolo Zanella, directeur de la division Données et Documents du C.E.R.N., qui a très aimablement accepté de faire partie du jury de cette thèse.

Je tiens à exprimer toute ma gratitude à Madame Liliane Noël pour avoir si soigneusement dactylographié et mis en page ce texte. Sa bonne humeur constante et l'efficacité de son travail ont contribué à la rédaction de cette thèse dans une atmosphère très agréable.

Je remercie mon ami Alain Jacquesson pour sa disponibilité et ses conseils très utiles concernant les références bibliographiques.

Ma gratitude va également à Pierre-Alain Marti qui a réalisé avec beaucoup de soin les dessins de cette thèse et à Mademoiselle Martine Vermeire qui a participé à la dactylographie de la bibliographie.

Enfin, je tiens à exprimer ma travail qui m'ont aidé, tout gentillesse et leur amitié.

reconnaissance à

au long de ma mes copains de thèse, par leur

(9)

(10)

L'écriture de logiciel en langage d'assemblage pour un mini-ordinateur est généralement un travail fastidieux. Les problèmes d'adressage ou de sauvetage des registres font rapidement perdre de vue les algorithmes de base et, par conséquent, la conception générale.

Un système d'exploitation, écrit en langage d'assemblage, est rarement bien documenté; les modifications sont pénibles à implanter et sont souvent la source d'erreurs : on assiste ainsi à une dégradation du système. Enfin, les systèmes ne sont pas portables d'un type de mini-ordinateur à un autre.

Nous avons voulu montrer qu'il est possible d'utiliser la puissance d'une grosse machine et un langage de haut niveau adéquat pour produire un système d'exploitation pour plus d'un mini-ordinateur.

SPIP est en lui-même une démonstration. Les progranuneurs peuvent l'utiliser pour écrire tout un système d'exploitation ou un simple module ou pour changer une requête au moniteur, dans un langage lisible et clair qui assure une grande sécurité. Le générateur produit un code optimisé qui libère les programmeurs des problèmes d'adressage et d'allocation des registres et accroît, nous l'espérons, leur efficacité.

SPIP est écrit en Pascal et dans l'implantation actuelle sur notre Univac-1108, il peut produire des systèmes d'exploitation pour des mini-ordinateurs Nova et PDP-11.

Un système d'exploitation pour un seul utilisateur, S.O.S. a été complètement écrit. Il permet le traitement de fichiers (création, lecture, écriture, destruction, édition), la compilation de programmes écrits en Pascal-S et leur exécution par interprétation.

(11)

(12)

Page Introduction

Chapitre 1 : Langages d'assemblage et langages évolués

de programmation de systèmes 1

1.1 Les langages d'assemblage 1

1.1.1 La structure d'un langage d'assemblage 1

~.1.2 Les défauts des langages d'assemblage 1 1.2 Les langages évolués de programmation de systèmes 3

1.2.1 Qu'est-ce qu'un langage de programmation

de systèmes ? 3

1.2.2 La programmation de systèmes et les

grands langages 3

1.2.3 Les langages spécifiques 4

1.2.4 PL360 et ses dérivés 5

1.2.5 Les langages de multiprogrammation 6 1.3 Analyse de coût et de performances 7 1. 4 Notre choix : SPIP et la machine À 8

Références 10

Chapitre 2 : La description de SPIP 14

2.1 Les principes de SPIP 14

2.1.1 Les différentes parties de SPIP 14

2. 2 La machine À 14

2.2.1 L'unité centrale 14

2.2.2 Les entrées/sorties 16

2.3 Le choix du langage d'implantation de SPIP 17 2.3.1 Les différents langages et leur compilateur 17 2.3.2 Les facilités intrinsèques des langages

et nos besoins 17

2.3.3 La sécurité 18

2.3.4 La performance 18

2.3.5 La portabilité 18

2.4 Le langage Pascal 19

2.4.1 Qualités et défauts de Pascal 19

2.5 Historique de SPIP 19

Références 21

Chapitre 3 : Le langage SPIP 24

3.1 Les champs des instructions 24

3.1.1 Les champs-mot 24

3.1.2 Les champs-byte 25

3.1.3 Les autres champs 25

3.2 Le jeu d'instructions 27

3.2.1 Le langage orienté machine 27

3.2.2 Les 2 niveaux de SPIP : mode privilégié

et protection 28

3.2.3 Les instructions simples 29

3.2.4 Les instructions spécifiques aux structures 31

3.2.5 Le traitement des fichiers 32

3.2.6 Les modules 33

3.2.7 Les instructions de contrôle 34 3.2.8 Le traitement des interruptions 39

(13)

3.2.11 Les macros et les synonymes 41

Références 42

Chapitre 4 : Le compilateur SPIP 44

4.1 La construction des compilateurs 44

4.1.1 Notion de langage 44

4.1.2 La structure d'un compilateur 46

4.2 La structure du compilateur SPIP 48

4.2.1 L'analyse lexicale 4R

4.2.2 L'analyse syntaxique 50

4.2.3 Le traitement des erreurs 55

4.2.4 Les macros 59

4.2.5 La table des symboles 63

Références 66

Chapitre 5 : Le code À et les actions sémantiques 69 5.1 Portabilité des compilateurs et codes intermédiaires 69

5.1.l La portabilité 69

5.1.2 Code indépendant de la machine 70

5.1.3 Quelques cas concrets 70

5.2 Le code À 71

'l. ?.. 1. DP.scription du code À 71

5.2.2 Exemples 73

5.3 La lecture du code 73

5.3.1 La lecture et la structure des

informations construites 73

5.3.2 Exemple : l'adressage par page 74

5.4 Les actions sémantiques 75

5.4.1 L'aiguillage et les procédures sémantiques 76 5.4.2 Le prétraitement, le traitement et

le post-traitement. 77

Références 80

Chapitre 6 : La génération de code et l'optimisation ^~2

6.1 Quel mini-ordinateur ? 82

6.2 Le mini-ordinateur DATA GENERAL NOVA 82

6.2.2 Le jeu d'instructions 83

6.3 Le mini-ordinateur D.E.C. PDP-11 84

6.3.2 Le jeu d'instructions 84

6.4 La réalisation des objets À sur les machines réelles 85

6.4.1 Les registres simples 85

6.4.2 Les structures 86

6.4.3 Les modules 88

6.5 Les problèmes d'adressages 88

6.5.1 L'adressage dans la Nova 88

6.5.2 L'adressage dans la PDP-11 88

6.5.3 Le traitement automatique de l'adressage 89

6.6 L'allocation des registres 90

6.6.1 Le problème de l'allocation 90

6.6.2 L'algorithme <l'allocation 91

6.7 Le code produit pour les instructions simples 94

6.7.1 L'instruction swap-bytes 94

6.7.2 Les autres instructions 95

6.8 Les instructions structurées 96

6.8.1 Un exemple : l'instruction if 97

(14)

6.10.2 Impresssion d'une chaîne de caractères 6.11 Le traitement des structures

6.12 Les modules et la récursivité

6.12.1 Les langages RALBOL, CEPPAN et MARIUS 6.12.2 La récursivité sur la Nova

6.12.3 La récursivité sur la PDP-11 6.13 Le traitement des interruptions

6.13.1 Les interruptions sur la Nova 6.13.2 Les interruptions sur la PDP-11 Références

Chapitre 7 : L'édition de liens 7.1 Chargeurs et éditeurs de liens

7.2 Chargeurs et éditeurs de liens dans SPIP 7.3 La forme du code relogeable

7.4 La structure de l'éditeur de liens SPIP$LINK 7.5 Le cas du résident cle

s.o.s.

7.6 La table de chargement Références

Chapitre 8 : Les simulateurs 8.1 Les interpréteurs

8.1.1 La structure générale d'un interpréteur 8.2 Le simulateur de la Nova

8.2.1 Description interne du simulateur 8.2.2 Exécution d'une instruction

8.2.3 Un exemple : instructions entre resistres 8.3

Le

simulateur de la PDP-11

8.3.1 Description interne du simulateur 8.3.2 Exécution d'une instruction

8.3.3 Un exemple : instructions à 2 opérandes 8.4 Le langage de contrôle des simulateurs

8.4.1 Les commandes du langage de contrôle 8.4.2 Le système d'exploitation du simulateur Références

102 103 104 104 107 105 108 108 110 112

114 114 114 116 118 116 119 120

121 121 121 122 122 123 123 127 127 127 127 130 131 132 135

Chapitre 9 : Le système S.O.S. 136

9.1 Pourquoi

s.o.s.

^? ¹³⁶

9.2 Les fichiers 136

9.2.1 Le type des fichiers 136

9.2.2 Les propriétés des fichiers 136

9.3 Le langage de contrôle 137

9.3.1 La liste des commandes 137

9.4 Un exemple de session 139

9.5 Le moniteur S.O.S. 140

9.5.1 Les requêtes 140

9.5.2 Le traitement des commandes 142

9.6 Le traitement des fichiers 146

9.6.1 La structure d'un fichier 146

9.6.2 Ecriture/lecture sur fichiers-disque 147

9.6.3 La table des fichiers 148

9.6.4 La création, la destruction et la

modification de fichiers 150

9.7 Un exemple complet de programme utilitaire : PATCH 152

Références 154

(15)

10.l Le langage Pascal-S 10.2 Le compilateur Pascal-S 10.3 L'interpréteur Pascal-S

10.3.1 L'ordinateur hypothétique 10.3.2 Exemples d'instructions

10.3.3 La structure de l'interpréteur 10.4 L'éditeur de texte

10.4.1 L'éditeur de

s.o.s.

Références

Chapitre 11 : Réalisations et perspectives 11.l Les caractéristiques du système réalisé

11.1.1 Les caractéristiques de SPIP 11.1.2 Les caractéristiques de

s.o.s.

11.1.3 Le travail réalisé 11.2 L'avenir de SPIP

11.2.1 L'extension à d'autres mini-ordinateurs 11.2.2 L'extension à de plus grosses machines 11.2.3 L'extension à des micro-ordinateurs 11.2.4 L'extension aux processus parallèles 11.2.5 L'extension à des procédures de

communications entre machines Références

Annexe A SPIP et O.S.1100

155 155 157 158 158 159 161 161 164 165 165 165 166 167 167 168 169 lfi9 170 171 172

Annexe B Préparation d'un disque

s.o.s.

et bootstrap sur Nova.

Annexe C Listage des macros et des identificateurs définis par NAME et SEQUENCE.

(16)

1.1 Les langages d'assemblage Définition

Un langage ct'assemblage ou assembleur est un langage symbolique très proche du langage-machine.

1.1.1 La structure d'un langage d'assemblage

Décrire un langage d'assemblage revient pratiquement à décrire un langage-machine, donc un langage spécifique à une machine. Nous pouvons néanmoins décrire des concepts généraux applicables à la plupart des ordinateurs actuels. Un langage-machine se compose d'instructions permettant le transfert entre les registres, les registres et la mémoire, les registres et les périphériques. La mémoire est accessible par différents adressages : direct, indirect, relatif, indexé. Hormis l'addition et la soustraction, les langages-machine ont toujours des instructions de décalage, de complémentation et d'opérations logiques (et, ou). Des instructions de test et de saut permettent la construction de boucles aussi sophistiquées que possible. Des facilités de définition et d'appels de sous-programmes existent généralement dans chaque langage- machine.

Dans un langage d'assemblage, le maniement des adresses se fait de manière symbolique.

Un langage d'assemblage permet l'utilisation du "hardware" d'une machine dans les limites de ses possibilités. Il est possible de déplacer dynamiquement des instructions, d'en modifier certaines en cours d'exécution.

1.1.2 Les défauts des langages d'assemblage

Un prograt!lI!le écrit dans un langage d'assemblage est rarement clair;

les al~orithmes employés sont masqués par la pauvreté du langage.

Seul 1 arrangement des instructions permet de reconnaître une structure de contrôle.

p.e. ^~queRl=R2 faire S se traduit par

E/. CHP Rl,R2 SAUT El

code de S SAUT E2 El

si Rl=R/. alors S sinon T se traduit par

El E2

CHP Rl,R2 SAUT El

code de S SAUT E2

code de T

(17)

Les problèmes d'adressage (accès limité) et de gestion rendent les programmes d'autant moins clairs et multiplier les risques d'erreurs.

des rP.gis tres contribuent à La modification des programmes est fastidieuse, la simple correction d'une erreur peut entraîner l'introduction de nouvelles; on a ainsi installé le phénomène d'une permanence d'un taux d'erreurs dans les prograrmnes. Ce taux constant d'erreurs est particulièrement manifeste au niveau des systèmes d'exploitation des très grosses machines (1).

Il est inconcevable qu'un programmeur ait la liberté d'ajouter une simple instruction de stockage dans un programme et d'exécuter alors des instructions qu'il n'a jamais prévues !

P.e. assembleur NOVA

ADD 1,2 STA 2, .+3 SUBC 3,3

+ on introduit l'instruction STA 3,L JMP .+2

0 L'instruction STA 2,.+3 stockera donc le contenu du registre AC2 sur l'instruction JMP .+2,

LDA 2,K on exécutera alors une instruction susceptible de modifier une toute autre partie du progratllJTl.e.

Nous aimerions encore signaler que la programmation en 'langage d'assemblage a entraîné la conception de compilateurs et de systèmes d'exploitation par des équipes très nombreuses, -pendant de très longues périodes. Les dernières personnes qui ont souvent participé à de gigantesques projets n'ont même pas connu les premières. Cette ri!partition du travail a contribué très largement à la diffusion de systèmes trop compliqués dont aucun être humain n'est capable d'avoir une vue d'ensemble.

Il suffit de comparer le listage d'un compilateur Fortran, écrit en assembleur, et celui du compilateur Pascal, écrit en Pascal, pour comprendre que les langages d'assemblage vont de plus en plus faire place à des langages de beaucoup plus haut niveau.

(18)

1.2 Les langages évolués de programmation de systèmes

1.2.1 Qu'est-ce qu'un langage de programmation de système ?

Nous définirons un langage de programmation de systèmes, comme un langage permettant l'écriture de systèmes d'exploitation, de prograrmnes en temps réel, de compilateurs et d'interpréteurs.

Quelles sont les caractéristiques d'un tel langage ?

Il doit permettre de manier des entités plus petites qu'un mot-machine (manipulation de bits, de bytes).

Il doit permettre d'accéder directement ou indirectement à la structure interne de la machine (adresses de la mémoire, registres).

- Il doit permettre "l'accès détaillé" aux divers périphériques (status d'équipement, secteurs-disque, etc.).

- Il doit pouvoir traiter soit les interruptions, soit la gestion de processus parallèles.

Un langage de programmation de systèmes n'a par contre pas besoin de certaines facilités telles que : les arithmétiques complexes ou même réelles. Un langage évolué de programmation de systèmes doit en plus renfermer de bonnes structures de données et de contrôle.

1.2.2 La programmation de systèmes et les grands langages

Les langages généraux ont été utilisés et étendus pour concP.voir et implanter des systèmes d'exploitation (2,3).

Fortran

Le centre de recherches électroniques de la NASA implanta un système en temps partagé sur une Honeywell 516, écrit en Fortran; la syntaxe du langage ne fut pas modifiée, les entrées-sorties furent traitées en langage d'assemblage (2).

Algol fiO

Burroughs développa un compilateur Algol étendu, qui permettait la manipulation de bits, la définition de macros, le traitement de listes, le traitement des interruptions et la compilation séparée de procédures. Le compilateur ESPOL (Executive System Problem Oriented Language) pour le modèle B5700 fut écrit en Algol étendu, ESPOL est lui-même un langage très proche d'Algol.

Burroughs implanta également un langage pour permettre la communication de données entre ordinateurs et stations "remote", le DCALGOL (Data Communications Algol) (4).

(19)

PL/l

Multics (5,6,7,8,9,10), le système développé au Massachussets Institute of Technology a été écrit dans un PL/l étendu (macros), 250 modules sur 1500 furent cependant écrits en langage-machine. En particulier, le traitement des interruptions fut codé en langage-machine.

PL/l a donné naissance à XPL, un langage développé à Stanford sur IBH 360 et qui permit d'écrire le générateur de compilateurs XPL (11) et à Malus, le langage qui fut employé pour implanter le système HCTS sur un prototype de la CDC STAR (12,13).

Algol 68

Le langage est utilisé pour la formalisation des concepts fondamentaux d'un système d'exploitation (9).

Pascal

Le langage Pascal (14) est certainement l'un des meilleurs pennettant l'écriture de compilateurs pour de petits langages (15,16,17) et pour des langages plus conséquents dont le principal est Pascal lui-même (18,19,20,21). Il a été également le support de développement de systèmes d'écriture de compilateurs (22). Par contre, il permet difficilement l'écriture de systèmes d'exploitation (1).

Brinch Hansen a tout d'abord étendu le langage Pascal formellement afin de permettre le traitement de tâches parallèles (1), puis il a développé un compilateur pour le Pascal concurrent et implanté le système d'exploitation Solo dans ce langage (23,24,2~,26)

Simula 67

Hoare l'utilise pour exprimer son concept de moniteur qui permet la structuration et la protection d'un systèoe d'exploitation ^(~7,28).

1.2.3 Les langages spécifiques

Un certain nombre de langages ont été développés plus particulièrement, pour l'écriture de systèmes d'exploitation :

Coral 66

C'est un langage particulièrement adapté à des systèmes fonctionnant en temps réel. Une des applications les plus intéressantes est l'implantation du système MOLCAP sur RRE Marconi Myriad par le Royal Radar Establishment (32).

BCPL

Le langage a été développé par M. Richards à l'Université de Cambridge, en 1969. C'est un langage indépendant de la machine basé sur une machine-objet dont chaque cellule-mémoire est caractérisée par son adresse (left value) et contenu (right value) (29,30). Le compilateur BCPL est écrit en BCPL.

(20)

Bliss (Basic Language for Implementation of system Software)

Il a été développé à l'Université de Carnegie-Mellon sur une PDP-10.

Si aucun système d'exploitation complet n'a été écrit en Bliss, un système conversationnel APL et un système semblable à Simula ont été implantés. Bliss est un langage à structure de blocs maniant les adresses des variables et non leurs valeurs (31).

1.2.4 PL360 et ses dérivés

Le langage PL360 a été créé par N. Wirth, à Stanford, il est proche de Pascal par certains aspects (instructions de contrôle), mais il a été conçu pour l'écriture de systèmes pour IBM 360. Il permet en particulier la manipulation des registres et des adresses ainsi que le maniement de bits et de bytes. Les instructions-machine de l'IBM 360 sont disponibles dans le langage PL360 (33,34). PL360 a donné naissance à de nombreux langages du même type, spécifiques à une machine donnée.

PLll a été écrit par B. Russell (35,36), pour la série DEC PDP-11;

~existe 2 compilateurs différents : un cross-compilateur écrit en FORTRAN et fonctionnant sur la plupart des systèmes actuels et un compilateur écrit en PLll implanté directement sur PDP-11.

PL516 a été développé par Bell et Wichmann (37) pour l'ordinateur Honeywell DDP-516.

PS440 (38) a été créé à Munich, pour l'ordinateur Telefunken TR-440 tandis qu'en France le LP15 (39) était développé pour les mini-ordinateurs Mitra 15. ^~~

Les objectifs de tous ces langages sont toujours les mêmes

"combler le vide existant entre des langages de haut niveau tels que FORTRAN ou ALGOL, qui sont faciles à apprendre, mais inefficaces pour la programmation de systèmes, des mini-ordinateurs en particulier et les langages d'assemblage, pénibles à apprendre et facilitant les erreurs, mais efficaces par leur proximité du hardware ¹¹^•

Ces langages ont été créés pour permettre un style de programmation clair, concis et structuré sans pour autant perdre trop d'efficacité.

Si les forces placées dans l'implantation de ces langages sont louables, il n'en reste pas moins que la dépendance de la machine à laquelle ils s'adressent est un obstacle de taille à leur généralisation.

Les efforts de conversion d'un programme de PL516 en PLll sont certes plus envisageables que c:eux d'une conversion d'assembleur DAP-516 en assembleur PAL-11, mais nous pouvons tout de même affirmer que les programmes sont quasiment intransportables d'une machine à l'autre.

(21)

1.2.5 Les langages de multiprogrammation Définition

On appelle multiprogrannnation l'ensemble l'exécution concurrente de processus ou ordinateur.

des techniques permettant d'activités dans un même Les langages d'assemblage ont permis, depuis de nombreuses années, aux programmeurs d'utiliser ces techniques; par exemple, la programraation d'activités parallèles dans un ordinateur tel que l'Univac-1108 s'effectue par des requêtes-système (40).

Les informaticiens ont cherché à formaliser dans des langages de haut niveau les concepts de multiprogrammation. Dijkstra (41) a introduit la notion de sémaphores pour résoudre les problèmes d'accès à des ressources critiques; il a également défini des régions critiques permettant le contrôle de variables connnunes à différents processus. Hoare (27) a utilisé les classes de Simula 67 (42) pour exprimer, dans une direction semblable, les problèmes de protection dans un système multiprogrammé et introduire sous le nom de moniteur un ensemble de données et de procédures associées à une ressource. Brinch Hansen (1,43) a systématisé ces notions et proposé une extension de Pascal lui permettant de formaliser les algorithmes fondamentaux d'un système d'exploitation.

Ce n'est que ces dernières années qu'un effort considérable a permis la définition et l'implantation de véritables langages de multiprogrammation et la réalisation de systèmes écrits dans ces

langages.

Pascal concurrent et Solo

Brinch Hansen a introduit le langage Pascal concurrent (44) et implanté dans ce langage sur PDP-11/45, un système d¹exploitation : le système SOLO (23,24,25,26).

Dans SOLO, une ressource est considérée comme une structure de données à laquelle on ne peut accéder qu'au moyen de 2 opérations : demande d'utilisation et demande de libération. Le compilateur contrôle que seules ces opérations sont effectuées pour une ressource donnée.

Un programme écrit en Pascal concurrent est basé sur 3 types d'informations

- les processus qui permettent des opérations concurrentes sur des structures de données;

- les moniteurs grâce auxquels les problèmes de synchronisation et d¹echanges de données sont résolus;

- les classes par lesquelles on accède à des structures de données liées à un seul processus particulier.

(22)

Modula

Wirth a défini un nouveau langage !10DULA (45), proche de Pascal, permettant les facilités de multiprograrmnation. Ce langage est basé sur la notion de module, collection de constantes, types, variables et procédures semblable aux classes de Simula 67 (42). Les concepts de processus, de signaux et de modules d'interface sont inclus dans le langage et correspondent aux définitions de Hoare et de Brinch Hansen. Un certain nombre de facilités propres à la PDP-11 ont été développées, dont notanunent les drivers.

Wirth (46) donne 3 exemples d'utilisation de Modula :

i) Un programme utilisant concurrennnent, une machine à écrire (entrée et sortie), une imprimante et un lecteur de cartes.

ii) Un programme de transfert entre cassettes magnétiques et disques.

iii) Un programme de représentation graphique sur un écran.

Les dérivés de Pascal

Pascal, dans sa forme standard, est certainement à l'heure actuelle le meilleur langage d'écriture de compilateurs, mais il ne permet pas l'implantation de systèmes d'exploitation (47). On comprend donc les nombreuses propositions ou implantations d'extensions de Pascal ou de langages dérivés.

Nous citerons les implantations qui intéressantes : MARY (48) sur Nord-SM, (50) sur IBM 360, PASCAL-11 (51) sur

!litra 15 et Tl600.

nous paraissent les plus PLATON (49) sur RC3500, SUE PDP-11 et PASCAL-E (52) sur 1.3 Analyse de coût et de performances

Nous allons tenter d'analyser brièvement les avantages et les inconvénients de l'écriture de modules-système en langage d'assemblage et en langage évolué. Notre analyse très imparfaite repose sur des considérations de temps et de coûts.

Considérons les variables suivantes (primées pour les évolués)

tl 'tl

'

t 2 ^tt2

'

t3 't3

' '

t4 't4

'

n3 ,n3

n4

ul u 2

c,c'

:

=

temps de programmations d'un module-système

=

temps de recherche d'erreurs ( "debugging")

=

temps de traduction en langage-machine temps d'exécution du module

nombre de traductions nécessaires

=

nombre d'utilisations du module

=

coût d'un programmeur-système par unité de temps coût d'une unité de temps-machine

coût total

langages

(23)

On a, en considérant un système qu'on ne modifie pas par la suite C

=

(t +t ).u + (nt +nt ).u _l ₂ _l _{3 3 4 4} ₂

et C' = (t1 '+t 2').u1 + (n³t _3' + n₄t ₄').u2 Les relations suivantes sont vraies

1. t1 ' < < t1

.,

t2' << t2

"-.

3. t 3

'

^>t3

4. t ₄

'

^{> t}₄

5. n_{3 '}<< n₃

Le temps d'écriture du module est considérablement raccourci.

la recherche d'erreur est pratiquement supprimée • La compilation en langage évolué est plus lente qu'un assemblage.

Le code produit est 8énéralement moins performant.

Le nombre de traductions nécessaires est beaucoup plus élevé.

Il est évident que l'écriture de programmes en langage évolué est rentable pour 6C

=

C - C' > O. Or 6 C tend à décroître lorsque le nombre d'utilisations du module n₄ augmente. Il est donc important d'estimer, s'il est possible d'atteindre la valeur limite nlfQ, pour laquelle 6C=O; cette valeur limite sera d'autant moins vite atteinte que t _{4 ' -} t ₄ sera petit; on peut même espérer dans un proche avenir que t _{4 '} tendra à devenir inférieur à t_{4 ;} c'est-à-dire que l'optimisation effectuée dans les compilateurs permettra d'obtenir un code plus performant que le code écrit en assembleur.

Enfin, il faut signaler que sont beaucoup plus faciles langage d'assemblage.

les modifications d'un module existant à introduire en langage évolué qu'en Un autre critère n'est pas négligeable

évolué est "auto-documenté".

1. 4 Notre choix : SPIP et la machine À •

un module écrit en langage

Notre but était l'écriture de systèmes d'exploitation pour des mini-ordinateurs. Nous souhaitions avant tout attaquer vigoureu-

sement l'affirmation qu'un système d'exploitation est intimement lié à une machine donnée. Nous désirions développer un outil d'écriture de programmes-système portables d'un mini-ordinateur à l'autre.

Nous avons décidé de développer cet outil en langage Pascal ^(l~) sur une grosse machine, d'abord la CDC Cyber de l'Hôpital de Genève, puis l'Univac 1108 de l'Université de Genève.

Nous étions convaincus de l'apport des gros ordinateurs dans le développement du software des mini-ordinateurs (52). L'ensemble des programmes élaborés dans ce but devait recevoir un nom, nous avons

choisi SPIP qui est 1' acronyme de ^.~ystern!rogramming

.!.n

.!'.,as cal.

(24)

SPIP allait bientôt devenir un langage symbolique permettant l'écriture de systèmes d'exploitation pour une machine abstraite, une sorte de super mini-ordinateur: la machine À.

SPIP peut être considéré connne un "PL360-like"

machine À • Nous avons donc une dépendance de la cette machine peut être concrétisée par différents réels.

langage pour la machine ^{À ,} mais mini-ordinateurs Pour permettre un développement rapide de software pour la machine À, il nous fallait d'une part les avantages d'un langage de très haut niveau : modules récursifs, instructions structurées et puissantes structures de données et, d'autre part, les facilités d'un langage de très bas niveau : accès aux registres et à la mémoire de la machine À, traitement des interruptions, accès aux secteurs-disque.

Enfin, il était nécessaire de produire un code efficace applicable ^à des machines concrètes telles que des mini-ordinateurs Nova ou PDP-11. Un programme-système écrit dans le langage SPIP est dépendant de la machine ^À, il est indépendant des mini-ordinateurs sur lesquels il peut fonctionner.

(25)

Références (1) Brinch Hansen, P.

Operating system principles.

Englewood Cliffs, N.J., Prentice-Hall, 1973.

(2) Sammett, J.E.

A brief survey of languages used in systems implementation.

In : Sigplan notices, 6 (1971) 9, pp. 1-19.

(3) Thalmann, D.

La construction des compilateurs. Vol. 1-2.

Lausanne, Ecole polytechnique fédérale, 1976.

(4) Lyle, D.M.

A hierarchy of high order languages for systems prograttlI!ling.

(5) Corbato, F.J.; Clingen, C.T.; Saltzer, J.H.

Multics : the seven years.

In : AFIPS 1972 spring joint computer conference.

(6) Daley, R.C.; Dennis, J.B.

Virtual memory, processes and sharing in Hultics.

In : Communications of the AC11, 11 (1968) 5, pp. 306-322.

(7) Bensoussan, A.; Clingen, C.T.

The Multics virtual memory : concepts and design.

In : Communications of the ACM, 15 (1972) 5, pp. 308-318.

(8) Crocus.

Systèmes d'exploitation des ordinateurs.

Paris, Dunod, 1975.

(9) Verjus, J.P.

Objets et fonctions primitifs d'un système d'exploitation.

(10) Héritier, C.A.

Time-sharing systems techniques.

IBM course. (Notes de cours.)

(11) McKeeman, W.11.; Horning, J.J.; Wortrnan, D.B.

A compiler generator.

Englewood Cliff, N.J., Prentice-Hall, 1970.

(12') Marcotty, M.; Schutz, H.

The systems programming language, Malus.

In : Software-Practice and Experience 4 (1974), pp. 79-90.

(13) Elshoff J.L.; Beckerrneyer R.; Dill J.; Marcotty M.; Murray J.

Handling asynchronous interrupts in a PL/1-like language.

In : Software-Practice and Experience 4 (1974), pp. 117-124.

(14) Jensen, K.; Wirth, N.

Pascal user rnanual and report.

Berlin, Springer Verlag, 1974. Lecture notes in computer science, No. 18.

(26)

(15) Wirth, N.

Algorithms + data structures

=

programs.

(16) Thalmann, D.; Levrat, B.

Un semestre pour écrire un compilateur : RALBOL.

In : IFIP 2nd world conference, Computers in Education.

Amsterdam, North-Rolland, 1975, pp. 561-566.

(17) Thalmann, D.

Rapport interne sur le langage Marius.

(18) Wirth, N.

The design of a Pascal compiler.

In : Software-Practice and Experience, 1 (1971), pp. 309-333.

(19) Ammann, U.

The method of structured prograrnming applied to the development of a compiler.

In : International cornputing symposium 1973, North-Rolland, 1974, pp. 93-99.

(20) Arnmann,

u.

Die Entwicklung eines Pascal-Compilers nach der }iethode des strukturierten Programmierens. (Diss.)

ZÜrich, Juris. Druck + Verlag, 1975.

(21) Arnmann,

u.

On code generation in a Pascal compiler.

ZÜrich, ETH, April 1976. Berichte des Instituts fÜr Informatik, No. 13.

(22) Lecarme,

o.

Un système d'écriture de compilateurs. Manuel d'utilisation.

Université de Montréal, s.d.

(23) Brinch Hansen, P.

The Solo operating system. A concurrent Pascal program.

Disk scheduling at compile time.

The Solo operating system. Job interface.

The Solo operating system. Processes, monitors and classes.

(27) Hoare, C.A.R.

Monitors : an operating system structuring concept.

(27)

(28) Hoare, C.A.R.

A structural approach to protection. (Draft.)

Computer science dept., Queen's University of Belfast, 1975.

(29) Richards, M.

BCPL : a tool for compiler writing and system prograTllI!ling.

In : AFIPS Spring joint computer conference, 1969, pp. 557-566.

(30) Willers, I.; Mellor,

s.

The BCPL mini-manual.

Geneva, CERN, April 1976.

(31) Wulf, W.A.; Russell, D.B.; Habermann, A.N.

Bliss : a language for systems programrning.

(32) Jackson, K.

Adding real-time features to Coral 66 via the operating system.

In : Computing with real-time systems. Proceedings of the first European seminar AERE Harwell, 1972, pp. 16-21.

(33) Wirth, N.

PL%0, a progr.annning language for the 360 computers.

In : Journal of the ACM, 15 (1968) 1, pp. 37-74.

(34) Wirth, N.

On multiprogrannning, machine coding and computer organization.

In : Communications of the ACH, 12 (1969) 9, pp. 489-498.

(35) Russell, R.D.

PL-11 : A programrning language for the D.E.C. PnP-11 coMputer.

Ed. by T.C. Streater, Geneva, CERN, 1974. CERN 74-24.

(36) Russell, R.D.

Experience in the design, implementation and use of PL-11, a programrning language for the PDP-11.

In : Sigplan notices, 11 (1976) 4, pp. 27-34, (37) Bell, D,A.; Wichmann, B.A.

An Algol-like assembly language for a small computer,

(38) Sapper, G.R.

The programming language as a time-sharing system.

In : Sigplan notices, 6 (1971) 9.

tool for implementing a

(39) Compagnie internationale pour l'informatique, Mitra 15, manuel de présentation software.

CII, 1972.

(40) Sperry Univac.

1100 series executive system, Vol. 1-4.

Sperry Rand Co, U.S.A., 1975. UP-4104.

(41) Dijkstra, E.W,

Cooperating sequential processes.

In : Programming languages. New York, Academic press, 1968.

(28)

(42) Dahl, o.J.

Hierarchical program structures.

In : Structured programming. New York, Academic press, 1972.

A comparison of two synchronizing concepts.

In : Acta Infonnatica, 1 (1972), pp. 190-199.

The programming language concurrent Pascal.

In : IEEE transactions on software engineering, 1 (1975) 2, pp. 199-207.

(45) Wirth, N.

Modula : A language for rnodular rnultiprogramming.

ZÜrich, ETH, March 1976. Berichte des Instituts fÜr Informatik, No. 18.

(46) Wirth, N.

The use of Modula and design and implementation of Modula.

ZÜrich, ETH, June 1976. Berichte des Instituts fÜr Inforrnatik, No. 19.

(47) Conradi, R.

Further critical comments on Pascal, particularly as a systems programming language.

In : Sigplan notices, 1976, pp. 8-25.

(48) Rekdal, K. et al.

MARY, a system for software development on minicomputers.

In : Minicomputer Softvare, North-Rolland, 1976, pp. 15-27.

(49) Staunstrup, J.; Sorensen, S.11.

Platon, a high level language for systems programming.

In : Minicomputer Software, IFIP TC-2 conference.

North-Rolland, 1975, pp.285-299.

(50) Clark, B.L.; Horning, J.J.

The system language for project SUE. Proceedings of a Sigplan symposium on languages for systems implementation.

(51) Stocks, A.I.; Krishnaswamy, J.

On a transportable high level language for minicornputers.

(52) De Lacroix, M.; Pauzin, J.L.

Software transportable écrit en Pascal.

Toulouse, Université Paul Sabatier, 1976. Rapport 120.

(53) Davies, H.E.

The use of large computers for software support of minicomputers.

Geneva, CERN, 1975; DD/75/1.

(29)

Chapitre 2 La description de SPIP

2.1 Les principes de SPIP

SPIP est un compilateur de systèmes d'exploitation implanté sur une machine hôte, en général un gros ordinateur. On écrit dans une première étape un système d'exploitation pour une machine abstraite possédant un jeu d'instructions très riche : la machine À • Le système-objet produit par SPIP est un système d'exploitation prêt à fonctionner sur le mini-ordinateur choisi. Une simple option dans SPIP permet de sélectionner la machine-objet. A l'heure actuelle, 2 options sont implantées : option N pour Data General Nova et option P pour DEC PDP-11.

2.1.1 Les différentes parties de SPIP SPIP se compose de 4 parties

1. Un compilateur accepte un programme écrit dans le symbolique SPIP et produit comme langage-objet, indépendant du mini-ordinateur : le code À.

langage un code 2. Un ensemble de procédures traduit le code À en code relogeable spécifique au mini-ordinateur choisi. Halgré la dépendance du hardware, environ 80 % des procédures restent valables pour tous les mini-ordinateurs. C'est à ce niveau que s'effectue une optimisation conséquente.

3. Un éditeur de liens produit un code absolu pour le mini-ordinateur. Une optimisation de l'occupation mémoire est encore ass-urée par cette partie. Le programme d'édition de liens est indépendant du mini-ordinateur choisi.

4. Un simulateur de chaque mini-ordinateur permet l'interprétation du code absolu sur la machine hôte.

2.2 La machine À.

2.2.l L'unité centrale

C'est un processeur traitant des mots de 16 bits et des bytes de R bits. Il est connecté à une mémoire adressable indirectement, par registres d'index ou par page. Le processeur permet l'accès à divers

p~riphériques et possède un système d'interruption.

(30)

2.2.1.l Les registres et les structures

30 registres-mots de 16 bits, wl,w2, ••• ,w30 sont utilisés comme registres d'opérandes, dans le transfert entre le processeur central et les périphériques, comme registres d'index et rlans l'adressage par page.

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

11111111111111111

10 reeistres-byte de 8 bits, bl,b?., ••• ,blO servent comme registres d'opérandes et dans le transfert entre le processeur central et les périphériques.

La grande puissance de la machine À réside dans ses structures; en effet, les instructions du processeur peuvent manier directement 10 piles, sl,s2, ••• ,sln, 10 queues, ql,q2, ••• ,ql0, 10 chaînes, cl,c2, ••• ,cl0 et 30 tables, tl,t2, ••• ,t30. Les éléments composant ces structures peuvent être des mots et des bytes.

Nous allons définir ces 4 structures telles qu'elles sont implantées dans la machine À·

Définitions

Une pile est une accéd~ ajouter seulement.

zone de mémoire dynamique,

ou retirer un élément à dans laquelle on peut une de ses extrémités

Une queue est une zone de mémoire dynanique, dans laquelle on ne peut aJouter un élément qu'à une extréMité et n'en retirer un qu'à l'autre.

Une chaîne constitués proprement élément. Le

ou liste linéaire de 2 parties, dite, et l'autre premier élément de

est une structure formée d'éléments une partie contenant l'information partie un pointeur sur le prochain la chaîne est appelé tête de chaîne.

Une table est une zone de mémoire dans laquelle on peut accéder à n'importe quel élément par l'intermédiaire de l'adresse de l'élément appelée indice.

(31)

2.2.1.2 L'accès à la mémoire

Trois types d'adressage permettent d'accéder à la mémoire de la machine

1. L'adressage indirect : l'adresse effective de l'opérande est supposée être le contenu de l'emplacement désigné par l'adresse spécifiée.

2. L'adressage indexé : on obtenue en additionnant déplacement positif.

atteint un

le contenu mot-mémoire par la valeur d'un registre-mot et un 3. L'adressage par paêe : on atteint un mot-mémoire par un

déplacement relatif a la page spécifiée.

Les adressages peuvent être combinés.

Il faut encore signaler la possibilité d'accéder à des opérandes immédiats sans passer par un adressage.

Définition

Une page est une zone de mémoire de page-length mots. La mémoire est ainsi divisée en pages numérotées de 0 ^à N.

2.2.1.3 Les modules

Le processeur permet la définition et l'utilisation de 50 modules, ml,m2, ••• ,m50. Les modules peuvent être définis récursivement, l'adresse de retour, les paramètres et les objets locaux sont sauvés automatiquement.

2.2.2 Les entrées-sorties 2.2.2.l Les périphériques

Tous les transferts entre registres simples et structures avec les périphériques sont possibles.

Le disque est accessible par secteurs, les transferts se font entre page de la mémoire et secteur disque.

Le traitement de fichiers s'effectue par l'intermédiaire des unités logiques fl à flO.

2.2.2.2 Le système d'interruption

La machine possède un système d'interruption qui permet n'inter- rompre le programme en cours d'exécution à la demande d'un équipement périphérique. Un branchement à un mode de traitement d'interruptions est effectué automatiquement. Des priorités d'interruptions peuvent être attribuées.

2.2.2.3 Le jeu d'instructions

Il sera présenté dans le cadre du langage SPIP au chapitre 3.

(32)

2.3 Le choix du langage d'implantation de SPIP

Pour implanter SPIP, il fallait choisir un bon langage d'implantation. Pour ce choix, nous avions différents critères à examiner pour chaque langage :

L'existence d'un compilateur sur l'installation utilisée.

- Les facilités intrinsèques (instructions de contrôle, structures de données) et leur intérêt pour notre projet.

- La sécurité.

La performance.

La portabilité.

2.3.1 Les différents langages et leur compilateur

Nous savions que notre projet débuterait sur un ordinateur CDC CYBER-173 pour être poursuivi et terminé sur une UNIVAC-1108. Il nous fallait donc choisir un langage dont le compilateur existait pour les 2 machines. Sur la CDC, les compilateurs et interpréteurs suivants étaient . disponibles : Algol 60, Basic, Cobol, Fortran, Lisp 1.5, Pascal, Simscript, Simula 67 et Snobol 4.

Sur l'Univac, on pouvait espérer avoir les compilateurs ou interpréteurs suivants : Algol 60, APL, Basic, Cobol, Fortran, GPSS, Lisp 1.5,v-Algol, Simscript, Simula 1 et Snobol 4.

En prenant l'intersection des 2 ensembles de compilateurs, il nous restait : Algol 60, Basic, Cobol, Fortran, Lisp 1.5, Simscript et Snobol 4.

2.3.2 Les facilités intrinsèques des langages et nos besoins

L'égalité de Wirth : Algorithms + Data Structures

=

Programs (1) nous montre qu'il est important d'avoir de bonnes instructions de contrôle pour exprimer nos algorithmes et des structures de données correspondant à ces algorithmes.

Un système comme SPIP utilise entre autres des algorithmes de tri rapide (quicksort), de recherche binaire et nous pousse à choisir un langage récursif. Les structures de données naturelles dont on a besoin sont les chaînes, pour éviter les limitations des tableaux, les arbres pour les tables de symboles. L'organisation interne de la machine À , la représentation des informations relatives aux instructions, nous montrent l'intérêt de structures hiérarchiques telles que les enregistrements. La pauvreté en instructions de contrôle et en structures de données et l'absence de récursivité de Fortran et Basic nous les a fait rejeter d'emblée. Les structures dynamiques telles que chaînes et arbres ne pouvaient être construites que sous forme statique à l'aide de tableaux en Al8ol 60 et en Cobol. La récursivité était absente dans ce dernier.

Il ne nous restait que Lisp 1.5, Snohol 4 et Sirnscript, des langages plus spécifiques qui ne convenaient pas à nos projets.

Il fallait donc choisir entre un langage ne possédant pas toutes les facilités requises ou implanter un langage.

(33)

2.3.3 La sécurité

Le but poursuivi dans le projet SPIP était l'implantation d'un système sûr, il était donc nécessaire de baser nos développements sur les fondements de la progranunation structurée énoncés par Dijkstra (2,3,4), Dahl (5), Hoare (6,7), Naur (8) et Wirth (1,9,10).

Si la sécurité dans la programmation est surtout une affaire de discipline (11), il n'en reste pas moins que le choix d'un langage qui s'y prête nous semble primordial. Nous ne pouvons suivre Tenny (12) et croire à la progrannnation structurée en Fortran, de même que nous pensons que si PL/l est considéré comme un langage structuré, les abus qu'il permet lui confèrent un danger certain.

L'approche "top-down", c'est-à-dire la conception d'un programme par raffinements successifs (13), base de la programmation systématique (14) introduite par Wirth ainsi que les affirmations de Dijkstra (2) qu'un être humain n'est pas capable de maîtriser intellectuellement plus d'une page de programme nous ont conduits à choisir un langage permettant une très grande modularité, excluant de ce fait Cobol ou Basic. Seuls, 3 langages nous semblaient répondre aux qualités de sécurité que nous exigions : Algol 60, Pascal et Simula 67.

2.3.4 La performance Le souci de performance Algol 60 et Simula 67 perf orrnances données par

2.3.5 La portabilité

de notre système nous incita à abandonner et à nous diriger vers Pascal dont les Wirth (15) nous semblaient encourageantes.

Nous définirons plus précisément la notion de portabilité dans le chapitre S, mais nous pouvons accepter la définition de Poole et

\faite (16) : "la portabilité est une mesure de la facilité avec laquelle un progranune peut être transféré d'un environnement dans un autre".

Nous devions commencer le développement de notre système sur un ordinateur et le terminer sur un autre, il nous fallait donc un langage favorisant cette portabilité.

Les entrées-sorties du langage Algol 60 (17) , varient beaucoup d'un constructeur à l'autre. Lecarme (18) prétend que la seule instruction Fortran réellement acceptée de la même façon par tous les compilateurs, est l'instruction CONTINUE, peut-être exagère-t-il, mais le fond reste vrai. Il juge également que le langage le plus approprié à la portabilité d'un prograrrane est Pascal, point de vue que nous partageons.

(34)

2.4 Le langage Pascal

2.4.1 Problèmes d'implantation

Pascal semblait le langage adéquat pour le développement de SPIP, pourtant un inconvénient majeur subsistait, il nous fallait un compilateur sur Univac-1108; nous avons donc étudié la possibilité d'implanter Pascal sur cette machine; le premier pas fut la réalisation d'un compilateur-interpréteur Pascal-S écrit en V-Algol (19). Puis nous nous sommes lancés dans la réécriture de la génération de code du compilateur d'Ammann (20,21); entre temps, nous avons appris l'existence d'un compilateur développé à l'Université de Copenhague (22) et c'est avec ce compilateur que nous avons terminé l'implantation de SPIP sur l'Univac tout en continuant le développement du compilateur projeté, l'Université de Copenhague nous ayant refusé la version source de son compilateur et de nombreuses améliorations étant désirées.

2.4.2 Qualités et défauts de Pascal

Les prétentions de Pascal ne sont pas celles d¹Algol 68, mais le langage facilite une bonne programmation par d'excellentes instructions de contrôle (if then else, repeat ••• until, while do, boucle for et case •• of)~e'"td:ë'Piii'Ssantes structures de données (tableaux;- enregistrements, pointeurs, ensembles et fichiers). Les procédures peuvent être récursives et il existe 2 types de passages de paramètres, les contrôles à l'exécution sont efficaces et le code est performant.

Nous ne suivrons pas Uabermann (23) et ses critiques aiguës contre le langage de Wirth; nous avons réalisé un système qui compte plus de 14'000 lignes de Pascal et la seule limitation que nous ayons rencontrée est l'impossibilité de passer comme paramètre une chaîne variable de caractères due à l'absence de définition des tableaux de longueur variable. Nous partageons les points de vue de Lecarme et Desjardins (24,25) dans la défense du langage Pascal. Néanmoins, nous aimerions préciser que tout naturellement et sans parti-pris, nous n'avons jamais employé l'instruction goto si contreversée

(3,26,27,28,29).

Nous pensons que nous n'aurions jamais pu développer SPIP en si peu de temps (environ un homme-année) dans un langage autre que Pascal.

2.5 Historique de SPIP

Nous voulons montrer par cet historique, l'évolution des idées maîtresses de SPIP.

Novembre 1974: conception des premières idées.

Janvier 1975 : l'idée d'écrire un ensemble de procédures Pascal sur CDC Cyber produisant un code pour un mini-ordinateur Nova est née. Un texte résumant ce projet est envoyé au responsable de l'école de printemps d'informatique 1975. (30)

(35)

Mars 1975 Avril 19 75

Mai 1975 Juin 1975

Mars 1976

Juillet 1976 Août 1976

Septembre 1976

Octobre

début de l'écriture des procédures de génération de code.

nous présentons le projet à l'école de printemps d'informatique aux Diablerets en présence de N. Wirth et C.A.R. Hoare. La machine ^À est née.

nous développons un simulateur de la Nova en Pascal.

l'Université de Genève reçoit l'Univac-1108 qu'elle a commandée. Nous arrêtons le projet SPIP momen- tanément, pour nous lancer dans la réalisation d'un compilateur-interpréteur Pascal-S (19), puis d'un compilateur Pascal.

nous recevons la version exécutable du compilateur Pascal 1100, développé par l'Université de Copenhague

(22). Le projet SPIP est reparti.

Nous constatons que les appels de procédures comme langage de base sont trop peu souples à l'emploi et coûteux en mémoire, nous décidons d'écrire un compilateur, la transition est expliquée dans notre cours ¹¹La construction des compilateurs" (31).

le compilateur fonctionne.

nous écrivons un éditeur de liens pour produire du code absolu.

nous développons un simulateur de la PDP-11 en Pascal et commençons les procédures de génération de code PDP-11.

Novembre 1976: nous développons le système

s.o.s.,

écrit dans le langage SPIP ainsi que le compilateur et l'inter- préteur Pascal-S, fonctionnant sous ce système.

Février 19 77 le système S.O.S. fonctionne. (32)

(36)

Références (1) Wirth, N.

Algorithms + Data Structures

=

Programs.

(2) Dijkstra, E.W.

A constructive approach to the problem of program correctness.

In : Bit 8 (1968), pp. 174-186.

(3) Dijkstra, E.W.

Goto statement considered harmful.

(4) Dijkstra, E.W.

Notes on structured programming.

In : Structured Programming, New York, Academic Press Inc., 1972.

(5) Dahl, o.J.

Hierarchical program structures.

In : Structured Programming, New York, Academic Press, 1972.

(6) Hoare, C.A.R.

Monitors : an operating system structuring concept.

(7) Hoare, C.A.R.

Notes on data structuring.

In : Structured Programming, New York, Academic Press Inc., 1972.

(8) Naur, P.

Programming by action clusters.

In : Bit 9 (1969), pp. 250-258.

(9) Wirth, N.

On the composition of well-structured programs.

In : Computing Surveys, 6 (1974) 4, pp. 247-259.

(10) Wirth, N.; lloare, C.A.R.

A contribution to the development of Algol.

(11) Dijkstra, E.W.

A discipline of programrning.

(12) Tenny, T.

Structured Programming in Fortran.

In : Datamation, Juillet 1974, pp. 110-115.

(13) Wirth, N.

Program development by stepwise refinernent.

In : Communications of the ACH, 14 (1971) 4, pp. 221-227.

(14) Wirth, N.

Systematic Programming : An Introduction.

(37)

(15) Wirth, N.

The design of a Pascal Compiler.

(16) Poole, P.C.; Waite, W.M.

Portability and adaptability.

In : Advanced course in software engineering.

Berlin, Springer-Verlag, 1973.

(17) Naur, P.

Revised report on the algorithmic language Algol 60.

In : Communications of the ACM, 6 (1963), pp. 1-17.

(18) Lecarme,

o.

Le langage Pascal comme outil d'écriture de programmes transportables.

In : Compte-rendus des journées sur l'implantation, le développement et les applications du langage Pascal.

Nice, juin 1976, pp. 5-20.

(19) Thalmann, D.

Compilateur-Interpréteur Pascal-S, bibliothèque de programmes Univac 1108.

In : Courrier Uni Informatique, Université de Genève, 7 (1976).

(20) Ammann, U.

The method of structured programming applied to the development of a compiler.

In : International Computing Symposium 1973.

(21) Ammann,

u.

(22)

Die Entwicklung eines Pascal-Compilers nach der Uethode des Strukturierten Programmierens. (Diss).

ZÜrich, Juris Druck + Verlag, 1975.

Steensgaard-Madsen, J.

A Pascal compiler for Univac 1100 machines.

Datalogisk Institut, University of Copenhagen,

publié). 1976' (non

(23) Habermann, A.N.

Critical comments on the programming language Pascal.

In : Acta Information, 3 (1973), pp. 47-53.

(24) Lecarme, O.; Desjardins, P.

More comments on the programming language Pascal.

In : Acta Informatica, 4 (1975), pp. 231-243.

(25) Lecanne, O.; Desjardins, P.

Reply to a paper by A.N. Habennann on the programming language Pascal.

In: Sigplan Notices, 9 (1974) 10, pp. 21-27.

(26) Hopkins, M.E.

A case for the GOTO.

In : Proceedings of the ACM Annual Conference.

Boston, Mass., 1972, pp. 787-790.

(38)

(27) Wulf. W .A.

A case against the GOTO.

Boston, Mass., 1972, pp. 791-797.

(28) Knuth, D.E.

Structured progranuning with goto statements.

In : Computing Surveys, 6 (1974) 4, pp. 261-301.

(29) Leavenworth, B.M.

Programming with(out) the goto.

Boston, Mass., 1972, pp. 782-786.

(30) Thalmann, D.

Rapport pour l'école de printemps Diablerets, 1975 (non publié).

(31) Thalmann, D.

d'informatique des

La construction des compilateurs, vol. 1-2.

(32) Thalmann, D.; Levrat, B.

SPIP : A way of writing portable operating systems.

In : International Computing Symposium 1977. Proceedings of the ACM.

(39)

Chapitre 3 Le langage SPIP

Nous ne pouvons décrire ici toutes les facilités du langage SPIP, vu sa richesse nous nous limiterons à une explication sommaire des instructions ou à des exemples explicatifs. Les possibilités complètes du langage sont décrites dans le manuel d'utilisation (1).

Nous insisterons sur les motifs qui nous ont poussés à certains choix.

Avant d'exposer le jeu d'instructions du langage, nous allons préciser les possibilités offertes dans le choix des opérandes.

3.1 Les champs des instructions

Les champs des instructions du langage SPIP sont le plus fréquemment des mots ou des bytes. Ils peuvent encore être des modules, des périphériques ou des mots-clé. On distinguera 3 catégories de champs:

a) les champs source

modifiée. : l'information est connue et ne peut être b) les champs destination

modifiée. l'information peut être inconnue et est c) les champs source-destination (s-destination)

connue et est modifiée. l'information est 3.1.l Les champs-mot

On peut donner la classification suivante a) Champs destination, s-destination et source

registres

adressage indexé

adressage par page

adressage indirect

structures

wl,w2, ••• w30

ind <déplacement > registre

le déplacement est un entier positif.

p.e. ind 5 w2

page <déplacement><nœnéro de pagè>

le déplacement et le numéro de page peuvent être des registres ou des entiers positifs.

p.e. page wl w2 page 5 w3 page w4 0 indirect <adresse>

l'adressage est indexé ou par page p.e. indirect ind 5 wl

indirect page w4 w5

piles, queues, chaines : l'accès se fait conformément au type de structure

tables : non autorisé.

Écriture de systèmes d&#039;exploitation portables pour mini-ordinateurs

Thesis

Reference