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
|
|
|
|
Livre : Amiga ROM Kernel Reference Manual: Devices (3e édition)
(Article écrit par Xavier Leclercq et extrait d'Amiga News - septembre 1992)
|
|
Ce deuxième volet est consacré au manuel technique (3e édition) de Commodore-Amiga, Inc.
se rapportant aux "devices" (Bruce Lepper : le premier volet était sur les
"Includes et AutoDocs").
Je vais profiter de l'occasion pour éclaircir un peu votre lanterne, si besoin est,
à propos de notions fondamentales se rapportant à ces fameux "devices" (périphériques logiques). Je vais d'abord
essayer de vous persuader d'utiliser les périphériques logiques et donc de justifier l'achat de ce volume RKRM.
Les périphériques logiques
Un périphérique logique est une interface entre le logiciel que vous concevez et le matériel
de l'Amiga. Pour illustrer par une image, établissons un parallèle entre vous, un
expert fiscal et le percepteur d'impôts. Pour payer au mieux votre contribution à
la société, vous engagez un expert fiscal qui se fait un devoir de connaître les modalités
les plus adéquates, et susceptibles d'être modifiées au cours des ans, pour assumer votre
devoir d'honnête citoyen.
Le percepteur est un homme heureux, puisqu'il reçoit dans les meilleures conditions ce qu'il
vous réclame. Pour revenir à des conceptions plus terre-à-terre, mettons à bas les masques
pour découvrir que le périphérique logique de notre jolie histoire n'est autre que l'expert fiscal
et que bien entendu le percepteur d'impôt est le matériel de l'Amiga. En effet, pour commander
une action X d'un périphérique, il faut utiliser sur l'Amiga Y une adresse en mémoire Z (qui
correspond en règle générale à un circuit dédié au périphérique). Mais l'eau ne cesse de
couler sous les ponts et un beau jour vous décidez d'acheter un Amiga Y+... Malheureusement
pour vous, l'Amiga Y+ n'emploie plus l'adresse Z pour commander le périphérique mais une
adresse Z+ ! Conséquence : votre géniale application ne fonctionne plus !
Pourtant, ce problème peut être résolu assez facilement, en déclarant à votre application de
ne pas directement commander le périphérique via l'adresse Y, mais d'adresser votre requête
au périphérique logique correspondant du périphérique. En fait, si vous écoutez ce conseil d'ami, c'est
Commodore-Amiga qui réalisera le travail de mise à jour de programmation via son interface,
c'est-à-dire le périphérique logique. Le premier point est donc d'assurer le bon fonctionnement
de la commande du périphérique, quelle que soit la version de la ROM et de l'Amiga.
Le multitâche
Le deuxième point qui doit vous motiver à programmer via les périphériques logiques est plus lié à
la nature même de l'Amiga. Ce point à lui tout seul (petit mais costaud) justifie
pour ma part à 200%, l'achat d'un Amiga plutôt qu'un #!@$? de PC : le multitâche (sans la lourdeur de
Windows).
Prenons le cas par exemple d'un programme désirant lire le bloc racine (root) d'une
disquette introduite dans le lecteur interne. Ce programme commande l'allumage du moteur,
le positionnement de la tête de lecture, et les diverses autres opérations en attaquant directement
les adresses des circuits spécialisés pilotant le lecteur interne. Et si, simultanément un
second programme veut ajouter une information au bloc racine, l'information lue par le
premier programme ne correspondra plus. Donc il est intéressant de fixer des priorités et
un système de dialogue entre le périphérique et l'application. Bref,
la programmation via le périphérique logique du périphérique répondra à tous ces critères.
Standard de programmation
Le troisième point est une question de standard de programmation. Pour réaliser des opérations
aussi différentes qu'écrire des informations sur une disquette ou jouer un échantillon sonore
via les canaux audio, la procédure à suivre sera toujours identique... L'idée est donc que la programmation
des différents périphériques logiques vous faciliteront la vie.
Mais quelle est la nature des périphériques logiques ? Réponse simple : des tâches... Il y a autant de
périphériques logiques, et donc de tâches, que de périphériques qui lui correspondent. Par exemple, il y aura trois tâches
"trackdisk.device" pour trois lecteurs de disquette branchés (l'input.device, le printer.device,
l'audio.device sont aussi des tâches ayant le type NT_DEVICE).
Votre programme en exécution est lui aussi une tâche camouflée en processus car comme il évolue dans
un environnement multitâche, il ne peut pas monopoliser tout le temps processeur.
Il peut être chargé à n'importe quel endroit de la mémoire. Nous avons donc deux "tâches" :
un périphérique logique et un processus qui peuvent se trouver n'importe où en mémoire et n'ayant, à première
vue, aucun lien entre eux. Le problème du processus est de trouver un moyen pour communiquer au
device, les actions qu'il veut commander. Et le problème du périphérique logique est de trouver un moyen de
communiquer à son tour au processus si, par exemple, la commande s'est déroulée sans problèmes.
Une "mémoire tampon commune" sera employée pour une communication bilatérale entre le processus et
le périphérique logique. Cette mémoire tampon très spéciale est connue sous le vocable "message port". Prenons
un exemple concret qui sera suivi de sa codification en C. Vous désirez fixer le pointeur de
votre souris à une position (X,Y) donnée de votre écran Workbench. Le nom du périphérique logique se chargeant du
traitement de ces événements est "l'input.device". Votre programme, "inerte" sur disquette, est
chargé à l'aide du CLI/Shell quelque part en mémoire et devient alors un processus actif.
A ce stade, ce qui différencie le processus d'une tâche, est le fait qu'un processus possède un
pointeur sur le CLI courant et peut ainsi exécuter des commandes DOS à tout moment (ce
qui est impossible à une tâche). Le processus possède une priorité, c'est-à-dire un nombre qui détermine
son classement d'ordre dans une liste. Cette liste est la liste des tâches/processus qui attendent
de passer à un état d'attente (WAIT) à un état d'exécution (RUN).
La liste est triée par un programme qui est à la base du système multitâche sur Amiga et dont on
ne parle pratiquement jamais car non référencé par les manuels techniques (y compris les ROM
Kernel). Cette procédure clé est l'ordonnanceur ("scheduler"). Vous ne vous êtes sans doute jamais posé la
question mais que fait l'Amiga quand il n'est sollicité nulle part ? Il boucle dans le noeud
d'Exec, c'est-à-dire l'ordonnanceur !
L'ordonnanceur
Il "ordonnance" ! (décalage -42 de l'exec.library). En clair, il calcule le temps d'exécution qui
sera accordé à chaque tâche suivant chaque priorité. Mais attention, le processus ne peut, même
avec une très haute priorité, dépasser un certain temps. Ce temps est le "quantum time", temps
maximum où une tâche est en état d'exécution (+/- 50ms). Il n'y a d'ailleurs toujours qu'une tâche
en mode "RUN" à la fois. Lorsque l'ordonnanceur estime qu'une tâche doit passer du mode RUN
au mode WAIT, il passera la main à une procédure de commutation de tâche ("task-switching", améliorée avec le 2.04)
qui effectuera en douceur le passage d'une tâche à l'autre (simplement en sauvegardant l'environnement,
c'est-à-dire la pile, les registres et le compteur ordinal de la tâche).
Sur Amiga, une seule adresse est toujours connue : execbase à l'adresse absolue $00000004.
Tout le reste (liste des tâches en attente, liste des ports messages) est lié inévitablement à cette adresse.
Notre processus est donc actif. Il va d'abord créer/allouer un port message, c'est-à-dire
un endroit de la mémoire qui servira de rendez-vous au processus et au périphérique logique. Puis il
préparera sa demande d'entrées/sorties dans une structure IORequest standard qui devra posséder la
référence au port message qui a été créé.
Ensuite, le lien est enfin établi en ouvrant l'input.device et en lui fournissant notre demande
d'entrées/sorties (BeginIO). Reste alors à attendre que l'input.device se manifeste via le
port message pour signifier la réalisation de la commande. Le processus se met en mode WAIT
car il attend un événement du port message (Wait-Port). Et il se "réveille" lorsque le message
en provenance du message port arrive et transmet au périphérique logique qui l'a correctement réceptionné (GetMsg).
BeginIO() et WaitPort() peuvent être remplacés par un unique DoIO() ce qui revient au même
mais est moins parlant pour mon exemple pédagogique. Reste alors à tout fermer. Remarquez que
j'utilise malloc() plutôt que la fonction d'Exec AllocMem() car cela prend moins de place et
est en norme ANSI (pas besoin d'un type de mémoire spécial non plus). Voir listing ci-dessous.
Conclusion
L'Amiga ROM Kernel Reference Manual "devices" (3e édition) est un volume de 580 pages en anglais
composé de 15 chapitres traitant des périphériques logiques suivants : Audio, ClipBoard, Console, Gameport,
Input, Keyboard, Narrator, Parallel, Printer, SCSI, Serial, Timer et Trackdisk.
Il est manifeste qu'il se révèle indispensable pour aborder le nouveau Kickstart 37.175.
La mise en garde reste qu'il est tout aussi vital de connaître le C si l'on veut progresser à
la lecture de l'ouvrage. Pour un environnement agrémenté de multitâche et de périphériques logiques,
votez pour ce ROM Kernel Manual.
Nom : Amiga ROM Kernel Reference Manual: Devices (3e édition).
Auteur : Commodore-Amiga, Inc.
Éditeur : Addison Wesley Publishing Company.
Genre : livre sur le système d'exploitation Amiga.
Date : 1991.
Prix : 490 FF.
|
|
