Obligement - L'Amiga au maximum

Mardi 12 décembre 2017 - 03:41  

Translate

En De Nl Nl
Es Pt It Nl


Rubriques

 · Accueil
 · A Propos
 · Articles
 · Galeries
 · Glossaire
 · Hit Parade
 · Liens
 · Liste jeux Amiga
 · Quizz
 · Téléchargements
 · Trucs et astuces


Articles

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

 · Articles in english
 · Articles in other languages


Twitter

Suivez-nous sur Twitter




Liens

 · Sites de téléchargements
 · Associations
 · Pages Personnelles
 · Moteurs de recherche
 · Pages de liens
 · Constructeurs matériels
 · Matériel
 · Autres sites de matériel
 · Réparateurs
 · Revendeurs
 · Presse et médias
 · Programmation
 · Développeurs logiciels
 · Logiciels
 · Développeurs de jeux
 · Jeux
 · Autres sites de jeux
 · Scène démo
 · Divers
 · Informatique générale


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


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


Partenaires

Annuaire Amiga

Amedia Computer

Relec

Hit Parade


Contact

David Brunet

Courriel

 


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.
  1. *s.lib pour small-code,
  2. *p.lib pour le "profilling" (profilage),
  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 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 :

    PowerPacker
    -lPP

...à 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.
  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é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 de l'OS. De toutes façons, 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...


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