Obligement - L'Amiga au maximum

Vendredi 29 mars 2024 - 07:28  

Translate

En De Nl Nl
Es Pt It Nl


Rubriques

Actualité (récente)
Actualité (archive)
Comparatifs
Dossiers
Entrevues
Matériel (tests)
Matériel (bidouilles)
Points de vue
En pratique
Programmation
Reportages
Quizz
Tests de jeux
Tests de logiciels
Tests de compilations
Trucs et astuces
Articles divers

Articles in english


Réseaux sociaux

Suivez-nous sur X




Liste des jeux Amiga

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


Trucs et astuces

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


Glossaire

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


Galeries

Menu des galeries

BD d'Amiga Spécial
Caricatures Dudai
Caricatures Jet d'ail
Diagrammes de Jay Miner
Images insolites
Fin de jeux (de A à E)
Fin de Jeux (de F à O)
Fin de jeux (de P à Z)
Galerie de Mike Dafunk
Logos d'Obligement
Pubs pour matériels
Systèmes d'exploitation
Trombinoscope Alchimie 7
Vidéos


Téléchargement

Documents
Jeux
Logiciels
Magazines
Divers


Liens

Associations
Jeux
Logiciels
Matériel
Magazines et médias
Pages personnelles
Réparateurs
Revendeurs
Scène démo
Sites de téléchargement
Divers


Partenaires

Annuaire Amiga

Amedia Computer

Relec


A Propos

A propos d'Obligement

A Propos


Contact

David Brunet

Courriel

 


