Obligement - L'Amiga au maximum

Mardi 19 mars 2024 - 07:47  

Translate

En De Nl Nl
Es Pt It Nl


Rubriques

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

Articles in english


Réseaux sociaux

Suivez-nous sur X




Liste des 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,
ALL


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


Galeries

Menu des galeries

BD d'Amiga Spécial
Caricatures Dudai
Caricatures Jet d'ail
Diagrammes de Jay Miner
Images insolites
Fin de jeux (de A à E)
Fin de Jeux (de F à O)
Fin de jeux (de P à Z)
Galerie de Mike Dafunk
Logos d'Obligement
Pubs pour matériels
Systèmes d'exploitation
Trombinoscope Alchimie 7
Vidéos


Téléchargement

Documents
Jeux
Logiciels
Magazines
Divers


Liens

Associations
Jeux
Logiciels
Matériel
Magazines et médias
Pages personnelles
Réparateurs
Revendeurs
Scène démo
Sites de téléchargement
Divers


Partenaires

Annuaire Amiga

Amedia Computer

Relec


A Propos

A propos d'Obligement

A Propos


Contact

David Brunet

Courriel

 


Test du compilateur AMOS 1.3 (AMOS Compiler)
(Article écrit par Pierre Ardichvili et extrait d'Amiga News - septembre 1991)


Amiga News a reçu une préversion du compilateur AMOS ; au moment où cet article paraîtra, on devrait pouvoir se le procurer en France pour 295 FF. Lorsque Bruce Lepper m'a proposé d'en faire l'essai, j'ai accepté, bien qu'à vrai dire mes premiers contacts avec AMOS n'aient pas été très engageants.

AMOS

Pour la petite histoire...

En effet, la version 1.1 que j'avais achetée en France (je ne m'étais jamais mis au GFA à cause des nombreux bogues dont j'avais entendu parler sur DEEP) comportait, ironie du sort, un certain nombre de bogues, et la documentation, en anglais, ce qui ne me gênait pas beaucoup, comportait un certain nombre d'erreurs et de silences qui, eux, m'ont bien gêné.

Le club des utilisateurs situé en Grande-Bretagne n'est pas une bonne solution pour nous : pour s'y inscrire, il faut leur envoyer un chèque de 12 livres. Le mien n'est jamais arrivé chez eux ; ils n'acceptent pas les cartes de crédit et ne répondent pas aux lettres non accompagnées d'une enveloppe timbrée. Les timbres anglais sont difficiles à trouver en France. Je ne pouvais donc pas en toute honnêteté me déclarer un inconditionnel d'AMOS, d'autant plus que les jeux d'arcade ne me passionnent pas beaucoup, sauf s'ils sont d'une qualité assez exceptionnelle, ce qui par définition est rare.

Mais voilà, François Lionet est un enthousiaste, un bosseur acharné, l'écoute de ses clients, car AMOS a reçu de constantes améliorations : c'est ainsi que la version 1.3 d'AMOS qui accompagne le compilateur et qui est nécessaire pour pouvoir l'utiliser, nous apporte, entre autres, la possibilité de travailler sur un écran haute résolution en mode entrelacé, sans parler de la réécriture de certaines routines pour les rendre plus rapides. De plus, existe à présent une documentation en français pour AMOS. Par ailleurs, François répond aux questions techniques sur 3615 ANT, rubrique "François Lionet".

Utilisation et description

Ceci n'est pas un essai technique complet : si certaines choses peuvent sembler trop élémentaires à certains, qu'ils pensent à leurs débuts ; les questions que l'on voit posées sur l'un ou l'autre serveur montrent bien que tout n'est pas évident pour tout le monde ! La boîte contient un manuel et deux disquettes, l'une pour la mise à jour d'AMOS à la version 1.3 (condition indispensable à l'utilisation du compilateur), l'autre contenant les éléments du compilateur.

Le manuel est comme toujours doté d'une excellente présentation ; les textes sont clairs, émaillés çà et là des superlatifs habituels à la documentation AMOS. Les procédures d'installation sont détaillées et prévues pour toutes les configurations depuis l'Amiga 500 sans expansion et muni d'un seul lecteur de disquette jusqu'à la machine équipée d'un disque dur, d'un paquet de mémoire et de deux lecteurs. De plus, elles marchent très bien.

Lisez toutefois la doc si vous voulez installer AMOS 1.3 et le compilateur dans un sous-répertoire et non dans le répertoire racine d'une partition ou d'un disque. II y a quelques opérations, fort bien documentées, à faire à la main ; mais pourquoi diable ne pas les avoir confiées au programme d'installation, qui, lui, accepte d'installer AMOS dans un sous-répertoire, ce qui est un piège car sans le petit travail mentionné ci-dessus, AMOS refuse de démarrer. Ceci est un piège tout à fait dans la ligne d'AMOS, le premier et le plus beau étant la fameuse instruction LLIST qui en fait n'existe que dans la doc.

L'installation s'est malgré tout réalisée très vite. Les instructions d'utilisation sont claires, les précautions à prendre pour économiser la mémoire dans le cas de petites configurations sont bien expliquées. Pour être complet, il faudrait mentionner ici toutes les dispositions qui peuvent être prises pour obtenir le meilleur compromis entre la rapidité du compilateur et l'utilisation de la mémoire. Ce serait assez fastidieux. Je n'aime pas émettre d'affirmation sans en avoir fait l'essai, mais j'ai l'impression qu'il y a vraiment tout ce qu'il faut pour que chacun puisse optimiser son installation.

Enfin, le compilateur lui-même est d'une simplicité d'emploi consommée (j'attrape le style AMOS, c'est contagieux). Il se lance tout simplement à partir d'AMOS, comme n'importe quel programme. Ici réside une des commodités du système, car la fonction "Run Other" d'AMOS permet d'avoir simultanément en mémoire le compilateur et le programme à compiler, ce qui permet un va-et-vient entre le compilateur et le programme source en restant dans la même fenêtre, par de simples clics de souris. On peut tout aussi bien lancer le compilateur par le Shell, en lui passant des paramètres de configuration. Lorsque le compilateur est lancé sous AMOS, ces derniers lui sont passés, si besoin en est, via un écran commandé par le gadget en forme de clé anglaise.

AMOS

Le programme à compiler est écrit dans l'éditeur d'AMOS (très convivial), ce qui permet de l'essayer en mode interprété. De toute manière, il faut actionner la fonction "Test" avant de compiler, sans quoi le compilateur refuse la compilation. Si votre programme marche en mode interprété, il est alors impossible qu'il ne marche pas en mode compilé. Notons enfin que le compilateur se lançant de l'intérieur d'AMOS, comme n'importe quel programme AMOS, il n'y a pas de raison pour qu'on ne puisse pas le lancer à partir d'un programme, et par conséquent les instructions nécessaires ont été incluses.

De même, un programme compilé peut en lancer un autre. Le compilateur a une option permettant le compactage de l'exécutable, le décompactage étant automatique. Voilà, ceci n'est qu'une présentation rapide et pas un essai complet, mais ça devrait pouvoir vous allécher.

Avant tout, pour finir par ce qui aurait dû être le commencement, pourquoi compiler ? Il y a deux raisons majeures : pour obtenir un exécutable indépendant et pour accélérer l'exécution du programme.

L'exécutable indépendant

Un programme écrit dans un langage interprété demande évidemment la présence de l'interpréteur en mémoire, ce qui représente par exemple 102 ko dans le cas de l'AmigaBasic, et pas loin de 200 ko pour AMOS et ses divers fichiers annexes. Les programmes AMOS interprétés peuvent fonctionner indépendamment d'AMOS, en présence de RAMOS, qui pèse 82 ko.

Un programme compilé n'a normalement besoin de rien d'autre que d'un Workbench avec certaines des bibliothèques standard de l'Amiga. Pour les deux compilateurs BASIC que j'ai eus en main, l'AC-Basic et AMOS, il faut toutefois mettre à la disposition du programme compilé une bibliothèque additionnelle, qui soit est incorporée à l'exécutable, qu'elle engraisse généralement de l'ordre de 40 ko, soit est présente dans le système. Dans le cas d'AC-Basic, ces fichiers doivent alors se trouver dans le répertoire "t:" pour que le programme "léger" marche. Dans le cas d'AMOS, ils sont bien évidemment là lorsque l'exécutable est lancé depuis AMOS.

En clair, un exécutable de 2 ko pèsera de l'ordre de 42 ko si on souhaite qu'il puisse se lancer et tourner soit en cliquant sur son icône, soit en le lançant depuis le Shell, aucun fichier spécial ne devant être ajouté au système. Par contre, les programmes compilés lancés depuis AMOS pourront conserver la taille plus fine.

Si cette taille des programmes autonomes vous pose problème, il faudra sans doute vous tourner vers le GFA.

La performance

Pour bien montrer la performance des programmes compilés, François Lionet recommande de lancer le programme interprété Cube-AMOS, puis de le compiler et de voir la différence.

Ce programme présente un cube en filaire, dont on peut commander la rotation sur les trois axes par des touches du pavé numérique, puis que l'on peut déplacer en continu par pression sur les touches de curseur.

L'amélioration est spectaculaire. Le mouvement, de très saccadé en mode interprété, devient assez fluide en version compilée, et d'une fluidité quasi parfaite avec un 68030.

J'ai mesuré le temps nécessaire, le cube étant en rotation (ce qui en fait ne change pratiquement rien à la vitesse de translation), pour lui faire traverser tout l'écran en maintenant simplement une touche de curseur enfoncée ; voyez plus bas les résultats.

Ce programme comporte un certain nombre de calculs faisant appel à des fonctions trigonométriques, dont l'exécution est souvent lente, mais ce n'est pas nécessairement ce qui prend le plus de temps. Comme chacun sait, la lenteur d'exécution des programmes interprétés est due au fait que chaque instruction est interprétée.

J'ai donc écrit en C, en AmigaBasic (suivi d'une compilation par AC-Basic) et en AMOS un petit programme assez cru de tracé d'une fractale de Mandelbrot (écran 320x256, niveau d'itération 32) comportant en gros un million d'itérations, puis mesuré le temps d'exécution de ce programme dans toutes ses versions, en mode 68000 (carte accélératrice hors-service) et en mode 68030.

