Suivez-nous sur X
|
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z,
ALL
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z
|
|
A propos d'Obligement
|
|
David Brunet
|
|
|
|
Dossier : Histoire et spécifications de Tripos
(Article écrit par Stéphane Mayère et extrait d'A-News (Amiga News) - janvier 1990)
|
|
Lorsque j'ai acheté mon premier Amiga, il y a bientôt deux ans, j'ai été impressionné par la puissance du système
d'exploitation. Ce système, à l'époque la version 1.2, était déjà, hormis quelques défauts de jeunesse, un OS
(operating system) perfectionné et performant. Rappelez-vous en comparaison les versions 1.xxx
de MS-DOS qui ne géraient pas de répertoires, pas de disques durs et des disquettes de 160 ko
(quand on sait que DOS veut dire "Disk Operating System"...). Bref, on pouvait se demander pourquoi
AmigaDOS était né majeur et qui était MetaComCo, société quasi inconnue qui l'avait créé.
Nous verrons également en détail un point spécifique d'AmigaDOS : la structure des fichiers.
Mais tout d'abord...
Un peu d'histoire
MetaComCo est une société britannique, fondée en 1981 et basée à Bristol. Le premier produit de la société
fut un interpréteur BASIC portable, écrit en BCPL, un précurseur du C. Cet interpréteur fut ensuite adapté
pour le 8086 puis vendu à Digital Research Inc. Les redevances de ce BASIC permirent à MetaComCo de
s'installer en Californie et de se faire connaître aux États-Unis.
En 1984, MetaComCo engage Tim King, un informaticien de Cambridge, et commence à s'intéresser au MC68000
que nous connaissons tous et sur lequel Tim King a travaillé depuis 1981. La société produit alors une
série d'outils de développements écrits en BCPL : un éditeur, un macro-assembleur et un éditeur de lien.
A ce moment-là, il n'y avait pas de système d'exploitation standard établi pour le 68000. MetaComCo
décida donc d'en écrire un : Tripos était né.
Le système d'exploitation Tripos était basé sur un noyau multitâche développé à Cambridge en 1976
(c'est vieux...) dans le cadre d'une thèse de doctorat ("Tripos" est le nom familier donné par les
étudiants aux examens de fin d'année de Cambridge). Tripos a été écrit en BCPL pour un DEC
PDP-11 (mini-ordinateur 16 bits de la société Digital) et a été transformé par King
en système d'exploitation multitâche utilisable sur ordinateurs 32 bits.
Tripos ressemble à Unix mais comporte pas mal d'innovations : nous verrons la structure des fichiers
plus loin. MetaComCo a également acquis les droits du Cambrige LISP (qu'on retrouvera sur l'Amiga
plus tard) développé au départ pour un IBM 370 puis adapté pour le 68000. La société développera
un peu plus tard un compilateur Pascal.
Le DOS de trois semaines
L'histoire d'AmigaDOS commence en novembre 1984. MetaComCo prend contact avec Amiga Corporation (qui venait
d'être rachetée par Commodore) pour discuter de la vente de leur compilateur Pascal pour la nouvelle
machine d'Amiga Corporation. Pendant ces discussions, il a été révélé que le système d'exploitation de l'Amiga
était très en retard par rapport aux prévisions et posait des problèmes (les mauvaises habitudes commençaient...
Wait and See pour la version 1.4).
Les spécifications d'Amiga pour le système d'exploitation du Lorraine (c'était le nom du prototype) étaient les
suivantes :
- Il devait être multitâche.
- Il devait gérer les entrées/sorties synchrones et asynchrones.
- Les entrées/sorties devaient être continues et indépendantes du matériel.
Toutes ces spécifications reprenaient les caractéristiques de Tripos que MetaComCo commencait à commercialiser
sur machines 68000. Amiga accepta de tester le système dans le cas où leur propre OS
(CAOS) ne fonctionnerait pas.
En février 1985, l'accord fut donné à MetaComCo et Tripos fut adapté sur le prototype de l'Amiga en trois semaines
grâce à la portabilité du BCPL. La démonstration du système fut un succès, l'ancien OS d'Amiga (CAOS) fut
abandonné et la conversion de Tripos en AmigaDOS commença. Heureusement pour MetaComCo, l'architecture
interne de Tripos correspondait bien à l'architecture prévue pour l'Amiga. Tripos est organisé autour
d'un OS classique, avec des commandes en lignes, des pilotes de périphériques, des annexes et des
communications systèmes (pour les adressages de coprocesseurs, de périphériques...).
Les programmeurs d'Amiga avaient déjà les ROM contenant les routines d'annexage et les adressages des
puces spécialisées, comme le Copper et le Blitter, qui gèrent l'animation, le graphisme et le son.
L'équipe de MetaComCo intégra ces routines avec leur système d'entrées/sorties pour disques, fichiers,
imprimantes, affichage ainsi que leur interpréteur de commandes pour en faire ce que nous connaissons
sous le nom d'AmigaDOS.
L'équipe d'Amiga s'occupa de produire l'interface graphique Intuition, qui s'appuie sur AmigaDOS.
MetaComCo s'occupa également de la mise au point du CLI comme d'une interface dédiée aux programmeurs
et aux utilisateurs expérimentés. Les langages de programmation de MetaComCo furent également implémentés
sur l'Amiga : Pascal, Lisp et BASIC.
Le noyau des systèmes - Tripos et AmigaDOS
Le système Tripos comporte quelques nouveautés par rapport à ce qu'on peut trouver sur d'autres OS
de micro-ordinateurs, en particulier en ce qui concerne l'organisation des fichiers sur disque,
et qu'on retrouve dans AmigaDOS. La plupart de ces idées nouvelles viennent de ce que Tripos
était au départ un projet de recherche en informatique.
Tripos est basé sur un concept de tâches multiples et de communications. Quand une application (tâche)
démarre, elle est informée du nombre des autres tâches qui tournent en même temps qu'elle. Chaque
tâche possède donc un numéro. Notre application va donc pouvoir repérer les tâches dont elle a besoin
pour communiquer avec les différents périphériques. Certaines de ces tâches sont, dans ce qu'on appelle
en jargon informatique, en "hibernation" en attendant d'être "réveillées" par les différents programmes
qui auront besoin d'elles.
Il y a par exemple une tâche de "débogage" qui tourne perpétuellement, ce qui est un avantage terrible
pour les programmeurs.
Chaque périphérique est desservi par sa propre tâche. Toutes les tâches tournent en concurrence les
unes par rapport aux autres ou, plus exactement, en pseudo-concurrence, car comme il n'y a qu'un
processeur central, le 68000, chaque application dispose à tour de rôle des ressources qui lui sont
nécessaires en envoyant et en recevant des messages (et oui, l'Amiga n'est pas encore une machine
multiprocesseur à architecture parallèle, peut-être qu'avec les transputers...).
Si un programme
nécessite 200 octets de stockage sur disque, il envoie un message à ce que j'ai appelé dans la figure
la tâche fichier en lui demandant de lui allouer cette place sur le disque. La tâche fichier,
de son côté, a son propre cache mémoire et va prendre un secteur (512 octets) dans cette mémoire
cache, puis va rentrer en communication avec l'unité disque souhaitée qui a également son propre
tampon mémoire (dans ce cas, des pistes sur le disque) et lui transférer ce secteur. De cette façon,
toutes les pistes à écrire sont lues en une seule fois. La tâche fichier envoie alors un message
au programme de départ pour l'informer que le stockage est maintenant possible (ça va plus vite
à faire qu'à dire...).
Une des conséquences de ce système est que, contrairement à des systèmes simples comme MS-DOS ou le
défunt CP/M, les accès disques peuvent se faire apparemment aléatoirement sans que l'utilisateur
n'intervienne.
La seule limitation au nombre de tâches simultanées est la mémoire disponible,
puisqu'il n'y a pas de système de mémoire virtuelle : une mémoire virtuelle utilise temporairement
les mémoires de masse (disques) en attendant que la mémoire soit de nouveau disponible. Apple
s'y met avec le nouveau système 7.0 du Macintosh, alors monsieur Commodore, et cette version 1.4 !
Pour pallier à cet inconvénient, un système de code partageable est utilisé pour minimiser la
place mémoire lors d'appels multiples à des tâches similaires. On peut donner différentes priorités
aux tâches, ceux qui ont été fouiner dans la liste de montage (mountlist) s'en seront rendu
compte, et chaque application, programme, etc. peut être exécutée en tâche de fond avec la commande
"Run <nom de programme>".
Le CLI ou le Shell sont des tâches également, on peut donc en invoquer autant qu'on veut. L'interface
système de communication et de message est très semblable à Unix et est identique pour les périphériques
et les applications ; elle comporte des messages de type Open, Close, Read, Write, Seek (Ouvrir, Fermer,
Lire, Écrire, Chercher).
La structure des fichiers sur le disque
C'est sur le terrain de la structure des fichiers sur disque que Tripos est radicalement différent.
Pour commencer, il n'y a pas de pistes de répertoires sur un disque Tripos, et en fait il n'y a pas
de répertoire du tout dans le sens habituel de table de nom de fichier. D'ordinaire, un répertoire
contient des pointeurs vers des noms de fichiers. A la place Tripos utilise un "Root Block" qui
est placé au centre du disque, généralement sur la piste 0. Ce Root Block (ou secteur racine,
je garde volontairement les termes anglais pour ceux qui bidouillent avez les éditeurs de
piste et de secteurs...) contient le nom du volume ainsi que les dates de création et de dernière
modification.
Vient ensuite la "hash table" (table de vérification) par laquelle les fichiers ou les noms de sous-répertoires
sont transformés en numéros de secteurs. Chaque secteur ainsi pointé peut donc être un fichier ou un répertoire
conduisant à une structure arborescente comme on peut en trouver sous Unix ou MS-DOS. Il peut se produire
des collisions : supposons que les deux fichiers "Chorizo_Kid" et "El_Yéti" soit contrôlés par le même secteur.
Des secteurs d'extension vont être chaînés sous le secteur de vérification, et la collision sera évitée en
chaînant les fichiers !
Les sous-répertoires ont la même structure que le secteur racine, alors que les en-têtes de fichiers contiennent
le nom du fichier, la date, ses attributs (S,H,P,A,R,E,W et D) et une table comportant le nombre de secteurs
de données du fichier. La taille d'un secteur est fixée à 512 octets en AmigaDOS (1024 octets sous le système
Tripos). Quand un en-tête de fichier déborde de la place allouée par la table, il se raccorde à un secteur
d'extension selon le principe décrit plus haut.
Pour optimiser la vitesse d'accès aux données, les en-têtes de fichiers et les sous-répertoires sont assignes
d'un côté du Root Block, et les blocs de données de l'autre côté. Ainsi, les secteurs consécutifs d'un
même fichier sont regroupés ensemble.
Ce système a plusieurs avantages, comparé aux systèmes d'exploitations plus
conventionnels. En particulier, il n'y a de limite à rien : les fichiers sont régis
par la seule capacité de stockage du disque. De plus, il n'y a pas de distinction entre les fichiers binaires
et les fichiers ASCII, car ils ne contiennent pas d'indicateurs de fin de fichiers comme les Ctrl-Z
sur d'autres systèmes. Du point de vue du disque, tous les fichiers sont identiques : juste des secteurs
de "matière".
Il y a encore plus fort (si, si...). Tous les secteurs constituant un fichier contiennent des pointeurs
vers le prochain secteur en ligne (pour un meilleur accès séquentiel) et également un pointeur de retour
vers le secteur d'en-tête de fichier. C'est une trouvaille géniale car même si un en-tête de fichier est
complètement détruit, on peut le reconstruire complètement en lisant ces fameux pointeurs de retour
contenus dans les secteurs de données : les secteurs de données contiennent chacun leur propre
"carte d'identité". Le diskdoctor du DOS permet selon ce principe de reconstruire complètement et
automatiquement un disque, fichiers et répertoires, et ce à presque tous les stades de détérioration.
Ce type de stockage est un grand pas en avant dans la sécurité des mémoires de masse comparé à MS-DOS
par exemple, où la destruction d'une piste d'un répertoire peut conduire à la perte définitive des données.
En contrepartie, le seul défaut imputable au système d'AmigaDOS est sa lenteur lors des listages de
répertoires, et des opérations sur les fichiers en général. En effet, il n'y a pas de FAT (File Allocation Table),
c'est-à-dire pas d'endroit unique auquel se référer pour chercher un fichier, toute l'arborescence du disque
doit être parcourue pour trouver le nom cherché. On voit désormais, avec le multitâche et les temps d'accès
disque assez imprévisibles, la nécessité de traiter les disquettes, en particulier lors des changements,
avec beaucoup de douceur !
Tripos (et donc AmigaDOS) garde en mémoire une représentation de l'utilisation du disque (une sorte de FAT donc...)
qui comporte un bit pour chaque secteur utilisé. Comme on l'a vu au début (si vous ne l'avez pas oublié !)
chaque tâche fichier a son propre tampon en mémoire, et après chaque accès disque, il y a une période de
deux à trois secondes pendant laquelle la tâche scrute son tampon mémoire et met à jour le disque d'après
sa représentation en mémoire.
Si le disque est enlevé pendant ces quelques secondes (ce que tout le monde a déjà expérimenté au moins une fois),
la mise à jour du disque (qui n'est plus là, je le rappelle car j'en vois qui dorment dans le fond) est
invalidée, une requête système apparaît et quand le disque est réinséré, une tâche de validation va
automatiquement être invoquée pour reconstruire la représentation du disque en mémoire. En fait, la seule
façon de perdre de l'information est de retirer un disque quand le lecteur est en train de tourner.
A ce propos, il a été question pendant un temps d'avoir un système d'éjection logicielle
comme sur le Macintosh d'Apple, mais l'idée a été abandonnée.
AmigaDOS reconnaît une disquette par son nom de volume et peut donc la retrouver dans n'importe quel lecteur,
ou, demander son insertion dans n'importe quel lecteur. Il est également possible d'enlever un disque avec un
fichier encore ouvert, d'utiliser un autre disque, de replacer le premier, et de retrouver le fichier dans
le même état. Comme sous Unix, les périphériques sont adressés comme des fichiers, avec un nom de périphérique
remplaçant le nom de volume dans les commandes. Par exemple, le périphérique CON: peut être suivi des paramètres :
"CON:20/20/100/100/MaFenêtre".
Les sorties série et parallèle peuvent être adressées de la même manière.
C'est fini
Voilà la petite histoire d'AmigaDOS. On peut comprendre sa maturité et ses innovations techniques par le
fait que Tripos existait déjà depuis près de 10 ans à la sortie de l'Amiga et qu'il était issu d'un projet de recherche.
|