En pratique : Le Shell et le multitâche
(Article écrit par Pierre Ardichvili et extrait d'A-News (Amiga News) - décembre 1989)


Notre exploration d'aujourd'hui va nous donner, ceci dit sans l'ombre de la moindre trace de sectarisme, une raison de plus d'être satisfaits d'avoir choisi l'Amiga, laquelle bécane, fût-elle un "simple" Amiga 500, nous offre à un prix incroyablement bas des possibilités que l'on ne trouve que sur des machines considérablement plus chères.

Rappel sur le multitâche

L'Amiga est en effet capable de fonctionner en multitâche. Kekseksa ? Cela veut dire qu'il est capable d'exécuter simultanément plusieurs tâches à la fois, du moins en apparence, car en fait - mais ceci est vrai même sur les mini-ordinateurs, les stations de travail et beaucoup de machines moyennes et grosses - il va distribuer le temps disponible de son processeur en profitant de ce que l'exécution de certaines phases de certaines tâches lui laissent une paix royale.

Prenons un exemple : lorsque je tape au clavier, j'envoie à la machine quelques signaux par seconde (cela pourrait être quelques dizaines, ce serait toujours très lent). Chaque fois que je frappe une touche, le microprocesseur reconnaît la touche frappée, identifie le caractère, détermine ses coordonnées, l'ajoute au texte, l'envoie à l'écran, puis avance le curseur d'un cran. Mais tout ceci ne lui prend que très peu de temps, je ne sais pas précisément combien, mais au pire ça ne dépasse pas quelques millième de seconde. En plus, comme l'Amiga a un coprocesseur graphique, le processeur principal est même déchargé d'une partie de ce travail. Alors, le reste du temps, ce processeur principal est disponible et attend qu'on lui donne quelque chose à faire.

Un ordinateur multitâche contient donc un système de gestion des tâches qui lui permet, pendant les temps libres de l'exécution d'une tâche, d'aller voir s'il ne peut pas faire avancer les autres. Comment il le fait n'entre absolument pas dans le cadre de cette série d'articles.

Deux ou trois remarques toutefois :

1. Un PC, fût-il de type AT, est monotâche. Ce n'est pas parce qu'on peut ouvrir plusieurs fenêtres sous Windows par exemple, que les programmes correspondants à ces fenêtres tournent en même temps. Il sont tous en attente, seul tourne celui dont la fenêtre est activée. Ce n'est pas non plus parce qu'un peut faire certaines choses pendant que l'imprimante fonctionne, que l'on fait du multitâche ; il se fait que certaines imprimantes ont une mémoire tampon de bonne taille (par exemple une DeskJet peut avoir 128 ko de mémoire interne) ; si le document à imprimer y entre en entier, le système peut reprendre la main immédiatement, tandis que l'imprimante travaillera encore plusieurs minutes. Pour qu'un PC tourne en multitâche, il faut qu'il puisse fonctionner sous Unix par exemple.

2. La plupart des jeux commerciaux ne fonctionnent pas en multitâche, pour la raison qu'il s'agit généralement de "portages" sur l'Amiga de programmes écrits pour des machines monotâches. Pour qu'un programme soit exécutable en multitâche, il faut, lorsqu'on l'appelle, qu'il puisse aller se charger en mémoire là où il y a de la place, et l'emplacement libre dépend de ce qui tourne sur la machine au moment où on appelle le programme. Un programme fait pour une machine monotâche va toujours se loger au même endroit de la mémoire, cela simplifie grandement les problèmes d'adressage et la programmation.

C'est pourquoi la plupart des programmes de jeux commerciaux obligent à redémarrer la machine. Dans le cas d'une machine monotâche, c'est un mal indispensable ; dans le cas d'une machine multitâche comme l'Amiga, c'est irritant. Le contraste est flagrant avec la plupart des jeux du domaine public, souvent moins impressionnants au niveau du graphisme, mais écrits par des gens qui connaissent la machine, et qui savent faire le ménage en mémoire quand on quitte le jeu. On peut faire un Tiles ou un Tetrix pendant que ça télécharge par exemple. Il faut dire que les jeux à animation rapide s'accommodent par définition mal d'un partage du temps du processeur, l'animation devenant saccadée.

3. Un système multitâche utilise le temps disponible au cours de l'exécution d'une tâche pour s'occuper d'une autre, encore faut-il qu'il y ait du temps libre. Un programme de calcul d'image (Mandelbrot ou lancer de rayons), fait mouliner le processeur à plein-temps. Il faut donc qu'il y ait un système de gestion des priorités qui évite l'accaparement de la machine par un programme goulu. Lorsque deux tâches ont la même priorité, AmigaDOS partage le temps du processeur entre les deux tâches.

4. Enfin, plus il y a de tâches en fonctionnement en même temps, plus le temps de réponse s'allonge, et plus chacune d'elles semble d'exécuter lentement. Il en va exactement de même sur les ordinateurs de gestion dans les entreprises, il y a des heures où tout le monde travaille et auxquelles le système ne répond que très lentement. C'est pourquoi les tâches très intensives en occupation de l'unité centrale sont effectuées la nuit. Sur l'Amiga, c'est la même chose, la plupart des images en trois dimensions et multicolores seront calculées la nuit, où à tout autre moment où l'heureux propriétaire de la machine en est séparé.

Multitâche et le Shell

Comme d'habitude, je suppose que nous ne disposons "que" d'un Amiga avec un seul lecteur de disquette et sans disque dur. Pas d'imprimante non plus, nous ne sommes que 52,15% à en avoir une (source de cette information : enquête publiée par Commodore Revue). Nous démarrons le système avec notre copie de travail de la disquette Workbench 1.3, nous cliquons dans l'icône du Shell, et nous voilà chez nous.

Commençons par copier la commande Copy en mémoire :

1.WB1.3> copy c:copy ram:

Insérons la disquette "Extras", et faisons :

1.WB1.3> ram:copy df0:tools/perfmon ram:
1.WB1.3> ram:copy df0:tools/palette ram:

Remettons notre disquette WB1.3 dans le lecteur. Faisons :

1.WB1.3> newshell

Réduisons un peu la hauteur de nos deux fenêtres, plaçons-les l'une au-dessus de l'autre, puis appellons-en une troisième en retapant "newshell".

Plaçons-la dans le bas de l'écran. Cliquons dans la première fenêtre, et faisons :

1.WB1.3> ram:perfmon

Dans PerfMon, il y a un menu, choisissons un intervalle de 0,5 seconde, puis ajustons la taille et la place de la fenêtre à notre meilleure convenance. Dans la moitié du haut, une courbe nous donne le temps libre du processeur ("idle" signifie inactif, c'est aussi le terme qui désigne le ralenti d'un moteur). Laissons les choses se calmer, et comme le processeur n'a plus rien à faire (sur l'Amiga, le rafraîchissement de l'écran est fait par un coprocesseur), la courbe est plate et dans le haut de la fenêtre. Dans la moitié du bas, nous voyons la mémoire Chip disponible ; c'est celle qui est accessible directement par le coprocesseur graphique ; un chiffre en bas nous indique ce qui reste de mémoire normale, dite Fast.

Ce n'est pas parce que j'ai dit, et nous le vérifierons encore cette fois, que PerfMon est un programme "mal élevé" qu'il n'est pas utile ; il est même très intéressant.

Cliquons dans la deuxième fenêtre Shell et faisons :

2.WB1.3> ram:palette

Nous voyons apparaître une charmante lucarne avec des curseurs qui nous permettent de changer à volonté les couleurs de l'écran. Remarquons qu'à présent, nous pouvons taper ce que nous voulons dans une des deux premières fenêtres Shell, sans aucun effet. Ces fenêtres sont bloquées par le programme qu'elles ont lancé.

Cliquons dans la fenêtre 3 et, pour avoir quelque chose qui mette un peu de temps à s'exécuter, tapons :

3.WB1.3> dir df0: opt a

Observons grâce à PerfMon ce qui se passe : la troisième tâche sollicite un peu le processeur ; PerfMon ne consomme pas beaucoup de temps, puisqu'il fait deux mesures à la seconde ; quant à Palette, il ne consomme rien tant qu'on ne touche pas aux curseurs.

Shell

La tâche 3 étant finie, relançons-la, puis attrapons avec la souris le curseur de la composante bleue dans Palette et déplaçons-le constamment de droite à gauche et de gauche à droite, sur toute sa course.

D'un oeil, observons sur PerfMon l'augmentation de l'occupation du processeur, de l'autre l'impact de ces manipulations sur la vitesse d'exécution de la tâche n°3.

Les priorités

Tant que nous y sommes, jouons avec les priorités. Nos trois Shell ont été ouverts avec la priorité par défaut, qui est 0. Les priorités peuvent être fixées entre -128 et +127, par la commande "Changetaskpri". Dans notre fenêtre 3, faisons :

3.WB1.3> cd c
3.WB1.3:c> dir

Et pendant que la commande s'exécute, balançons comme précédemment un curseur dans Palette. Nous observons deux phases de fonctionnement : tant que le système lit le contenu du répertoire "c" sur le disque, le changement de couleur de l'écran suit instantanément le mouvement de la souris. Ceci parce que l'accès au disque est en partie l'affaire d'un des coprocesseurs de l'Amiga, et le processeur principal a du temps pour exécuter les ordres reçus de Palette et en plus, deux fois par seconde, faire une mesure avec PerfMon, dès que l'accès disque est terminé, on voit immédiatement que le changement de couleur se fait par saccades, de même que l'affichage dans la troisième fenêtre Shell. Il y a partage équitable entre les tâches.

Faisons maintenant, dans la troisième fenêtre :

3.WB1.3:c> changetaskpri 2

Et recommençons la manipulation. Cette fois, nous constatons que Palette et PerfMon sont bloqués pendant toute la durée de l'affichage du contenu de "c", qui s'effectue, lui, à vitesse normale. Incidemment, PerfMon est lancé d'office avec une priorité de -100, pour ne gêner personne. Si nous souhaitions rédiger un texte pendant que le système calcule une image, sans être gêné dans notre vitesse de frappe, nous donnerions à la fenêtre à partir de laquelle nous avons lancé notre traitement de texte une priorité 2 par exemple. De cette manière, nous ne nous apercevrons absolument pas de l'activité de l'autre programme, qui par contre se remettra à utiliser toutes les ressources du processeur chaque fois que nous irons faire pipi ou boire un Burp Fraise.

La commande Run

Bon, n'importe quel amigoïde avec un peu d'expérience du Shell va se marrer doucement en voyant nos trois fenêtres CLI, et par-dessus, les fenêtres de Palette et de PerfMon. En effet, c'est vachement encombré et ça fait désordre. Je l'entends déjà ricaner : "et la commande Run, ça sert à quoi ?". Justement, on y vient. Y a comme ça des coïncidences heureuses.

D'abord, faisons le ménage. La troisième fenêtre se ferme en faisant :

3.WB1.3:c> endshell

Comme les deux autres ne veulent rien entendre, nous cliquons dans le point en haut à gauche du cadre de PerfMon, dans OK de Palette, après quoi on peut fermer la fenêtre 2 par "endshell" et garder tout de même la fenêtre 1.

Faisons :

1.WB1.3> run ram:perfmon

Perfmon apparaît, mais nous voyons aussi :

[shell 2]
1.WB1.3>

Pas mal, nous pouvons de nouveau travailler dans notre fenêtre 1 ; PerfMon, quant à lui, est géré par une tâche Shell n°2, mais en arrière-plan, sans fenêtre. Continuons.

1.WB1.3> run ram:palette

Même chose. Tant qu'on y est :

1.WB1 3> run dir df0: opt a
[shell 4]

rien...

Puis notre affichage qui commence, mais pas question de réutiliser notre fenêtre Shell : avant que la commande "dir opt a" n'ait fini son boulot. Pourquoi ? Simplement parce qu'on ne peut pas demander à un programme de s'exécuter en arrière-plan, alors qu'il a besoin d'une fenêtre Shell pour s'exprimer ! PerfMon et Palette ouvrent leur propre fenêtre ; une commande comme "Dir" s'exécute normalement dans une fenêtre Shell. Il en aurait été autrement si nous avions fait :

1.WB1.3> dir > prt: df0: opt a

Ou, puisque nous n'avons pas d'imprimante :

1.WB1.3> dir > ram:toto df0: opt a

Nous voyons donc que nous pouvons lancer "en arrière-plan" par "Run", à partir d'une seule fenêtre Shell, toute une série de programmes qui vont fonctionner simultanément, avec les restrictions de temps de réponse dont nous avons parlé. Par exemple, si on veut jouer à Tetrix en téléchargeant, on constate que les figures tombent par saccades. On peut évidemment privilégier Tetrix, au détriment de la note de téléphone, cela dépend de la relation que l'on a avec celui qui paie la note.

Je fais le ménage, et je recommence :

1.WB1.3> run ram:perfmon
[shell 2]
1.WB1.3> endshell
shell 1 ending

Et qu'est-ce que je m'aperçois ? Plus rien ! Le Shell à partir duquel j'ai fait "Run" s'est bien refermé, mais comme il y a toujours PerfMon qui tourne sous le Shell n°2, pas moyen de fermer la fenêtre. Ça, c'est embêtant, car imaginez qu'une commande "run sys:utilities/perfmon" fasse partie de la séquence de démarrage du système : plus moyen de refermer le CLI (rappelons-nous que la séquence de démarrage part d'un CLI ouvert sans notre intervention) et donc impossibilité de faire apparaître l'écran du Workbench.

Si vous examinez le fichier startup-sequence du répertoire "s", vous verrez qu'il se termine par "loadwb" (qui charge le Workbench) et "endcli >nil" (qui referme le CLI). Il faudra donc, si nous voulons lancer au cours de notre séquence de démarrage des programmes mal élevés comme PerfMon (j'appelle mal élevés des programmes qui gardent une tâche Shell bloquée), faire autre chose.

AmigaDOS propose d'utiliser dans ce cas la syntaxe :

run >nil: nomdeprogramme

Ce qui marche dans un certain nombre de cas. L'idée est que l'unité logique NIL: se comporte comme un trou noir qui engloutit tout ce qu'on verse dedans. Si le programme avait l'idée saugrenue de vouloir encore envoyer quelque chose à la fenêtre Shell après avoir été lancé, en redirigeant cette sortie vers NIL:, on supprime le besoin de la fenêtre Shell et elle se débloque.

Si nous faisons :

WB1.3> run >nil: utilities/perfmon

...nous constatons qu'après le démarrage de PerfMon, nous pouvons refermer la fenêtre Shell par "endshell". PerfMon s'est "détaché" du Shell et fonctionne en tant qu'une tâche donnée. De ce point de vue, PerfMon n'est qu'à moitié mal élevé, car, pour des raisons relativement compliquées à expliquer, ça ne marche pas avec tous les programmes ; pour trouver une solution générale, il faudra recourir à la commande "Runback" du domaine public. On en trouve la dernière version sur Fish 214 ainsi qu'une explication remarquablement claire de Matt Dillon sur les raisons de l'échec occasionnel de la syntaxe "run >nil:".


[Retour en haut] / [Retour aux articles] [Article précédent]