Micro Systèmes n°49 janvier 1985
Micro Systèmes n°49 janvier 1985
  • Prix facial : 24 F

  • Parution : n°49 de janvier 1985

  • Périodicité : mensuel

  • Editeur : Société Parisienne d'Edition

  • Format : (203 x 271) mm

  • Nombre de pages : 198

  • Taille du fichier PDF : 137 Mo

  • Dans ce numéro : dossier sur l'ordinateur biologique.

  • Prix de vente (PDF) : gratuit

Dans ce numéro...
< Pages précédentes
Pages : 174 - 175  |  Aller à la page   OK
Pages suivantes >
174 175
LA REVUE DE PRESSE par Michel Rousseau La presse mondiale semble préoccupée  : trouvera-t-on enfin cette chimère que constituent, chacun dans leur domaine, machine universelle et langage pour tous types d'applications ? Pour la machine, une lueur pointe à l'horizon amérindien ; pour le langage, il est encore nécessaire de se faire une opinion par soi-même. Les informaticiens s'interrogent  : comment obtenir le meilleur archivage des données, que faire de l'Intelligence Artificielle, le disque optique numérique constitue-t-il l'avenir ? Et Prolog, que devient-il dans tout cela ? Le Dimension 68000  : un multicompatible Qui ne s'est pas trouvé, un jour, confronté au terrible problème de trouver exactement le logiciel qui conviendrait à une application donnée, mais, hélas, pas sur son ordinateur ? Le rêve do posséder un calculateur qui puisse fonctionner avec n'importe quel programme est presqu'aussi vieux que l'informatique. Parfois les légendes deviennent réalité, comme tendrait à le prouver Popular Computing dans son article consacré au Dimension 68000, un ordinateur qui exécute les programmes écrits pour l'IBM PC et les compatibles, ceux qui tournent sous CP/M et notamment sur le Kaypro, le Cromemco,. l'Osborne, le TRS-80 Model III, sans oublier les logiciels conçus pour l'Apple II et (bientôt) tous ceux qui tournent sous Unix. De plus, le Dimension possède son propre Basic ainsi qu'un compilateurC, et s'enorgueillit d'un CP/M 68K spécialement écrit pour le microprocesseur 68000 qui l'équipe. Cela semble trop beau pour être vrai, et pourtant cela fonctionne mais pose parfois quelques petits problèmes, notamment quant à la rapidité d'exécution des programmes et à leur parfaite intégrité. Physiquement, le Dimension 68000 ressemble extérieurement à un PC. A l'intérieur, on découvre une carte principale configurée autour d'un M68000 et disposant de six slots pour recevoir les cartes portant les coprocesseurs ou les mémoires additionnelles. La configuration standard, qui coûte la bagatelle de 3 900 $, comprend 256 Ko de RAM, une sortie RS 232, une sortie parallèle, une sortie joystick et la haute résolution. De plus, le fabricant Micro Craft propose trois cartes- coprocesseurs, une carte 8086 pour la compatibilité IBM, une carte Z 80 supportant le CP/M 2.2, et une carte 6512 pour l'Apple. Seul ennui, il n'est pas possible d'émuler l'Apple tournant sous CP/M, des problèmes ayant surgi au niveau des adressages de la carte 80 colonnes. Mais le plus extraordinaire dans tout cela, ce n'est pas que cela marche parfaitement bien, c'est tout simplement que cela marche ! Comment donc, au juste ? L'émulation ne signifie pas obligatoirement la copie. L'approche de la compatibilité menée par le Dimension diffère substantiellement de celle proposée par les compatibles PC. Généralement, ceux-ci sont des clones du matériel originel. Ils suivent les plans du PC d'aussi près que possible. Pour émuler un ordinateur plutôt que de le copier, on dispose de deux solutions  : soit on met tout dans le hardware, ce qui signifie la construction d'un système qui fonctionne presque de la même manière que l'ordinateur cible, soit on réalise un programme qui fait se comporter la machine-hôte de la même façon que celle du calculateur imité. En ce qui concerne la première approche, tout ce que vous pouvez utiliser de l'hôte est son clavier, son moniteur et ses drives. Un émulateur hardware possède généralement son propre processeur et des circuits logiques qui diffèrent de ceux de l'émulé. En général, il nécessite aussi sa propre RAM. L'émulateur devient un ordinateur à l'intérieur d'un autre ordinateur. Comment cela fonctionne-t-il ? Prenons le cas de la lecture d'un programme sur disque. L'hôte va d'abord convertir le format du disque, traduire ensuite les adresses mémoire, puis charger le programme reconverti dans sa propre mémoire. Qui plus est, il doit effectuer tout ceci rapidement s'il ne veut pas se retrouver dépassé par les informations en provenance du disque. Il est nécessaire de traduire les adresses mémoire, puisque même les ordinateurs utilisant le même processeur n'adressent pas leur mémoire de façon identique. Par exemple, le bloc d'adresses mémoire de l'écran diffère presque toujours d'un ordinateur à l'autre. Pour résoudre ce problème, on peut rajouter de la RAM, mais c'est une solution d'autant plus coûteuse qu'il y a souvent des « pailles » dans le système, dont la recherche coûte encore plus cher ! La solution logicielle est une alternative intéressante, mais qui comporte ses propres contraintes. Ici, la machine hôte agira comme l'appareil émulé. C'est ainsi que l'IBM 370 exécute des programmes écrits pour le 1401. Chaque instruction et chaque adresse du programme doivent être traduites deux fois, une première fois dans le langage de la machine cible, et une deuxième dans celui de l'hôte. Les problèmes se multiplient lorsqu'on a affaire à des processeurs qui « pensent » de façon radicalement différente. De plus, l'émulation devient un vain mot lorsque les programmes font appel 174 — MICRO-SYSTEMES Janvier 1985
par souci de performance à des particularités d'une machine. Le Dimension se tire d'affaire en fonctionnant de manière hybride  : il nécessite en fait 512 Ko de RAM pour émuler de façon correcte. Le 68000 se charge principalement des entrées/sorties telles que l'affichage écran et la lecture disque. Dès que l'émulateur reconnaît des instructions spécifiques à un processeur, il transmet celles-ci au coprocesseur approprié. Après quelques essais, on s'aperçoit que tournent sans grand problème des logiciels tels que Flight Simulator ou Lotus 1.2.3. Le seul point noir reste la vitesse d'exécution desdits programmes. Un tout dernier mot d'un problème non encore résolu  : les instructions propres à la machine cible qui ne trouvent pas leur équivalent sur l'hôte perturbent un peu le programme. Mais au dire du constructeur, ceci est en passe d'être résolu. Unix à la une Bientôt Unix sur le Décision V, Xenix sur l'A.T., décidément ce système d'exploitation récolte tous les suffrages. C'est aussi ce que semble penser notre homonyme américain, Microsystems, qui lui consacre une bonne part de son numéro d'octobre. Vous y trouverez, entre autres articles, une interview des pères du système, Dennis Ritchie et Ken Thompson, ainsi que l'histoire d'Unix. Nous ne résistons pas au plaisir de vous en donner de courts extraits. Unix, les débuts. Contrairement à ce que l'on raconte, Unix n'est pas né en 1974, mais en 1969. C'est en grande partie suite au déclin de Multics, un système multi-users dont le prix s'avèra exorbitant, que le groupe de départ (K. Thompson, Ritchie, M. D. Mclllroy et J.-F. Osanna) décida de construire un système d'exploitation qui permette un certain échange entre ses utilisateurs. Les premiers essais furent plutôt frustrants  : comme le dit D. Ritchie, « rétrospectivement, on ne peut pas en vouloir aux Bell's Laboratories de ne pas avoir voulu investir dans un projet trop fumeux, qui aurait concerné trop peu de gens et qui aurait coûté trop cher ! » En réalité, c'est grâce à un jeu développé par Thompson qu'Unix devait voir le jour. « Space Travel », d'abord écrit sous Multics, fut ensuite traduit en Fortran pour le Gecos (les.e. du GE qui devait devenir plus tard l'Honeywell 635). Ce n'était rien moins qu'une simulation des principaux corps célestes du système solaire, entre lesquels le joueur déplaçait son vaisseau et sur lesquels il essayait d'atterrir. Mais la version Gecos présentait deux inconvénients majeurs  : un affichage sautillant et un prix de l'heure de jeu de 75 $ ! Aussi Ritchie et Thompson réécrirent-ils tout le système sur un Graphic II. Cette tâche allait s'avérer plus importante que le jeu luimême. Dédaignant le logiciel existant, les programmeurs décidèrent d'écrire leur propre arithmétique en virgule flottante, une spécification point à point des caractères graphiques et un sous-système de debugging qui affichait le contenu des localisations dans un coin de l'écran. En vérité, Space Travel préparait à la programmation sur PDP-7. Partant de là, Thompson décida d'implémenter le système de fichier calque qu'il avait précédemment développé pour Multics. Tout ceci nécessitait de repenser le système d'exploitation. Celui-ci devait autoriser la copie, l'impression et l'effacement de fichiers, ainsi que leur édition, sans parler bien entendu d'un noyau interpréteur. Tous ces programmes furent écrits sous Gecos, et les fichiers furent transférés sur bandes perforées vers le PDP-7. Bien que l'on ne fût pas encore en 1970, Brian Kernighan, qui avait rejoint le groupe, suggéra d'appeler ce système « Unix ». Le système d'exploitation que nous connaissons aujourd'hui était né. Unix sur le PDP-7. Le système de fichiers du PDP-7 était presqu'identique à celui d'aujourd'hui. Il disposait  : 1. D'une liste-i  : un arrangement linéaire de noeuds-i, chacun décrivant un fichier. Un noeud contenait moins d'infos qu'aujourd'hui, mais l'information de base était la même ; à savoir le mode de protection du fichier, son type et sa taille, et la liste des blocs physiques contenant les données. 2. Des répertoires  : un type spécial de fichier contenant une suite de noms et les numéros-i qui y étaient associés. 3. Des fichiers spéciaux décrivant des dispositifs dont la spécification n'était pas contenue explicitement dans le noeud, mais encodée dans un numéro. Les appels-fichier les plus importants étaient présents dès le départ. Read, write, open, creat, close. A une exception près, ils étaient semblables à ceux d'aujourd'hui. Les liens, dans le sens Unix du terme, existaient déjà. Grâce à un ensemble de conventions très élaborées, ils permettaient de combler l'absence de noms de chemins. L'appel de lien avait la forme suivante  : link (dir, fichier, nouveaunom) où dir était le fichier-répertoire courant, fichier l'entrée requise dans ce répertoire et nouveaunom le nom du lien, qui était ajouté au répertoire disponible. Seul problème, il n'était pas possible de créer un répertoire pendant que le système tournait. Mais l'inconvénient le plus sérieux résidait dans la très grande difficulté de modification de la configuration. Le système d'exploitation qui implantait ce système de fichier était une version hautement simpliste du système actuel. Tout d'abord, il n'était pas multiprogrammable  : la règle d'or semblait être un seul programme à chaque fois en mémoire, et le contrôle n'était transmis entre processes que s'il y avait un swap explicite. Bien qu'il existât un embryon du mécanisme de tampon (quatre pour être plus précis), il n'y avait pas de simultanéité entre les entrées/sorties disque et les calculs. Contrôle de processus. Par là, il faut entendre les mécanismes de création et d'utilisation des processus. A la différence du système de fichier, le schéma du contrôle de processus subissait de nombreux remaniements alors qu'Unix était déjà en pleine utilisation. De nos jours, la façon dont les instructions sont exécutées par le noyau peut être résumée ainsi  : 1. Le noyau lit une ligne d'instructions en provenance du terminal. 2. Il crée un processus secondaire au moyen de fork. 3. Ce processus utilise exec pour appeler l'instruction à partir d'un fichier. 4. Entre-temps, le noyau attend la fin du processus d'appel en appelant l'instruction wait. 5. Le noyau apparenté revient à la première étape. Ces processus existaient déjà sur le PDP-7• (rappelons qu'Unix n'a été réécrit en C qu'en 1974). Il n'y avait ni fork, ni wait, ni exec. La principale boucle du noyau opérait de la manière suivante  : 1. Le noyau fermait tous les fichiers et ouvrait un fichier spécial pour les entrées/sorties standard. 2. Il lisait la ligne d'instruction du terminal. 3. Il liait cette instruction au fichier, ouvrait celui-ci et enlevait le lien. Puis il copiait un petit programme de bootage en RAM-TOP et l'exécutait. Le programme lisait le fichier puis sautait à la première localisation de l'instruction. 4. L'instruction s'exécutait et se terminait en faisant appel à exit. L'intérêt de ce proto-système était d'anticiper la plupart des développements à venir. Point crucial, le noyau y était déjà considéré comme un programme-utilisateur stocké dans un fichier plutôt que d'être partie prenante du système d'exploitation. Mais le pas décisif fut franchi quand, en 1973, le noyau du système d'exploitation fut réécrit enC. Ritchie explique alors la filiation du C au travers du B, du BCPL et du TMG de McClure. Si vous voulez en savoir plus, reportez-vous au numéro d'octobre de Microsystems. A lire absolument ! Kamas, un Forth « Canada Dry » Puisque nous en sommes aux langages, jetons un coup d'oeil sur le numéro de septembre de Byte, qui nous propose une étude préliminaire d'un nou- Janvier 1985 MICRO-SYSTEMES — 175



