 |
Jeudi 18 avril 2024 - 17:54 |
| Translate |
|
| Rubriques |
| Réseaux sociaux |
|
| Liste des jeux Amiga |
|
| Trucs et astuces |
|
| Glossaire |
|
| Galeries |
|
| Téléchargement |
|
| Liens |
|
| Partenaires |
|
| A Propos |
|
| Contact |
|
|
|
Après quelques mois d'absence (les membres d'ATP vieillissent...), cette série d'articles reprend du service et se rend ce mois-ci au CERN, le Centre Européen pour la Recherche Nucléaire, de réputation mondiale. Nous y découvrirons des Amiga au coeur de certaines expérimentations, là où les exigences techniques le rendent indispensable. Le type de développement effectué nous permettra au passage d'aborder la gestion des extensions par la machine.
Présentation des lieux
Créé dans l'immédiat après guerre, le CERN, dont le siège est à Genève, s'attache à découvrir les structures fines de la matière. Il dispose pour ce faire d'un accélérateur de particules de dizaines de kilomètres de diamètre (il ferait presque le tour de Paris), enterré à cheval sur la France et la Suisse, appelé le LEP (Large Electron-Positron collider).
Le tracé du LEP
Dans le cas du LEP, on étudie les sous-produits de la collision frontale d'électrons et d'anti-électrons, à des énergies (des vitesses) qui nous ramènent aux premiers instants de l'univers. Cette remarque me permet de rappeler que la recherche des structures de la matière rejoint aujourd'hui la recherche des origines de l'univers, la cosmologie. Celle-ci repose en effet essentiellement sur l'étude des premiers millièmes de seconde de l'univers, où l'énergie se condense progressivement pour constituer successivement les premières structures, qui conduiront à la nucléosynthèse après dissipation de quelques milliards de degrés, quelques minutes plus tard. L'énergie des collisions produites dans les grands collisionneurs permet de se rapprocher de ces conditions initiales.
Mais je ne peux m'empêcher à ce stade de citer littéralement notre contact au CERN (qui y a travaillé pendant toute la phase d'élaboration du LEP, soit jusqu'à fin 1992), Milan Zofka (j'ai d'ailleurs abondamment puisé dans ses écrits pour réaliser cet article) :
"Il y a dans la communauté scientifique une catégorie bien particulière de chercheurs, les physiciens. Toujours en quête de l'inconnu, le physicien explore les lois naturelles qui l'entourent et cherche à comprendre les mécanismes qui les régissent."
"Mais la physique est un vaste domaine, et de l'infiniment petit il y a un fossé avec l'infiniment grand. Au fait, ce fossé est-il si grand que ça ? Les spécialistes de l'infiniment petit tendent à démontrer que notre infiniment grand est né de notre infiniment petit. Et, pour le prouver, ils construisent dans d'immenses proportions des machines qui domestiquent de minuscules petites choses."
"Partant de ce petit rien, ils ont oeuvré des années durant et ont finalement construit la plus grande machine jamais créée, une gigantesque machine de 27 kilomètres de long représentant l'équivalent de milliers d'années de travail dans des domaines des plus variés."
Ces collisions sont produites en quatre zones de l'anneau, où l'on traque et étudie les milliers de petites traces qui signent le passage plus ou moins fugace de chacun des nombreux fragments de l'annihilation électron-positron (c'est à se demander d'ailleurs si le terme d'annihilation est bien choisi !). Chacune des quatre zones est donc occupée par un détecteur, truffé (le mot est faible) de capteurs de toutes espèces et de toutes tailles. Dans la zone dédiée à l'expérience L3, le détecteur pèse au total 8000 tonnes (soit 200 semi-remorques chargées), pour 16 mètres de diamètre (soit six étages). Il nourrit en données 600 chercheurs, 34 Universités et laboratoires du monde entier ont participé à sa mise au point, huit années durant.
Squelette du détecteur L3
Schéma d'un détecteur
Car tous ces traitements se font bien sûr à l'aide d'ordinateurs, via énormément d'électronique. Mais ce n'est pas tant la puissance de calcul qui compte ici, que la capacité à configurer et piloter des périphériques, et à traiter les résultats en temps réel. Si vous êtes lecteur assidu de cette série d'articles depuis, l'origine, ces caractéristiques évoquent pour vous quelque chose, et vous avez raison : dans cette fameuse expérience L3, à l'un des quatre pôles de l'anneau, une des parties de la chaîne d'acquisition est pilotée par un Amiga, qui est donc utilisé à chaque fois que la machine LEP se met en route.
Et comme lors de tous nos reportages précédents, bien que notre machine soit reconnue adéquate à posteriori, son introduction doit tout au dynamisme de quelques individus. Au CERN, c'est Milan Zofka qui a joué ce rôle du moins pour l'application qui nous intéresse aujourd'hui, car l'Amiga est présent dans d'autres laboratoires du CERN, sans qu'il n'y ait la moindre corrélation. Comme quoi les mêmes exigences conduisent parfois aux mêmes solutions...
Des ordinateurs et des cartes
Afin de suivre la trajectoire des particules qui résultent de la désintégration électron-positron, une série de sous-détecteurs enrobent en couches successives le point d'impact : au centre, tout près du lieu des collisions, on trouve d'abord une chambre à fil, puis autour un calorimètre électromagnétique, puis un calorimètre hadronique, puis des chambres à muons... (chaque type de particule connu ou présumé a une façon particulière d'interagir, et donc d'être détecté, selon sa masse, sa charge, etc.).
L'application qui nous intéresse concerne le calorimètre électromagnétique au BGO, qui est un scintillateur (le BGO est une substance cristalline ayant la propriété d'émettre des photons lorsqu'une particule la traverse). Ce capteur doit être calibré avant chaque expérience afin que l'on puisse interpréter ses réactions (et il se trouve que le mécanisme de calibration doit lui-même être calibré) : on mesure son "rendement" précis en l'exposant au rayonnement d'une source connue.
Le calorimètre électromagnétique BGO
Même si le débit n'est pas très rapide (identique à Ethernet, soit 10 Mbits/s), les conditions de temps réel contraignent fortement l'informatique. De plus, il n'est pas rare de devoir réaliser l'électronique sur place, ce qui recommande d'utiliser des ordinateurs adapter aux développeurs, notamment en ce qui concerne la gestion des extensions.
Des Vax sous VMS sont fréquemment utilisés pour ce type d'usage, mais ces systèmes sont lourds et assez onéreux (rien qu'en maintenance), de plus, la communication monopolise une baie. On trouve également des PC, à condition d'alléger considérablement les contraintes (une seule baie, avec un contrôleur spécifique).
Des Amiga étaient déjà présents dans le laboratoire lors de la construction du détecteur (comme dans beaucoup de laboratoires, ils servaient de terminaux graphiques couleur). Le petit groupe d'utilisateurs-programmeurs, connaissant leurs capacités particulièrement adaptées au problème, a donc incité à faire choisir l'Amiga pour cette tâche de pilotage, bien que cela supposait de réaliser la carte contrôleur et son logiciel d'acquisition (mais les thésards, ça coûte pas cher !). Mais jusqu'à la réalisation finale de l'ensemble, ce petit groupe a dû se battre dans le scepticisme général, performances à l'appui, pour que l'Amiga obtienne le droit d'être utilisé pour la calibration du capteur, face à la préférence ambiante pour une solution de type Vax II.
Pourquoi l'Amiga ?
Les motivations du choix de cette machine, vous en connaissez certainement quelques-unes en tant que programmeur, et si vous suivez assidûment nos reportages sur les "grands utilisateurs" qui sont souvent des laboratoires, les autres doivent maintenant vous venir à l'esprit (sinon relisez toute la série !) :
1. L'interface graphique est intégrée au système, ce qui la rend cohérente et rapide. Et comme le système, propre et modulaire, se prête particulièrement à la programmation, développer devient un plaisir ! (j'aimerais pouvoir vous parler une fois de divers grands logiciels sur d'autres machines, qui sont d'abord mis au point sur la nôtre...).
2. Le système d'exploitation est multitâche, comme Unix et VMS (qui tournent sur des machines d'un autre ordre de prix, et non sans lourdeur), de plus, il est temps réel, ce qui signifie que l'on peut maîtriser de diverses manières le déroulement des processus à un moment donné (ou à un intervalle de temps donné). Comme il est de surcroît particulièrement efficace, il ne passe pas son temps à se gérer lui-même et est apte à donner la main très vite à un processus si un signal extérieur l'exige. Encore aujourd'hui, les systèmes temps-réel sont assez rares (essayez donc de réveiller un processus à une heure précise à la milliseconde près sous Unix...).
De plus, il n'y a pratiquement pas de zones fixes en mémoire, tout développement doit donc être relogeable, ce qui augmente sa compatibilité avec les autres logiciels ou périphériques, ainsi qu'avec les versions futures du système d'exploitation.
3. C'est peu connu mais l'Amiga a une façon exemplaire de s'autoconfigurer au démarrage, ce qui évite toute commutation, zone réservée, ou conflit entre cartes. Le bus d'extension n'est d'ailleurs pas sans rappeler VME, la norme de l'électronique scientifique.
Nous donnons plus d'explications sur la gestion des extensions dans le chapitre suivant.
Rapide incursion dans le système de l'Amiga
Pour ce genre d'application système, le système d'exploitation de la machine est utilisé dans ses moindres recoins, ce qui nous donne l'occasion de faire un petit tour d'horizon des divers aspects utilisés.
Extensions et auto-configuration
Sur Amiga, ni un programme ni une carte d'extension ne doivent imposer d'adresse fixe. Les cartes sont reliées en "daisy-chain", ce qui permet au système de les interroger tour à tour à l'initialisation pour leur demander qui elles sont, quelles sont leurs exigences en mémoire (qui peut être sur la carte) et en vecteurs d'interruptions, où se trouvent leurs routines (en cas d'EPROM). etc. Le protocole s'adapte même à la taille des mots utilisés par la carte.
En échange de ces informations, le système alloue une adresse de base pour l'extension, enregistre son identité, puis lui associe plus tard un éventuel pilote stocké sur disque.
On évite ainsi tout problème de port fixe ou de commutation, ainsi qu'une bonne partie des problèmes d'incompatibilité entre cartes, et on peut alors sans autre forme de procès insérer plusieurs cartes identiques dans la machine, qui seront automatiquement différenciées (sous réserve que le pilote associé ait été écrit dans les règles de l'art !).
Multitâche et temps-réel
Pour la gestion du multitâche (préemptif, s'entend), les concepteurs de l'Amiga ont choisi un noyau temps-réel plutôt qu'un noyau superviseur : un anneau de tâches de même priorité se partagent le processeur (round robin) : si toutes sont en attentes alors la main est donnée à l'anneau de priorité inférieure (les tâches de haute priorité sont donc très réactives mais mieux vaut qu'elles ne gardent pas trop longtemps la main...). Ce mécanisme peut être momentanément gelé pour allouer tout le processeur à une tâche particulière, ou pour répondre immédiatement à une interruption du matériel (signal extérieur, chronomètre programmable, synchronisation vidéo...).
Communications
Vous le savez déjà, sur notre machine les processus dialoguent par messages, le principe étant universellement employé (il en va ainsi d'Intuition, de la console, et en fait de toutes les entrées/sorties). Ces communications peuvent être synchrones ou asynchrones selon qu'elle doive ou non attendre pour rendre la main que la commande ait été achevée.
Pour communiquer avec le matériel en évitant tout conflit inhérent au multitâche (risque d'accès concurrents), on s'adresse en fait à un processus associé à la fonctionnalité requise, un pilote. Celui-ci permet de séquencer, mémoriser ou refuser les requêtes faites à une ressource, et gère lui-même les opérations de lecture-écriture.
On peut d'ailleurs itérer ce procédé, et séparer ainsi proprement une vaste application en couches de plus ou moins haut niveau, chacune s'appuyant sur une plus basse qu'elle utilise sans se soucier des protocoles qui ne la concerne pas directement. Le débogage, la réutilisation et l'évolution en sont d'autant facilités...
Pilotes et auto-configuration
Au démarrage, les périphériques internes (ports série et parallèle, audio. etc.) se voient automatiquement affublés de leurs pilotes, stockés dans Devs:.
Les autres périphériques ont plusieurs façons d'être reliés à un point d'entrée : comme on l'a vu plus haut, une carte peut comporter une ROM, et signaler qu'il faut lancer la routine d'initialisation qui s'y trouve (romboot). D'autre part, les pilotes stockés dans Sys:Expansions sont examinés au BindDrivers, commande appelée dans le script de démarrage (mais que l'on peut relancer à tout moment, ce qui est très pratique pour la mise au point puisque l'on peut ainsi à loisir installer et désinstaller un pilote sans redémarrer la machine à tout bout de champ). Enfin, on peut utiliser la commande "Mount" que vous connaissez tous, et qui permet d'utiliser les paramètres décrits dans la liste de montage.
Bien entendu, les messages, les entrées/sorties, les bibliothèques et les interruptions sont abondamment utilisés également, mais leurs manipulations sont suffisamment classiques pour qu'il ne soit pas nécessaire de détailler davantage.
Résultats
Le prototype a été essentiellement réalisé par un doctorant en physique, secondé par un ingénieur de recherche. La carte existe maintenant en version commerciale, et constitue ainsi une interface capable de contrôler une branche CAMAC standard, permettant d'utiliser tous les modules CAMAC existants.
Le logiciel se compose des pilotes, de nombreuses bibliothèques, d'une application à interface graphique pour piloter la calibration, et d'une application jumelle à interface réseau, qui permet au gros ordinateur gérant la calibration de toute la chaîne de contrôler ce maillon via Ethernet. Et le tout est durablement installé dans le LEP !
Si CAMAC n'est plus considéré comme de la haute technologie, il rend encore bien des services, d'autant que les placards regorgent de modules de toutes sortes. Grâce à l'Amiga, on peut alors se débarrasser des gros ordinateurs poussifs et cher à maintenir, pour les remplacer par des micros modernes qui exploitent le CAMAC à son plein régime.
Partant de ce principe, plusieurs laboratoires ont adopté le fruit de ce développement, dont le SLAC (Stanford Linear ACcelerator) qui en a acquis dix exemplaires.
Le mot de la fin de Milan
La digestion d'un système d'exploitation multitâche et temps-réel n'est pas une mince affaire. En écrivant un pilote, on se heurte à tous les problèmes qui peuvent survenir dans les pires des cas. On passera sous silence les nombreuses réinitialisations, les impressions de "quelque chose de bizarre", les interruptions ininterruptibles, et autres coups du sort...
[...] Mais dans ce capharnaüm, on arrive à s'y retrouver. Mieux encore, on y prend plaisir. Noyau, interruption, messagerie interne, port de communication, lien dynamique, point d'entrée, pilote, tâche... Tous ces mots prennent un sens, s'emboîtent, correspondent, sont logiquement dépendants et deviennent clairs.
Dans cet immense labyrinthe, on élabore l'esprit de synthèse nécessaire pour maîtriser le domaine dans lequel on évolue, la programmation système. Bref, l'écriture d'un pilote n'est pas une sinécure. L'apprentissage est long puisqu'il faut rentrer dans l'intimité de la machine. Mais au bout du compte, on se rend compte que l'on a appris beaucoup de choses et que ça n'est qu'en se confrontant aux difficultés que l'on apprend "comment ça fonctionne".
[...] En écrivant un pilote pour Exec, on n'a effleuré qu'une infime partie de ses capacités. Si les professionnels de l'informatique "grand public" se donnaient la peine de consacrer du temps pour la maîtrise de l'Amiga, on aurait probablement des logiciels d'une surprenante qualité à disposition. A suivre...
Notes : Je tiens à remercier particulièrement Milan Zofka qui m'a fourni toutes ces informations, notamment via son rapport exemplaire "Étude et réalisation d'un driver CAMAC pour Amiga" dans lequel j'ai largement puisé.
|
