Obligement - L'Amiga au maximum

Jeudi 21 septembre 2017 - 07:07  

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 - DiceConfig et programmes résidents
(Article écrit par Laurent Faillie et extrait d'Amiga News - mai 1993)


Après l'installation, il est temps de programmer notre premier utilitaire avec DICE. La version enregistrée ayant beaucoup trop d'options pour utiliser les alias comme pour la version freeware, nous allons donc créer un programme de configuration. Il faut se rappeler que DCC prend ces options aussi bien dans la ligne de commande que dans DCCOPTS.

Attention : il s'agit d'une variable de type "Commodore" (donc stockée dans ENV:), en opposition aux variables "ARP" utilisées par Csh.

Notre programme va remplir cette variable en fonction de l'exécutable que nous voulons créer. Tapez le listing de DiceConfig et compilez avec :

Dcc -2.0 -ms -// -r DiceConfig.c -o DiceConfig

DiceConfig a besoin d'un fichier de configuration nommé "DiceConfig.cfg".

-2.0 -ms -//
Math
-lm

La première ligne contient toutes les options toujours présentes (-2.0 pour l'utilisation des includes et bibliothèques du 2.0...). Les lignes suivantes indiquent, par groupes de 2, les bibliothèques que l'on peut lier (linker) :
  • La première ligne contenant le nom,
  • La seconde les actions à faire.
DiceConfig

A l'exécution, le programme ouvre une fenêtre où l'on peut :
  • Choisir le niveau de profiling (profilage). Il s'agit de code que DICE ajoute et qui donne des statistiques sur l'exécution d'un programme. Très utile pour savoir où un programme perd son temps.
  • Créer un programme pure (pur) (qui peut être rendu résident).
  • Unix permet d'ouvrir les fichiers avec une syntaxe à l'UNIX.
  • Dynastack crée un programme avec une pile dynamique. Très utile pour les programmes récursifs !
  • Enfin, Debug ajoute le "hunk-symbole" à l'exécutable (lors du réassemblage avec Dobj par exemple, les étiquettes sont conservées). Il fait aussi un #define DEBUG pour une compilation conditionnelle. Nous y reviendrons par la suite (toujours des promesses...).
  • Le dernier groupe de gadgets sert à choisir les bibliothèques à lier. Pour le moment, il ne devrait y avoir que "math" de sélectionnable.
Le code

Regardons un peu le code. D'abord, on peut voir que les messages peuvent être en français en mettant la variables "Lang" à "français". Je préfère cette solution à la locale.library qui n'est pas compatible avec le 1.3 (de toutes façons, je n'ai pas les documentations...).

Il contient aussi quelques particularités de DICE :
  • La première chose qui peut surprendre les utilisateurs d'autres compilateurs est que je n'ai ouvert aucune bibliothèque : DICE le fait tout seul. Cela évite quelques Gurus !
  • Une des fonctions de ce programme est aussi de se rappeler la configuration des gadgets entre deux appels. J'ai donc utilisé la propriété "__config" pour deux variables qui contiennent l'état du programme. DICE crée le code pour que ces variables soient automatiquement lues au départ et sauvegardées à la fin de l'exécution.
Grâce à l'option -r, notre exécutable peut être mis résident. Voilà une bonne occasion pour se pencher sur les programmes pure.

"Pure"

Un programme pure est un programme qui peut être mis résident. Cette possibilité est apparue avec le système 1.3 pour les utilisateurs du Shell standard et depuis beaucoup plus longtemps pour ceux qui préfèrent les Shells utilisant l'arp.library (Csh, AShell...). Une fois de plus, grâce à Commodore, les deux résidents ne sont pas compatibles ! (mais ils peuvent quand même cohabiter comme nous avons pu le voir dans le premier épisode).

Pour résumer, la table Commodore est gérée par "Res1.3" alors que la table Arp est gérée par "resident" (le résident du Shell). Or DCC se trouve dans l'Arp (pour être accessible depuis le Shell) et ne gère que la table Commodore où doit donc se trouver Dc1, Das, Dlink. Les dernières versions de Csh (V5.19 par exemple) permettent d'utiliser aussi la table Commodore mais ce n'est pas encore parfait (et ça ne marche pas sous 2.0). Une autre différence, l'Arp reteste l'intégrité de la commande à chaque fois qu'il l'exécute, mais pas Commodore. Essayez de rendre résident une commande non pure dans le Shell du 1.3. La première exécution passe... la seconde casse ! Csh nous aurait indiqué que la commande a été altérée.

Quelles différences y a-t-il entre un programme ordinaire et une commande pure ?

Un programme normal peut modifier, comme il le veut, ces variables, voire son propre code, car à chaque nouvelle exécution, tout sera rechargé depuis le disque ; pour un programme résident, ceci n'est plus possible car le même segment mémoire est utilisé à chaque fois. Prenons le programme suivant :

int i=5;
Void main(){
i++;
printf("%d\n",i);
}

"Non Pure"

Dans le cas d'un programme non pure, le compilateur réservera la place pour "i" en y mettant directement la valeur 5. Si ce programme est mis résident de force, la première exécution donnera 6 (5+1), mais la seconde donnera 7 (6+1) - ou ne marchera pas dans un Shell Arp car la somme de contrôle (checksum) de la commande a changé. En effet, rien n'a remis "i" à sa valeur initiale après la première exécution !

Un programme pure s'y serait pris autrement : les variables globales sont créées dynamiquement - ce qui permet à la commande de s'exécuter simultanément dans plusieurs Shells, les variables étant recréées pour chaque tâche - et son affectées ensuite à leurs valeurs initiales.

Comment ce n'est pas clair ? Allez prendre une bière - ou un Pastis - et relisez calmement ce qui précède.

De toutes façons, le C est un langage de haut niveau, donc nous ne devrions pas nous soucier de ces questions très techniques. Ouais, bof, les utilisateurs du Lattice ou de Aztec peuvent vous en parler (peut-être que leurs dernières versions permettent ce genre de manipulations). Avec DICE, rien de plus simple, il n'y a qu'à ajouter un -r à la ligne de commande et le tour est joué. Presque, car si le programme comporte des données en mémoire Chip, elles doivent obligatoirement être constantes. Enfin, DICE permet de partager des variables entre plusieurs tâches d'un même programme s'il est résident, avec l'attribut __shared mais ça ne marche pas avec les Shells Arp (somme de contrôle modifiée).

Bon, c'est fini pour aujourd'hui. La prochaine fois nous verrons les bibliothèques partageables...

Note : vous pouvez télécharger une archive contenant le binaire de DiceConfig v1.0 avec le fichier source.


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