J'ai aussi fait calculer cette fractale, avec les mêmes paramètres, par un programme commercial spécialisé (Math-Vision) qui utilise pour le calcul des Mandelbrot une routine écrite en assembleur et fonctionnant sur un mode récursif, ce qui représente ce que l'on peut faire de plus rapide.

Les résultats sont donnés dans les tableaux ci-dessous.

Tableau 1 : traversée de l'écran par le code

Cube.AMOS 68000 68030
Interprété 29" 6"
Compilé 8" 1,9"
Gain x3,6 x3,2

Tableau 2 : fractale

Mode AMOS AmigaBasic
AC-Basic
C MathVision
68000 - - - 2'15"
Interprété 41'10" 2h55' - -
Compilé 8'30" 42'50" 34'20" -
Gain x4,0 x4,1 - -
68030 - - - 50"
Interprété 7'30" 26'50" - -
Compilé 3'10" 6'50" 5'40" -
Gain x2,4 x3,9 - -

Ce tableau montre des choses tout à fait intéressantes :

1. L'interpréteur AMOS donne des programmes rapides systématiquement quatre fois plus que l'AmigaBasic, qui a beaucoup de chances d'être en absolu ce qui se fait de plus lent.

2. Le compilateur AMOS donne des programmes qui s'exécutent plus vite que leurs homologues en C. Ça, c'est la bonne surprise ! Les affirmations de la documentation d'AMOS sur la rapidité du langage tant en versibn interprétée qu'en version compilée ne sont donc pas dues qu'à l'enthousiasme de l'auteur ! Il faut aussi signaler la rapidité du processus de compilation. Je n'ai fait qu'une mesure, en mode 68030, pour le programme de calcul de fractale. La compilation a pris 3 secondes, comparées à 4,5 secondes pour l'AC-Basic et 6 secondes pour le C dans ce dernier cas les includes étaient précompilés, c'est surtout l'éditeur de liens qui consomme du temps). Ces temps seront évidemment beaucoup plus longs lorsque l'on travaillera sur une machine à mémoire réduite et sans disque dur.