Autres parutions de ce magazine  voir tous les numéros


Liens vers cette page
Couverture seule :


Couverture avec texte parution au-dessus :


Couverture avec texte parution en dessous :


Micro Systèmes numéro 49 janvier 1985 Page 1Micro Systèmes numéro 49 janvier 1985 Page 2-3Micro Systèmes numéro 49 janvier 1985 Page 4-5Micro Systèmes numéro 49 janvier 1985 Page 6-7Micro Systèmes numéro 49 janvier 1985 Page 8-9Micro Systèmes numéro 49 janvier 1985 Page 10-11Micro Systèmes numéro 49 janvier 1985 Page 12-13Micro Systèmes numéro 49 janvier 1985 Page 14-15Micro Systèmes numéro 49 janvier 1985 Page 16-17Micro Systèmes numéro 49 janvier 1985 Page 18-19Micro Systèmes numéro 49 janvier 1985 Page 20-21Micro Systèmes numéro 49 janvier 1985 Page 22-23Micro Systèmes numéro 49 janvier 1985 Page 24-25Micro Systèmes numéro 49 janvier 1985 Page 26-27Micro Systèmes numéro 49 janvier 1985 Page 28-29Micro Systèmes numéro 49 janvier 1985 Page 30-31Micro Systèmes numéro 49 janvier 1985 Page 32-33Micro Systèmes numéro 49 janvier 1985 Page 34-35Micro Systèmes numéro 49 janvier 1985 Page 36-37Micro Systèmes numéro 49 janvier 1985 Page 38-39Micro Systèmes numéro 49 janvier 1985 Page 40-41Micro Systèmes numéro 49 janvier 1985 Page 42-43Micro Systèmes numéro 49 janvier 1985 Page 44-45Micro Systèmes numéro 49 janvier 1985 Page 46-47Micro Systèmes numéro 49 janvier 1985 Page 48-49Micro Systèmes numéro 49 janvier 1985 Page 50-51Micro Systèmes numéro 49 janvier 1985 Page 52-53Micro Systèmes numéro 49 janvier 1985 Page 54-55Micro Systèmes numéro 49 janvier 1985 Page 56-57Micro Systèmes numéro 49 janvier 1985 Page 58-59Micro Systèmes numéro 49 janvier 1985 Page 60-61Micro Systèmes numéro 49 janvier 1985 Page 62-63Micro Systèmes numéro 49 janvier 1985 Page 64-65Micro Systèmes numéro 49 janvier 1985 Page 66-67Micro Systèmes numéro 49 janvier 1985 Page 68-69Micro Systèmes numéro 49 janvier 1985 Page 70-71Micro Systèmes numéro 49 janvier 1985 Page 72-73Micro Systèmes numéro 49 janvier 1985 Page 74-75Micro Systèmes numéro 49 janvier 1985 Page 76-77Micro Systèmes numéro 49 janvier 1985 Page 78-79Micro Systèmes numéro 49 janvier 1985 Page 80-81Micro Systèmes numéro 49 janvier 1985 Page 82-83Micro Systèmes numéro 49 janvier 1985 Page 84-85Micro Systèmes numéro 49 janvier 1985 Page 86-87Micro Systèmes numéro 49 janvier 1985 Page 88-89Micro Systèmes numéro 49 janvier 1985 Page 90-91Micro Systèmes numéro 49 janvier 1985 Page 92-93Micro Systèmes numéro 49 janvier 1985 Page 94-95Micro Systèmes numéro 49 janvier 1985 Page 96-97Micro Systèmes numéro 49 janvier 1985 Page 98-99Micro Systèmes numéro 49 janvier 1985 Page 100-101Micro Systèmes numéro 49 janvier 1985 Page 102-103Micro Systèmes numéro 49 janvier 1985 Page 104-105Micro Systèmes numéro 49 janvier 1985 Page 106-107Micro Systèmes numéro 49 janvier 1985 Page 108-109Micro Systèmes numéro 49 janvier 1985 Page 110-111Micro Systèmes numéro 49 janvier 1985 Page 112-113Micro Systèmes numéro 49 janvier 1985 Page 114-115Micro Systèmes numéro 49 janvier 1985 Page 116-117Micro Systèmes numéro 49 janvier 1985 Page 118-119Micro Systèmes numéro 49 janvier 1985 Page 120-121Micro Systèmes numéro 49 janvier 1985 Page 122-123Micro Systèmes numéro 49 janvier 1985 Page 124-125Micro Systèmes numéro 49 janvier 1985 Page 126-127Micro Systèmes numéro 49 janvier 1985 Page 128-129Micro Systèmes numéro 49 janvier 1985 Page 130-131Micro Systèmes numéro 49 janvier 1985 Page 132-133Micro Systèmes numéro 49 janvier 1985 Page 134-135Micro Systèmes numéro 49 janvier 1985 Page 136-137Micro Systèmes numéro 49 janvier 1985 Page 138-139Micro Systèmes numéro 49 janvier 1985 Page 140-141Micro Systèmes numéro 49 janvier 1985 Page 142-143Micro Systèmes numéro 49 janvier 1985 Page 144-145Micro Systèmes numéro 49 janvier 1985 Page 146-147Micro Systèmes numéro 49 janvier 1985 Page 148-149Micro Systèmes numéro 49 janvier 1985 Page 150-151Micro Systèmes numéro 49 janvier 1985 Page 152-153Micro Systèmes numéro 49 janvier 1985 Page 154-155Micro Systèmes numéro 49 janvier 1985 Page 156-157Micro Systèmes numéro 49 janvier 1985 Page 158-159Micro Systèmes numéro 49 janvier 1985 Page 160-161Micro Systèmes numéro 49 janvier 1985 Page 162-163Micro Systèmes numéro 49 janvier 1985 Page 164-165Micro Systèmes numéro 49 janvier 1985 Page 166-167Micro Systèmes numéro 49 janvier 1985 Page 168-169Micro Systèmes numéro 49 janvier 1985 Page 170-171Micro Systèmes numéro 49 janvier 1985 Page 172-173Micro Systèmes numéro 49 janvier 1985 Page 174-175Micro Systèmes numéro 49 janvier 1985 Page 176-177Micro Systèmes numéro 49 janvier 1985 Page 178-179Micro Systèmes numéro 49 janvier 1985 Page 180-181Micro Systèmes numéro 49 janvier 1985 Page 182-183Micro Systèmes numéro 49 janvier 1985 Page 184-185Micro Systèmes numéro 49 janvier 1985 Page 186-187Micro Systèmes numéro 49 janvier 1985 Page 188-189Micro Systèmes numéro 49 janvier 1985 Page 190-191Micro Systèmes numéro 49 janvier 1985 Page 192-193Micro Systèmes numéro 49 janvier 1985 Page 194-195Micro Systèmes numéro 49 janvier 1985 Page 196-197Micro Systèmes numéro 49 janvier 1985 Page 198