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 : Tripos, les racines d'AmigaDOS
(Article écrit par Dick Pountain et extrait de Byte - février 1986)
|
|
MetaComCo est la société britannique à l'origine d'AmigaDOS
Une question qui doit laisser perplexe de nombreuses personnes dans les cercles informatiques
américains est "Qu'est-ce que MetaComCo ?". Lorsque Commodore a annoncé son spectaculaire
ordinateur Amiga, une grande partie de la presse américaine a omis de signaler (et peut-être
ne savait-elle pas) que le système d'exploitation avancé AmigaDOS était en fait écrit par
une petite maison de logiciels britannique appelée MetaComCo.
MetaComCo est basée à Bristol, en Angleterre, une ville qui commence à rivaliser avec
Cambridge en tant que capitale potentielle de l'informatique (elle abrite également
TDI-Pinnacle, INMOS et d'autres). MetaComCo a été fondée en 1981 par Derek Budge et
Bill Meakin et emploie aujourd'hui environ 25 personnes, principalement des programmeurs
et d'autres personnels techniques.
Le premier produit de la société fut un interpréteur BASIC portable écrit en BCPL, l'ancêtre
du C, qui est enseigné et utilisé de manière intensive à l'université de Cambridge. Cet
interprète a été porté sur le processeur 8086 et a été vendu peu après à Digital Research Inc.
qui commercialise toujours son descendant sous le nom de Personal BASIC. Ce lien avec les
États-Unis est devenu très important pour MetaComCo, car les redevances ont constitué une
source régulière de revenus pendant les premières années cruciales et ont permis à la société
d'établir un bureau en Californie, ce qui a permis à MetaComCo de rester en contact avec la
scène informatique américaine.
En 1983, le Dr. Tim King, un informaticien de Cambridge, a été engagé par la société en
tant que consultant, et MetaComCo a mis l'accent sur le processeur 68000, avec lequel
Tim King avait travaillé depuis la sortie des premiers échantillons en 1981. La société
a produit une série d'outils de développement, également écrits en BCPL, dont un éditeur
plein écran, un assembleur de macros et un chargeur de liens. A cette époque, il n'y
avait pas de système d'exploitation standard clairement établi pour le 68000, l'étape
suivante était donc d'en écrire un. C'est ainsi qu'est né Tripos.
Le système d'exploitation Tripos est basé sur un noyau multitâche développé dans le cadre
d'un projet de thèse de doctorat à Cambridge en 1976 ("tripos" était le nom donné aux
tabourets à trois pieds sur lesquels les étudiants s'asseyaient autrefois pour passer leurs
examens et est devenu depuis le nom familier des examens finaux de Cambridge). Tim King,
qui travaillait alors à l'université de Bath, a pris le noyau écrit pour un DEC PDP-11 et
l'a transformé en un système d'exploitation multitâche complet de 32 bits pour le micro-ordinateur
Sage (qui était nouveau à l'époque). Tripos est écrit en BCPL de la même manière qu'Unix
est écrit en C, et il possède de nombreuses caractéristiques innovantes dont je vais parler.
MetaComCo avait également acheté les droits de Cambridge LISP, un puissant interprète/compilateur
LISP développé à l'origine pour l'IBM 370 et ensuite porté sur 68000 à Cambridge. MetaComCo a
produit des versions pour l'infortuné CP/M 68K et ensuite pour Tripos. Reduce 3, un système
de mathématiques symboliques écrit en LISP, a été ajouté pour produire une station de travail
basée sur Sage qui a été vendue à des institutions de recherche dans différents pays.
Parmi les clients figuraient SORD au Japon et INMOS, le voisin de Bristol, qui a utilisé
BCPL pour la première étape de l'amorçage de son compilateur Occam sur le 68000, en
utilisant des ordinateurs Sage fonctionnant avec Tripos.
En 1984. Tim King rejoint MetaComCo à plein temps en tant que directeur de recherche, et
Sinclair Research lance le QL. Au départ, le QL ne disposait pas d'un environnement de
développement de logiciels sérieux, et MetaComCo a pu rapidement y porter ses outils de
développement, notamment le compilateur BCPL. La société a depuis étendu la gamme pour
inclure un ordinateur Pascal validé par l'ISO (Organisation internationale de normalisation),
et elle commercialise ces produits directement, plutôt que par l'intermédiaire du fabricant,
essentiellement par correspondance.
Novembre 1984 est la date cruciale dans l'histoire d'AmigaDOS. MetaComCo rend visite à Amiga
Corporation (qui est encore en train de finaliser son achat par Commodore) pour discuter
de la vente du compilateur Pascal 68000 de MetaComCo pour la nouvelle machine Lorraine
d'Amiga, comme on l'appelle alors. Au cours de ces discussions, il est apparu que le système
d'exploitation d'Amiga avait pris beaucoup de retard et suscitait quelques inquiétudes. Les
stipulations d'Amiga pour le système d'exploitation du Lorraine étaient qu'il devait être
multitâche, qu'il devait gérer les entrées/sorties synchrones et asynchrones, et que les
entrées/sorties devaient être basées sur les flux et indépendantes du matériel.
MetaComCo commercialisait déjà un tel système d'exploitation, Tripos, fonctionnant sur
68000. Amiga a accepté de considérer Tripos comme une assurance, au cas où son système
déjà commercialisé ne fonctionnerait pas.
En février 1985, MetaComCo a reçu le feu vert, et Tripos a été porté sur l'Amiga en trois semaines seulement,
grâce à sa portabilité BCPL (bien que le noyau soit écrit en code 68000 pour des raisons d'efficacité).
Tim King se souvient que lorsqu'il en a fait la démonstration à la fin du mois de février 1985, il s'est détourné
de l'écran pour constater que toute l'équipe Amiga était réunie pour applaudir ; le matériel était soudainement
devenu un véritable ordinateur. Le système d'exploitation existant a été abandonné, et le travail de transformation
de Tripos en AmigaDOS a commencé.
Heureusement pour MetaComCo, il y avait une correspondance remarquable entre la structure interne de Tripos
et l'architecture logicielle prévue pour Amiga. Tripos est conceptuellement organisé sur les lignes classiques
d'un système d'exploitation, avec un planificateur, un système de passage de messages et un ensemble de pilotes
de périphériques. Les programmeurs Amiga disposaient déjà de routines ROM (read-only memory) pour effectuer les
tâches d'ordonnancement et de passage des messages, ainsi que des pilotes de périphériques essentiels pour les
puces personnalisées très spéciales, le Copper et le Blitter, qui gèrent les graphismes, les animations et le
son. L'histoire aurait pu s'arrêter là s'il avait fallu écrire les pilotes suivants à partir de zéro, étant donné
qu'il s'agissait d'éléments personnalisés nouveaux et inconnus et qu'ils n'étaient probablement que partiellement
débogués à l'époque. Les gens de MetaComCo ont intégré ces parties avec les entrées/sorties du système de fichiers,
du texte de la console, de l'imprimante et du processeur de ligne de commande de Tripos pour créer AmigaDOS.
L'équipe Amiga a produit l'arrière-plan logiciel pour les icônes/fenêtres appelé Intuition qui se trouve au-dessus
d'AmigaDOS ; nous devons cependant remercier MetaComCo d'avoir insisté pour qu'une interface de ligne de commande
sous-jacente soit toujours disponible en tant qu'interface pour les programmeurs et pour les utilisateurs plus
expérimentés.
Les relations entre Commodore-Amiga et MetaComCo sont désormais très étroites. Le Pascal, le LISP et un BASIC très
modifié de MetaComCo fonctionnent tous sur Amiga. L'histoire du BASIC est assez compliquée en soi. Amiga avait
déjà commandé à Microsoft une version de son BASIC pour Macintosh, très attendue, qui devait être installée sur la
machine. Lors du lancement en juillet 1985, cependant, c'est l'ABasic de MetaComCo qui a été vu par la presse,
bien que certaines "ambiguïtés" aient pu conduire les gens à penser qu'il s'agissait de celui de Microsoft.
Au moment où nous écrivons ces lignes, le langage qui a finalement été livré avec la machine semble encore assez
vague. MetaComCo travaille actuellement à l'amélioration d'ABasic pour permettre des procédures avec des paramètres,
des numéros de ligne optionnels et une compilation complète ; la version actuelle est structurellement toujours
au niveau de la version 5.2 de Microsoft. Elle possède cependant quelques commandes de gestion matérielle
Amiga étonnamment puissantes, telles que TRANSLATE et NARRATE, qui convertissent respectivement une chaîne ASCII
en une chaîne de phonèmes et la prononcent ensuite. Toute la puissance des puces spécialisées est accessible par
des instructions BASIC de haut niveau plutôt que par des PEEK et des POKE.
Tripos/AmigaDOS
Le système d'exploitation Tripos possède certaines caractéristiques que l'on ne trouve pas habituellement
dans les systèmes d'exploitation des micro-ordinateurs, en particulier dans le domaine de l'organisation
des fichiers sur disquette, et celles-ci ont été héritées par AmigaDOS. Beaucoup de ces idées avancées
proviennent de l'origine de Tripos, un projet de recherche en informatique ; il y a beaucoup d'emphase sur
la façon de faire les choses comme elles devraient être faites, plutôt que de se contenter de la façon dont
le dernier gars l'a fait. Tripos est basé sur les concepts de tâches multiples et de passage de messages.
Lorsqu'une tâche applicative est lancée, elle trouve un certain nombre d'autres tâches déjà en cours
d'exécution. En particulier, il y en aura une pour chaque périphérique auquel elle doit parler, bien que
certaines de ces tâches dorment jusqu'à ce qu'elles soient réveillées par une demande de service d'une
autre tâche. Une tâche de débogage s'exécute également en continu dans le noyau, ce qui est une grande aubaine
pour le programmeur. L'environnement d'une application, grandement simplifié, pourrait ressembler à la
figure 1.
Figure 1
Chaque périphérique est desservi par sa propre tâche. Toutes les tâches s'exécutent simultanément ou, à
proprement parler, en pseudo-courant, puisqu'il n'y a qu'une seule unité centrale de traitement, et
l'application obtient les ressources dont elle a besoin en envoyant et en recevant des messages. Si un
programme a besoin de 200 octets de stockage sur la disquette, il peut envoyer un message à la tâche fichier 1
pour le demander. La tâche fichier dispose de son propre tampon de cache et procède à l'introduction
d'un nouveau bloc dans le cache en communiquant à son tour avec la disquette, qui dispose de son propre
tampon de piste, de sorte que des pistes entières sont lues en une seule fois. Lorsque la tâche fichier
dispose du bloc, elle envoie un message à l'application indiquant que le stockage est désormais possible.
Une conséquence de cette structure est que, contrairement à des systèmes plus simples tels que CP/M et
PC-DOS, il est possible que l'activité de la disquette se produise à des moments apparemment aléatoires, sans
que l'utilisateur fasse quoi que ce soit pour la provoquer ; c'est assez effrayant jusqu'à ce qu'on
s'y habitue.
La seule limite au nombre de tâches pouvant être exécutées est la mémoire disponible ; il ne s'agit pas
d'un système de mémoire virtuelle, mais le partage de code est utilisé pour minimiser les besoins en mémoire
lors d'invocations multiples de tâches similaires. Il est possible d'attribuer des priorités aux tâches, et
toute tâche peut être exécutée en arrière-plan à partir de la ligne de commande en tapant "RUN <taskname>".
Le CLI est lui-même une tâche, et plusieurs CLI peuvent être créés si nécessaire.
L'interface de passage des messages est assez similaire à celle d'Unix et est identique pour tous les
périphériques et toutes les applications ; elle comprend des messages comme Open, Close, Read, Write et Seek.
Structure des fichiers
C'est dans le domaine de la structure des fichiers de la disquette que Tripos est vraiment radical. Pour
commencer, il n'y a pas de piste de répertoire sur une disquette Tripos, et d'ailleurs pas de répertoire
au sens habituel d'une table de noms de fichiers. Au lieu de cela, Tripos utilise un bloc racine,
qui est placé au centre de la surface de la disquette plutôt que sur une piste comme c'est le cas habituellement.
Le bloc racine contient le nom de volume de la disquette et les dates de création et de dernière modification.
Il est suivi d'une table de hachage, par laquelle les noms de fichiers ou de sous-répertoires sont
transformés en numéros de blocs. Chaque bloc ainsi pointé peut être un répertoire ou un fichier, ce
qui conduit à une structure de répertoire hiérarchique comme celle d'Unix ou de PC-DOS 2. Dans le cas
d'une collision de hachage (peut-être que "Fred" et "Bill" correspondent tous deux au même numéro de
bloc), les blocs d'extension sont enchaînés sur le bloc pointé et la collision est résolue par une
correspondance de chaîne (voir figure 2).
Figure 2
Les sous-répertoires ont la même structure que le bloc racine, tandis que les en-têtes de fichiers comportent
un nom de fichier, une date et une table des numéros des blocs de données qui constituent le fichier.
La taille du bloc est fixe (512 ko sous AmigaDOS, 1024 ko sous Tripos sur Sage). Lorsqu'un en-tête de
fichier manque d'espace pour sa table de blocs, il enchaîne simplement sur un bloc d'extension.
Pour optimiser la vitesse d'accès aux données, les en-têtes de fichiers et les sous-répertoires sont
alloués vers l'intérieur du bloc racine, tandis que les blocs de données sont alloués vers l'extérieur,
de sorte que les blocs consécutifs peuvent être rapprochés (voir figure 3).
Figure 3
Ce schéma global a plusieurs conséquences bénéfiques par rapport aux systèmes d'exploitation plus
conventionnels. Il n'y a aucune limite arbitraire sur quoi que ce soit ; les fichiers ne sont régis
que par la capacité de stockage physique du support. Tous les fichiers sont automatiquement à accès
aléatoire. De plus, il n'y a pas de distinction entre les fichiers binaires et ASCII, car les fichiers
n'ont pas besoin de contenir de caractères de contrôle spéciaux comme ^Z pour la fin de fichier.
Tous les fichiers sont identiques, ce ne sont que des blocs de "choses".
Mais il y a plus. Tous les blocs qui composent un fichier contiennent des pointeurs vers le bloc suivant
dans la file (ce qui permet un accès séquentiel efficace) et également un pointeur arrière vers leur
bloc d'en-tête. L'inclusion de ces caractéristiques signifie que même si l'en-tête d'un fichier est
complètement déformé, il peut être reconstruit par les pointeurs de lecture dans les blocs de données ;
les données individuelles connaissent leur propre identité (voir figure 4).
Figure 4
MetaComCo dispose également d'un programme, nommé "Disk Doctor", qui peut reconstruire une disquette,
à la fois les fichiers et les répertoires, à partir de presque n'importe quel état d'endommagement,
à l'exception de la perte totale de données, et il peut le faire automatiquement. Il s'agit d'une
avancée très significative en matière de sécurité du stockage de masse par rapport à PC-DOS, où
la corruption d'une piste de répertoire peut conduire à des sauts depuis des immeubles élevés.
Les seules pénalités payées, en contrepartie de tous les avantages, sont que la liste des répertoires
et le renommage des fichiers sont plus lents que dans les systèmes conventionnels, parce qu'il n'y
a pas un seul endroit où aller pour chercher les noms de fichiers ; toute l'arborescence doit être
parcourue pour trouver les noms. MetaComCo envisage actuellement de mettre en cache la structure du
répertoire pour atténuer ce problème, mais d'après mon expérience limitée de l'Amiga, cela ne semble
pas trop grave de toute façon ; il n'est pas beaucoup plus lent qu'un PC IBM au moment où les vitesses
d'accès à la disquette et de mise à jour de l'écran de ce dernier ont pris le dessus.
Étant donné la nature multitâche de Tripos, et donc les moments imprévisibles des accès à la disquette,
des mesures étaient nécessaires pour gérer gracieusement les changements de disquette. En conséquence,
Tripos garde en mémoire une carte de bits de l'utilisation de la disquette - la même idée que la FAT
(file-allocation table) de sous PC-DOS - qui a un bit défini pour chaque bloc utilisé. Comme mentionné
précédemment, chaque tâche de fichier garde son propre tampon de bloc en mémoire. Après l'activité de la
disquette (signalée par la lumière rouge habituelle), il y a une période de trois secondes, après
laquelle la tâche vide automatiquement ses tampons et la carte de bits mise à jour sur la disquette.
Si une disquette est retirée pendant la période de temps mort, la carte de bits sur la disquette sera marquée
comme invalide, et quand cette disquette est réinsérée, une tâche de validation dans le noyau sera automatiquement
invoquée pour reconstruire la carte de bits. Amiga et MetaComCo ont longuement débattu d'un système
de verrouillage mécanique similaire à celui du Macintosh, mais ont décidé de ne pas le faire après
avoir observé l'impopularité de ce dernier (auprès de tout le monde, sauf de l'industrie des coupes-papiers,
bien sûr).
Tripos sait tout sur les volumes de disquette et peut trouver un volume dans n'importe quel lecteur ou
demander qu'elle soit insérée selon les besoins ; pas besoin de s'embêter avec les lecteurs par défaut
ou de se connecter. Il est en fait possible de retirer une disquette avec un fichier encore ouvert, d'utiliser
une nouvelle disquette, puis d'être invité par le système à remplacer la première disquette et de continuer.
Comme sous Unix, tous les périphériques sont adressés comme des fichiers, avec un nom de périphérique remplaçant
le nom de volume qui serait utilisé dans une spécification de fichier complet. Le périphérique logique
CON: peut être associé à des paramètres de taille de fenêtre, par exemple avec "CON:20/20/100/100/Fred",
qui adresse une fenêtre de 80 caractères sur 80 appelée Fred. Le port série et l'imprimante peuvent être
adressés de manière similaire.
Conclusion
La relation entre MetaComCo et Commodore-Amiga semble avoir été mutuellement bénéfique. L'Amiga s'est
doté d'un système d'exploitation mature et performant, conçu sur des principes sains, bien que non
conservateurs. MetaComCo, de son côté, a obtenu un ancrage plus fort aux États-Unis, ainsi que le
respect de ceux dans l'industrie informatique américaine qui étaient déjà au courant de son existence.
La question de savoir si l'Amiga sera ou non l'acteur mondial qu'il mérite d'être reste la grande question
de l'année. Bien que certains problèmes de démarrage apparaissent, il est probable qu'ils seront moins
graves qu'ils ne l'auraient été si un système d'exploitation totalement inédit avait été adopté.
Je pense depuis un certain temps que les utilisateurs ne sont pas suffisamment conscients de la complexité
des systèmes d'exploitation de nouvelle génération, post-Macintosh. L'époque du "rafistolage et de l'espoir"
est définitivement révolue, et nous sommes maintenant dans le territoire de l'ingénierie logicielle lourde ;
le débogage doit maintenant être considéré comme un processus continu, et les chances d'avoir un système
d'exploitation exempt de bogues au lancement (ou même un an plus tard) sont assez minces. Commodore-Amiga
est toujours en train de débattre pour savoir s'il faut ou non mettre AmigaDOS en ROM à la manière des
Macintosh (les premières machines sont livrées avec un DOS sur disquette). Tim King est fermement en
faveur du maintien d'un DOS sur disquette, précisément pour ces raisons.
Quant aux projets futurs de MetaComCo, la société se contente pour l'instant de rester sur 68000, un
processeur dans lequel l'expertise accumulée par la société porte ses fruits. L'Atari 520ST a attiré
l'attention de MetaComCo, et son personnel y a déjà installé la combinaison assembleur/éditeur, bientôt
suivie par Pascal et Lattice C. Un système de développement basé sur IBM PC, avec assembleur croisé,
vient également d'être annoncé. La relation avec Lattice est née lorsqu'elle a été chargée d'installer
le compilateur sur le Sinclair QL ; MetaComCo a fini par le commercialiser.
MetaComCo entretient toujours des liens étroits avec les universités de Cambridge et de Bath (Tim
King donne toujours un cours d'informatique à Bath) et leur verse des redevances pour des travaux
tels que le noyau Tripos original. Elle illustre la tendance lente mais bienvenue vers une collaboration
fructueuse entre le monde universitaire et le monde des affaires, qui est nouvelle au Royaume-Uni,
bien qu'elle soit une pratique courante sur les campus américains depuis le début de la révolution
microélectronique.
Note : Dick Pountain est un auteur technique et un consultant en logiciels vivant à
Londres. Angleterre. Il peut être contacté à Byte, POB 372, Hancock, NH 03449.
|