J'attire votre attention sur le fait qu'un tel essai n'a qu'une signification très relative. En effet, dans la vitesse d'exécution d'un programme interviennent de nombreux facteurs, dont certains dépendent de l'approche utilisée par l'interpréteur ou le compilateur, et d'autres de la machine. Par exemple, tout ce qui est affichage à l'écran dépend en partie du matériel et du logiciel système de l'Amiga. Pour vous en convaincre, écrivez les deux versions du programme suivant :

repère de temps
for x=0 to 1000
print "a"
next x
repère de temps

...et :

repère de temps
for x=0 to 100000
repère de temps

Note : la ligne "repère de temps" est en AMOS : "1print timer" (donne des 50e de seconde). En AmigaBasic : "1print time$" (donne les heures, minutes, secondes). Faites tourner en interprété et en compilé. Pour le programme sans affichage, la compilation donne un gain de 10 pour l'AmigaBasic et de 20 pour AMOS. Pour le programme avec affichage, le gain est pratiquement nul.

Vu la vocation d'AMOS, il est probable que la grande majorité des programmes écrits dans ce langage sont destinés à tourner sur des machines non accélérées, mais il pouvait être intéressant de voir ce que cela pouvait donner sur des machines plus performantes.

Que manque-t-il encore à AMOS ?

