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
|
|
|
|
Programmation : DICE - utilisation des bibliothèques partagées
(Article écrit par Laurent Faillie et extrait d'Amiga News - juin 1994)
|
|
Les bibliothèques partageables sont à la base de tout le système d'exploitation de l'Amiga, c'est aussi l'une de ses principales
forces. En plus de celles fournies par Commodore (Exec, Dos, Graphics...), le DP permet de nous faciliter la vie (la
majorité des Shell n'existeraient pas sans l'arp.library). Choses promises, choses dues, voici l'utilisation de ces
bibliothèques avec DICE.
Chaque distribution programmeur d'une bibliothèque devrait - doit - être accompagnée des fichiers suivants :
- Fichiers de documentations,
- Fichiers includes .h (et .i pour les adeptes de l'assembleur),
- Fichiers objets dit de glue que nous verrons plus loin.
- Les fichiers fd.
powerpacker.library
Je vais commencer par le plus simple : la powerpacker.library V35.344 de la disquette Fred Fish 678.
Les fichiers includes concernant DICE sont les suivants :
- clib/powerpacker_protos.h qui contient les prototypes des fonctions,
- libraries/ppbase.h qui contient les définitions propres à la bibliothèque.
Les répertoires pragmas & proto concernent les autres compilateurs, nous les oublierons donc. DICE nous permet de
stocker ces fichiers dans un répertoire spécial nommé "pd". Ceci facilite une mise à niveau future.
Pour une installation "propre" une hiérarchie identique à celle d'Amiga 2.0 doit être créée :
Makedir Dinclude:pd/clib
Makedir Dinclude:pd/libraries
|
Le fait de faire #include <mlibraries/ppbase.h> ne suffit pas pour que le compilateur utilise les nouvelles fonctions :
il lui faut aussi un "glue-code" qui n'est en fait qu'une sorte de mode d'emploi pour le compilateur (où trouver ces fonctions,
comment leur passer des arguments...).
Pour une fois, des glues sont fournies pour DICE mais on va se dépêcher de les remplacer par les nôtres car ils ne sont pas
suffisants. Regardons dans DLIB: on voit que chaque .lib existent en plusieurs exemplaires : amigal20.lib, amigapl20.lib,
amigarl20.lib, amigarpl20.lib, amigas20.lib, amigasp20.lib, amigasr20.lib, amigasrp20.lib, par exemple en ce qui concerne
simplement la bibliothèque Amiga. Chaque version concerne un groupe d'options de DCC.
- *s.lib pour small-code,
- *p.lib pour le "profilling" (profilage),
- *r.lib pour le passages d'arguments par registres,
- Et toutes les combinaisons...
FDTOLIB permet de créer les glues codes facilement à partir des fichiers .fd, avec la possibilité que les bibliothèques soient
ouvertes et fermées automatiquement.
fdtolib /fd/powerpacker_lib.fd -o PPs.lib -auto powerpacker.library
fdtolib /fd/powerpacker_lib.fd -o PPsp.lib -prof -auto powerpacker.library
|
Les fichiers crées (PPs.lib & PPsp.lib) sont à copier dans Dlib:. N'oubliez pas de créer aussi les PPsr.lib & PPsrp.lib
si vous utilisez les passages par registres. Enfin, un -lPP permettra à DCC de lier notre glue.
Pour ceux qui utilisent DiceConfig, ajoutez :
...à la fin de dlib:diceconfig.cfg.
req.library
Passons à un peu plus difficile : la req.library. Ici, nous ne pouvons pas utiliser FDTOLIB car beaucoup
de fonctions ne sont que des macros (SimpleRequest() ne fait qu'appeler TwoGadRequest() mais en ne demandant qu'un gadget). Par
contre, des glues sont fournis pour d'autres compilateurs...
On va oublier tout de suite ceux de l'Aztec car le format de son code objet n'est pas standard. Ceux du Lattice sont
par contre parfait. Les anciennes versions serviront à ceux qui utilisent un code long (le copier en dlib:Reql.lib) alors
que les nouvelles concernent le code court (dlibs:Reqs.lib).
Le seul problème est que l'ouverture ne sera pas automatique. FDTOLIB nous permet de créer seulement ce code avec l'option
-AUTO. Ma version ne contenant pas de fichier .fd nous allons en créer un :
* Fichier Req.fd
##base _ReqBase
##bias 30
##public
##end
|
Vraiment très court ! En fait, FDTOLIB n'a besoin que de ##base _ReqBase.
fdtolib Req.fd -o req.o -AUTO req.library
join req.lib req.o dlib:req.lib
|
...va créer le glue final.
Problèmes de compatibilité avec les autres compilateurs : les fichiers includes fournis sont généralement destinés à
d'autres compilateurs ce qui nous demande quelques adaptations.
- D'abord, DICE ne gère pas les #Pragras, un #define NO_PRAGMAS suffit généralement à les éliminer.
- Plus grave : DICE met les qualificateurs devant la définition des fonctions alors que le Lattice ou l'Aztec les
mettent au milieu. Un des plus utilisés est __stdargs qui force le passage de paramètre par la pile, son équivalent DICE est
__stkargs mais un simple #define ne suffit pas. Prenons l'exemple du premier prototype de reqproto.h :
void __stdargs SimpleRequest __PROTO((char *,...));
|
Après le préprocesseur, avec #define __stdargs __stkargs le fichier devient :
void __stkargs SimpleRequest (char *,...);
|
Ce qui provoque une erreur du compilateur.
DC1: Warning Line 14 "dinclude:pd/clib/reqproto.h" 68:expected semicolon
|
Car pour DICE la bonne syntaxe est :
__stkargs void SimpleRequest __PROTO((char *,...));
|
Il est conseillé de ne pas modifier les fichiers fournis avec les bibliothèques donc supprimons ce qualificateur par
un #define __stdargs. Ceci ne marchera que si le passage de paramètre est par la pile par défaut, dans le cas contraire
(options -mR,...), une modification est obligatoire !
On voit tout de suite que le désavantage de ne pas créer notre propre glue est que certaines options de DICE ne sont
plus applicables : plus de profilage, ni de passage de paramètre par les registres... Bref, dans tous les cas un
fichier .fd est toujours préférable à l'utilisation d'un glue fournis.
arp.library
Enfin, on va finir par le plus compliqué : l'arp.library.
Vous pouvez trouver la distribution de cette bibliothèque sur les disquettes de... l'Aztec C ! Allez donc chez votre
voisin qui a ce compilateur et copiez l'archive de l'Arp. Ceci n'a rien d'illégal, et ce n'est pas du piratage car
cette archive est du DP et donc librement copiable. Ce n'est pas le cas du reste de l'Aztec donc on ne prend que l'Arp
et d'autres DP si l'on veut, mais certainement pas le reste !
Donc l'Arp est une des bibliothèques qui a aidé le plus les programmeurs sur Amiga. Pour l'utilisateur moyen, l'Arp fournit
une fenêtre de requête puissante depuis longtemps, devenue inutile avec le 2.0 (mais je rappelle que de nombreux Amiga sont
toujours sous 1.3). Des rumeurs concernant l'Arp et les nouveaux systèmes Amiga ont tentés de faire croire à des incompatibilités.
En réalité, l'Arp fournit des choses distinctes : les commandes (et le AShell) qui visent à remplacer l'environnement
Shell du 1.x (non sans raison d'ailleurs). C'est vrai, certaines commandes sont incompatibles ou inutiles. avec le 2.0 et
je conseille de les virer lors d'une mise à jour du système d'exploitation. De toute façon, utilisant Csh, cela fait longtemps que non
C: ne contient plus que les commandes indispensables. L'arp.librairy qui est une bibliothèque qui facilite beaucoup la
programmation du système. Elle est compatible avec le 2.0 et toujours très utile. La majorité des Shell n'existeraient pas
sans l'Arp. Pour les incrédules, je rappelle que de nombreux DP continuent à l'utiliser (entre autres Csh) même s'ils ne
fonctionnent uniquement que sous 2.0.
Tout n'est pas rose cependant car elle contient aussi quelques bogues mais que le premier programme parfait lui jette la
première disquette !
Les points étant mis sur les "i", il est temps de l'ajouter à notre environnement de programmation. D'abord, évidemment
FDtoLib va nous créer le glue... Cette bibliothèque devrait être la plus compliquée avais-je dit, mais pour le moment, rien que de
très classique ! Ouais, attendez, ça arrive !
Comment diminuer la taille de nos programmes ?
Souvenez-vous (on se croirait chez Drucker !), Amiga News vous avait parlé d'une manière de diminuer sensiblement la taille de nos
exécutables en remplaçant les routines de codage du printf par une fonction de la ROM. Eh bien, je vous propose mieux :
totalement supprimer les f/s/printf, puts de notre code en utilisant ceux de l'Arp.
Première fonction : le puts. C'est la plus simple car le code du glue est largement suffisant.
Un simple "#define puts Puts" réglera le problème.
Pour les autres fonctions à base de printf, un bout de code assembleur s'avère indispensable. Dans le printf de DICE (et aussi
dans les versions 5.xx du Lattice), les arguments du printf sont poussés dans la pile alors que pour celui d'Arp, un registre
(A4) pointe sur les arguments, il correspond donc au vprintf de DICE. En plus, et c'est normal, le fprintf, qui, je le rappelle,
écrit en direction d'un fichier, demande un FileHandler du DOS comme premier argument au lieu d'une structure FILE (équivalent
au fhprintf de DICE). Je ne vais parler que de printf et sprinf, mais ceci peut aussi se généraliser à fprintf.
Ce qui rend la chose plus compliquée que pour les autres bibliothèques est que nous allons devoir créer le glue
nous-mêmes et en assembleur ! Certains prôneraient d'utiliser les mêmes noms que les fonctions à remplacer, de
manière à les écraser, mais je préfère pouvoir accéder aux deux fonctions, donc les "nouvelles" fonctions auront comme
préfixe LF, pour flatter ma mégalo !
Voici donc l'appel de LFPrintf :
section ,code
xref _ArpBase
xdef _LFPrintf
_LFPrintf:
move.l A6,-(A7)
movea.l 8(sp),A0
lea.l $c(sp),A1
movea.l _ArpBase(A4),A6
jsr -228(A6)
movea.l (A7)+,A6
RTS
END
|
Et celui de LFSPrintf :
section ,code<- c'est du code !
xref _ArpBase<- On importe _ArpBase
xdef _LFSPrintf<- & On exporte _LFSPrintf
_LFSPrintf:
move.l A6,-(A7)<- On sauve A6
movem.l 8(sp),D0/A0<- Les deux premiers arguments sont placés dans D0 & A0
lea.l $10(sp),A1<- A1 pointe sur les autres
movea.l _ArpBase(A4),A6
<- _ArpBase-> A6
jsr -642(A6)<- Appel de SPrintf
movea.l (A7)+,A6<- On restore A6
RTS
END
|
Je rappelle que seul A6 doit être restauré, D0, D1, & A0 sont considéré comme des registres de scratch. Compilez
le tout avec DAS. Lors de l'utilisation, n'oubliez pas de relier ce code avec l'option -lmes_fonctions.o.
Il faut aussi penser à prototyper nos fonctions :
extern int LFPrintf(constchar *,...);
// Remplacement pour printf, il utilise le printf d'Arp.library.
// Attention, les entiers sont par défaut sur 16 bits,
// et les flottants ne sont pas accessibles.
extern int LFSPrintf(char *,const char *,...);
// Remplacement de sprintf. Même condition que LFPrintf
|
La prochaine fois, nous créerons notre propre bibliothèque de fonctions (.lib) grâce. à LibMake.
Remarque très importante : attention, certaines bibliothèques utilisent une fonction de la ROM pour faire
leur affichage (l'Arp pour la série des Printf et la Req pour ces fenêtres de requête). Le point important
est que pour ces fonctions les entiers sont sur 16 bits par défaut, alors que DICE utilise 32 bits lors du passage
de paramètres (même pour les shorts pour le moment). Il faut donc l'indiquer à la routine d'affichage en changeant
les %d, %x et %u en %ld, %lx et %lu. Ceci est très important sinon le Guru risquera de se réveiller...
|
