Dice 3

Les bibliothèques partageables sont à la base de tout le système d'exploitation de l'Amiga, et une de ses principales forces. En plus de celles fournies par Commodore ( Exec, Dos, Graphics, ... ), le DPs permet de nous faciliter. la vie ( La majorité. des Shells n'existeraient. pas sans l'Arp.libraries). Choses promises, choses dues .... - musique angoissante soulignant le suspense intenable - voici l'utilisation de ces bibliothèques avec Dice.

Chaque distribution programmeur d'une librairie devrait - doit - être accompagne des fichiers suivant :

• 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.

Je vais commencer par le plus simple : La PowerPacker.libraries V35.344 de la FredFish 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 librairies.

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'Amiga20 doit être créé :

Makedir Dinclude:pd/clib Makedir Dinclude:pd/libraries

Le fait de faire #include <libraries/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 vas se dépecher de les remplacer par les notres car ils ne sont pas suffisants. Regardons dans DLIB:; on vois que chaques .lib existent en plusieurs exemplaires: amigal20.lib amigapl20.lib amigarl20.lib amigarpl20.lib amigas20.lib amigasp20.lib amigasr20.lib amigasrp20.lib par exemples en ce qui concerne simplement la bibliothèque Amiga. Chaques versions concernent un groupe d'options de Dcc

1. *s.lib pour small-code,
2. *p.lib pour le 'profilling',
3. *r.lib pour le passages d'arguments par registres
4. et toutes les combinaisons ...

FDTOLIB permet de créer les glues codes facilement à partir des fichiers .fd, avec la possibilité que les librairies soit 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 linker notre glue.
Pour ceux qui utilise DiceConfig, ajouter

PowerPacker -lPP

à la fin de dlib:diceconfig.cfg .

Passons à un peut 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 vas oublier tous 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èmes 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

vas 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.

1. D'abord, Dice ne gère pas les #Pragras, un #define NO_PRAGMAS suffit généralement à les éliminer.
2. 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é est __stdargs qui force le passages 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 *,...));
   Apres 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 passages de paramètre est par la pile par défaut., dans le cas contraire ( options -mR,...), une modification est obligatoire !!.

Enfin, on va finir par le plus compliqué : L'Arp.librarie.
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 & copiez l'archive de l'Arp. Ceci n'a rien d'illégal., & 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, & d'autres DPs 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 un requester puissant depuis longtemps, devenu inutile avec le 2.0 ( mais je rappelle que de nombreux Amigas sont toujours sous 1.3 ). Des rumeurs concernant l'Arp & les nouveaux OS Amiga ont tenter de faire croire a des incompatibilités. En réalité, l'Arp fournit deux choses distinctes :

1. Les commandes ( & 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 & je conseille de les virer lors d'un upgrade de l'OS. De toutes façons, utilisant CSH, cela fait longtemps que non C: ne contient plus que les commandes indispensables.
2. L'Arp.librairie qui est une bibliothèque qui facilite beaucoup la programmation du système. Elle est COMPATIBLE avec le 2.0, & toujours très. utile. La majorité des Shell n'existerais pas sans l'Arp. Pour les incrédules, je rappelle que de nombreux Dps continuent a l'utiliser ( entre autre CSH ) même si ils ne fonctionnent uniquement que sous 2.0.

Tous n'est pas rose cependant car elle contient aussi quelques Buggues mais que le premier programme parfait lui jette la premiere disquette !!

Les points étant mis sur les i, il est temps de l'ajouter a 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 !. Ouai, attendez, ça arrive !

Comment diminuer la taille de nos programmes ?

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 a 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 & 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ême ... et en assembleur ! Certains prôneraient. d'utiliser les mêmes noms que les fonctions a remplacer, de manière. a les écraser, mais je préfère. pouvoir accéder aux 2 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

& 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 2 premiers arguments sont placer 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. Compiler le tous avec DAS.
Lors de l'utilisation, n'oubliez pas de 'linker' ce code avec l'option -lmes_fonctions.o.
Il faut aussi penser a 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. a LibMake.

Remarque très importante : Attention, certaines librairies utilisent une fonction de la Rom pour faire leur affichage ( l'Arp pour la série. des Printf & la Req pour ces requesters ). 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 a la routine d'affichage en changeant les %d, %x & %u en %ld, %lx & %lu. Ceci est très. important sinon le Guru risquera de ce réveiller. ...