Pour faire des jeux, probablement pas grand-chose, mais je suis mal placé pour le dire. Pour faire des démos, il faut signaler que le compilateur AMOS comporte également un assembleur, ce qui permettra d'insérer des routines en assembleur dans des programmes AMOS. Ceci devrait donner des vitesses qui s'approchent de la limite du possible pour une configuration de machine donnée.

Il y a sur la disquette du compilateur une démo avec défilement multiple et un programme de double défilement d'étoiles très joli à voir. Pourrait-on en passant demander aux programmeurs de ces belles choses d'être un peu moins avares de commentaires dans leurs fichiers sources ?

Peut-on faire autre chose que des jeux avec AMOS ?

Bien sûr. A condition d'accepter soit de lancer les programmes depuis AMOS, soit de les voir prendre 40 ko de mémoire supplémentaires, on peut écrire des programmes qui seront plus rapides que leurs homologues en C, sans s'empoisonner avec les structures et la gestion des messages et sans passer par le désagrément des déclarations de variables ni subir la paranoïa des compilateurs en ce qui concerne les conversions de types.

La seule chose qui manque encore à AMOS pour des applications un peu spéciales comme les fractales, c'est de pouvoir calculer avec 15 chiffres significatifs, car 7 chiffres, ce n'est pas assez pour faire des choses un peu poussées dans ce domaine.

Il me semble que la vitesse d'exécution donnée par le compilateur, venant s'ajouter à la facilité de réaliser des animations, devrait permettre de belles réalisations dans le domaine des programmes de simulation interactifs à usage didactique, en physique par exemple. J'aimerais avoir le temps d'en écrire !

Conclusion

Le compilateur AMOS m'a pressionné. C'est vraiment un beau produit. Bien qu'il s'appelle "The Creator", ce qui est une définition très large, AMOS a essentiellement une image de programme destiné à écrire des jeux. Le compilateur devrait permettre non seulement de remplir encore mieux cette mission, mais d'élargir son domaine d'application, et par rebond celui de l'Amiga. C'est tout le bien que je lui souhaite...

Nom : Compilateur AMOS 1.3 (AMOS Compiler).
Développeur : François Lionet.
Genre : logiciel de programmation.
Date : 1991.
Configuration minimale : Amiga OCS, 68000, 512 ko de mémoire.
Licence : commercial.
Prix : 295 FF.


[Retour en haut] / [Retour aux articles]