 |
Jeudi 03 avril 2025 - 05:48 |
| Translate |
|
| Rubriques |
| Réseaux sociaux |
|
| Liste des jeux Amiga |
|
| Trucs et astuces |
|
| Glossaire |
|
| Galeries |
|
| Téléchargement |
|
| Liens |
|
| Partenaires |
|
| A Propos |
|
| Contact |
|
|
|
Au seuil des dernières grandes vacances, le kit de compilation AMOS version Pro a vu le jour. Outil de phase finale dans un travail de programmation, cette extension rend enfin possible la libération de vos sources. A l'occasion de cette sortie, une mise à jour d'AMOS Pro voit le jour en s'attribuant le numéro de version 2.0.
Compilation AMOS sous Workbench
A l'image de la version antérieure réservée à AMOS, le kit est composé du compilateur proprement dit, d'un Shell de compilation et d'une bibliothèque AMOS propre à son fonctionnement. L'outil principal réside pourtant en une commande incluse dans le tiroir "C:" de votre système. En effet, le module appelé "APCmp" (contraction d'AMOS Pro Compiler) est un exécutable ayant la particularité de pouvoir être indépendamment utilisé sous CLI ou sous AMOS.
Cette multiplicité d'utilisations tient à ce que le compilateur peut permettre au programmeur, même en l'absence de la version Pro, de compiler une source BASIC et cela pour des fichiers tokenisés ou de simples scripts ASCII. Est-il alors envisageable de penser pouvoir créer un exécutable sans posséder AMOS Pro ? La réponse va vous conforter d'aise. Non seulement, cette version est capable de fonctionner en autonomie absolue, mais encore elle offre de compiler des sources issues de milieux aussi divers qu'Easy AMOS, AMOS (non Pro) ou, tout aussi inhabituel, d'un fichier ASCII construit avec l'éditeur Ed du Workbench. Cette dernière possibilité démontre s'il en est les buts inavoués affichés par la nouveauté : être un produit à part entière.
On peut donc acheter la boîte, sans pourtant posséder AMOS Pro. On peut même envisager de ne jamais avoir eu entre les mains un produit édité par Mandarin Software, à charge dans ce cas de connaître de façon innée le langage et ses commandes, et de se passer de débogueur aisément vos sources (à moins de désassembler le code résultant à l'aide d'un MonAm quelconque). Cependant, cela reste le module de compilation d'AMOS Pro.
Genèse d'un exécutable
Pour ceux qui l'ignoreraient encore, la compilation dans le cas d'AMOS consiste à créer, à partir d'une source exécutable seulement avec l'aide d'un interpréteur, un programme indépendant de l'environnement dont il est issu. La clef de voûte de ce processus est sans l'ombre d'une incertitude la commande "APCmp". Celle-ci s'est vu gratifier d'un jeu d'options conséquent. Pas moins de douze mots clefs sont envisageables. A l'image d'une compilation dans un environnement C, on doit désigner en entrée le fichier source contenant votre code AMOS. Tous les autres paramètres sont optionnels. Cela veut dire d'abord que le fichier "cible" ou "destination" n'a nul besoin d'être entré. Par défaut, il sera créé au côté du code source. Sinon APCmp offre de le placer où bon vous semblera.
Il est envisageable de générer quatre types de programmes : Workbench (c'est-à-dire s'exécutant à partir d'une icône), CLI (où l'on crée une commande démarrant à partir d'une fenêtre), CLI multitâche (qui en plus de lancer le code à partir d'une fenêtre, rend la main à celle-ci tout en se plaçant en tâche indépendante) et AMOS Pro compilé (qui tient à la création d'une source AMOS Pro contenant dans une procédure le code compilé). Multiplicité donc des types de programmes créés, afin de mieux s'adapter à vos besoins.
Ceci se retrouve également dans le choix offert d'inclure l'amos.library dans le code, car, à défaut, celle-ci devra toujours être placée dans le tiroir "Libs:". La non-intégration de cette bibliothèque permet de rendre vos codes exécutables compacts (on n'a plus les 50 ko en trop). Sans passage de paramètres adéquats, un écran AMOS 320x256 points est systématiquement ouvert. On peut inhiber cette création, mais alors il conviendra de créer l'écran, sinon la sanction sera celle de l'impitoyable Guru. Pour alléger la source, l'omission de message d'erreur AMOS est envisageable. Dans ce cas, il faut être sûr de son code (on n'est d'ailleurs jamais sûr de rien). Un programme peut s'exécuter tout en laissant à l'écran le Workbench. Dans ce cas l'écran AMOS apparaîtra quand une commande "AMOS to Front" sera utilisée.
Cette option est intéressante, car elle rend possible l'utilisation de programmes en tâche de fond, sans que cela n'entrave l'utilisation du Workbench. On peut ainsi lancer un gigantesque programme de calcul sans qu'il n'y paraisse. Cependant, certaines imperfections subsistent. La compilation en mode AMOS Pro compilé par exemple ne rend correctement qu'aléatoirement l'intégrité de vos écrans AMOS. Et cela, même si trois secondes avant, le programme précédemment lancé a parfaitement joué son rôle. Rassurez-vous, cela ne plante pas l'Amiga, ni d'ailleurs votre programme. Mais vous risquez de ne pouvoir obtenir un résultat visuel sur l'écran AMOS. Plaisir du multitâche sans doute.
Pour vos programmes les plus longs, une option remplacera toutes les instructions 68000 BRA (BRanch Always ou sauter à une instruction en toutes circonstances) par une instruction JMP (JuMP ou saut). Cette dernière peut sauter à une adresse sur 32 bits, ce qui n'est pas le cas de la première. Mais celle-ci prend moins de cycle machine pour s'exécuter. L'utilisation de JMP ne devra se faire que dans l'hypothèse de sources d'une longueur insolente.
En ligne de commande, le tiroir contenant les bibliothèques nécessaires peut être modifié, ainsi que le fichier de configuration du compilateur. Comme toute commande du tiroir "C:", APCmp peut fonctionner en mode Quiet, c'est-à-dire sans délivrer de message dans la fenêtre CLI. La dernière option concerne la tokenisation. Si on compile un fichier ASCII, il est automatiquement tokenisé (préparé au format de fichier source AMOS, format adapté à l'interprétation). APCmp, au lieu de compiler un fichier, peut simplement convertir un listing ASCII en source AMOS : le tokeniser.
Accessoires de compilation
C'est intéressant de pouvoir compiler à partir du CLI, mais c'est encore meilleur si cela est possible directement dans l'éditeur d'AMOS Pro. Pour cela, des accessoires ont été incorporés. Les mêmes options sont rencontrées, mais cette fois plus besoin d'utiliser le clavier. La souris reprend la main, dans un univers construit avec la complicité efficace du système d'interface.
Sur ce caractère graphique, l'outil est parfaitement intégré dans l'ensemble. Comme à son habitude, François Lionet y a réuni toute la magie de son langage. Un système complet de paramétrage subdivisé en trois pôles essentiels a été retenu. Au premier rang, on y trouve les paramètres de compilation proprement dits, qui regroupent les options précédemment énumérées au sujet d'APCmp. Le deuxième pool de réglages concerne le fonctionnement du Shell_Compiler, c'est-à-dire des options supplémentaires offertes par l'accessoire. C'est le cas par exemple de la copie automatique des bibliothèques dans le RAM Disk ou de la compression des programmes compilés.
Panneau principal
Une fois démêlés, les méandres du paramétrage reste à voir le panneau principal du logiciel. Très visuel, celui-ci propose d'abord trois types de sources à compiler : celle issue de la fenêtre d'édition à partir de laquelle le Shell a été lancé ; un fichier précédemment sauvé et exhumé de vos mémoires de masse afin de lui faire subir un traitement fortifiant ; et enfin ce qui est appelé pudiquement la "Compiler List Editor".
Il s'agit dans cette ultime optique d'automatiser le processus de compilation pour une liste de sources AMOS. Le compilateur se charge de lancer successivement la construction des fichiers exécutables pris dans la liste que vous avez définie. Les éléments de la liste sont capables d'être sélectionnés seuls, ou bien alors tous les fichiers AMOS d'un répertoire donné peuvent d'une seule définition incorporer la file. C'est un système de lot très puissant, hormis le fait qu'il est impossible d'affiner le paramétrage de compilation pour chaque élément : même régime de création pour tous. Vient ensuite la définition de la destination. Par défaut, il s'agit d'un fichier sur disque. On peut ouvrir une nouvelle fenêtre AMOS et y placer le résultat de la compilation. Cela est exclu en cas de lot.
Si la compression est de rigueur, elle intervient en dernier ressort. La pression sur le bouton "Help" donne des informations sur chaque élément sélectionné de l'interface. Dommage par contre que les fonctions principales ne soient pas doublées par une combinaison de touche. Un bogue est apparu à la suite d'un arrêt volontaire de la compilation. Une fois retournés à l'éditeur d'AMOS, les menus ont eu quelques maux, et l'effet obtenu était inquiétant, mais pas rédhibitoire. Une commande du menu "accessoire" est réservée uniquement au paramétrage du compilateur.
Un dernier outil, que je nommerai le "Compilateur Rapide", compile le programme contenu dans la fenêtre de travail au format source AMOS et place le résultat dans une nouvelle fenêtre. Pratique pour faire quelques tests !
Une poignée de commandes en plus
Hormis les utilitaires, AMOS Pro Compiler intègre seize nouvelles instructions au langage. Celles-ci vous permettront de créer votre propre module de compilation, ou d'opérer certains tests en vue d'un débogage. "Compile" incluse dans un programme, ou en mode direct, est équivalent à APCmp. Les mêmes commandes doivent être placées à sa suite. D'autres fonctions servent à gérer le processus de compilation, comme "Comp Load" qui charge APCmp à partir d'un endroit donné (le RAM Disk entre autres).
Quatre commandes sont réservées à la compression/décompression des données (format AMOS ou PowerPacker). Celles-ci ne sont pas documentées dans l'aide en ligne. Mais les cinquante pages du manuel n'entravent en rien une recherche rapide de la syntaxe d'utilisation. Les accessoires étant eux-mêmes écrit en AMOS, vous n'aurez aucun mal à vous en inspirer.
Et la vitesse
La question cruciale concernant ce genre d'utilitaire est de connaître exactement son utilité. En écartant la futile question de vitesse, il faut bien dire qu'elle est immense : on peut détacher tout programme de l'interpréteur AMOS, et le rendre totalement indépendant comme c'est le cas d'un programme C. Cela va faciliter la distribution de vos oeuvres, et leur utilisation deviendra totalement transparente. Donc, c'est a priori à posséder absolument si on est un utilisateur d'AMOS.
La vitesse, quant à elle, peut aussi être un point crucial. En théorie, le fait de se passer d'interpréteur (et de ses éventuelles interventions) et de convertir vos lignes AMOS Basic en code machine va avoir pour effet de doper vos créations. C'est de pure logique, et dans le cas présent c'est une réalité, dont nulle exception ne vient contrarier la règle. Les essais effectués n'ont rien pu faire pour le démentir. Quant à quantifier cette vitesse, c'est-à-dire donner des rapports, pourcentages et autres ratios, je ne m'y risquerai pas. Il est simple de présenter une batterie de tests standard et d'en déduire des valeurs chiffrées, mais il est hasardeux d'en donner une interprétation fiable. Les hommes politiques en sont l'exemple le plus vivant : pas un seul ne commente de la même façon les derniers chiffres édités par l'INSEE. Traduit en terme de programmation, chaque programmeur a une façon particulière de construire ses sources. Il en ressort des différences considérables en termes de rapidité pour une même fonction à efficacité égale.
Les codes assembleurs ne prennent pas le même temps machine. Si les conditions s'y prêtent une multiplication par décalage logique de bits est plus véloce qu'un "MULU" pourtant destiné à cette seule opération. L'utilisation de "POKE" pour remplir un écran a plus de mordant que le "PLOT" classique. Les exemples sont légions. La rapidité dépendra toujours de facteurs endogènes et exogènes à un programme. Pour rassasier les amateurs de sensation, il m'est arrivé de diviser par cinq le temps d'exécution de certaines routines après passage au compilateur. Pour d'autres, le seuil est inférieur à 5%. Cela dépendra de la façon de faire, la seule limite étant le code propre à chaque fonction AMOS. A moins de le désassembler et de l'optimiser, il y a un point de non-retour impossible à surmonter.
Enfin, le code assembleur de François Lionet est d'une qualité irréprochable. Bien malin celui qui pourra faire une comparaison valable avec d'autres langages. Les jolis exemples fournis sur le deuxième disque ne sont là que pour l'anecdote. Le jeu de Synthex est bien fait, mais pour moi les jeux de tir... Jean-Baptiste Bolcato, à qui on doit le Shell_Compiler, nous offre, quant à lui, quelques trucs pour gagner en vitesse. Tout cela a un intérêt pédagogique évident.
AMOS Pro, deuxième génération
Le lot de compilation intègre une troisième disquette destinée à mettre à jour votre vieille version 1.xx en toute nouvelle 2.00. Ce changement ressemble plus à un nouveau souffle donné au produit qu'à une réelle modification de la forme et du fond. Certains points du logiciel ont été réécrits, notamment pour pouvoir accueillir dans un proche avenir les nouveaux modes AGA. A l'heure actuelle, AMOS Pro fonctionne parfaitement sur un A1200 ou un A4000, mais pas encore question de faire un jeu en 256 couleurs. Cette possibilité demande effectivement certaines rectifications dans les structures d'écran. Pour faciliter cette mutation, François Lionet a orienté son programme vers une utilisation plus poussée des bibliothèques. Le code principal n'a plus que comme seul objectif d'harmoniser ces différentes banques de fonctions.
L'avantage est évident : faciliter l'intégration des futures mises à jour (que l'on trouve et que l'on trouvera dans le domaine public). La banque contenant le pointeur souris et la police système a été enlevée du tiroir "APSystem" et intégrée dans l'amos.library. Souplesse oblige, il est toujours possible d'en intégrer des différentes par le biais du système de configuration. Une seule nouvelle fonction, ZDIALOG, servant à connaître l'ID d'une zone se trouvant à une coordonnée définie par l'utilisateur.
Toujours dans le domaine du contrôle de la gestion des interfaces, le "Resource Bank Maker" offre la possibilité de placer vos codes interfaces dans la Resource Bank. Au lieu d'inclure dans une variable texte insérée dans votre source le contrôle et la création d'une interface, il suffit maintenant de l'invoquer au sein même de la banque. Cela évitera de surcharger vos sources.
Par contre, cela n'est pas très convivial en ce qui concerne la mise au point et le débogage. Ce n'est pas encore une Interface Builder. Ce dernier produit n'étant malheureusement pas encore mis au point, on en est encore à créer l'interface directement dans le programme, et une fois au point, à la supprimer des lignes de codes pour l'intégrer dans la "bank".
Un train de bogues a été éradiqué. Il en subsiste cependant encore : le placement d'un "Icon" dans un menu est très risqué. Si du texte est placé après l'ordre de dessin, un beau plantage système interviendra. Ne cherchez pas non plus la fonction interface "InactiveList" pourtant présente dans le manuel : elle n'existe pas. Quelques problèmes apparaissent également dans la manipulation de certaines banques. Mais ils sont très rares.
Une version spéciale de la bibliothèque "3D.lib" du kit AMOS 3D a été placée dans le paquetage. Celle-ci permet d'utiliser les fonctions de 3D, de cette extension dans AMOS Pro. Pour faire fonctionner cette extension, il faut déjà posséder AMOS 3D, car la bibliothèque "C3D.LIB" n'est pas fournie. La même mise à jour existe pour le compilateur AMOS.
Un très grand produit
Cela devient une habitude : la gamme AMOS fait toujours plus pour nous étonner, et réjouir en nous l'âme du programmeur. Le compilateur fonctionne presque à merveille. Par malchance en effet, un programme de mon cru a planté à son lancement sous Workbench. Il faut dire pour la défense d'AMOS que du code assembleur y était intégré. Mais ce n'est qu'une hypothèse. Le programme fonctionne parfaitement en mode interprété !? Évidemment ce n'est qu'un exemple isolé, et il a fallu que cela tombe sur moi.
Il est toujours aussi regrettable que l'ensemble soit dans la langue des Beatles. Les contraintes de distribution sont ce qu'elles sont. C'est navrant d'avoir un produit 100% made in France, et de s'escrimer à décrypter des pages entières. Patientons, car la traduction est en cours.
Un autre regret tient à la disparition de l'utilitaire AMOS Assembler (présent dans AMOS Compiler). Son auteur a refusé de l'adapter à la nouvelle version, et certaines voix se sont élevées pour marquer leur réprobation face à ce concept. C'est l'un des gros points faibles d'AMOS Pro. On peut y incorporer du code machine, mais impossible de le construire directement dans la source. Il serait souhaitable que cela soit développé dans les versions futures. L'exemple du Blitz Basic 2 doit être suivi. Ce dernier intègre un assembleur In-Line et un système de structure équivalent au C. AMOS Pro tient toujours à distance le Workbench et Intuition. Il est prévu dans un avenir proche d'intégrer cette notion d'espace de travail. Pour l'instant c'est inexistant. Ce n'est pas grave, car intégrer Intuition, c'est aussi subir ses tares.
Conclusion
AMOS Pro Compiler, pour un prix très modique, est à acquérir d'urgence. C'est un module d'extension primordial pour qui veut développer ses applications en AMOS Basic. La souplesse et la rapidité de l'ensemble sont sans égal. Quelques utilisateurs inquiets ont pu critiquer la dénomination "Pro" rajoutée à AMOS. Il paraît que cela fait peur, et provoque des réticences à l'utiliser. Comme tout langage qui se respecte, ce n'est pas toujours évident à mettre en oeuvre. Mais avec ou sans Pro, AMOS restera toujours un outil exceptionnel.
|
Nom : AMOS Pro 2.0 (AMOS Pro Compiler). Développeur : François Lionet. Éditeur : Europress Software. Genre : langage de programmation. Date : 1993. Configuration minimale : Amiga OCS, 68000, 1 Mo de mémoire. Licence : commercial. Prix : environ 400 FF. |
|
