 |
Vendredi 06 juin 2025 - 12:25 |
| Translate |
|
| Rubriques |
| Réseaux sociaux |
|
| Liste des jeux Amiga |
|
| Trucs et astuces |
|
| Glossaire |
|
| Galeries |
|
| Téléchargement |
|
| Liens |
|
| Partenaires |
|
| A Propos |
|
| Contact |
|
|
|
Il est de bon ton de dire pis que pendre du BASIC en général, et de l'AmigaBasic en particulier. Quelle ingratitude ! La plupart d'entre nous avons commencé par b-a-ba-siquer sur un micro ou sur un autre. Pour ma part, après avoir tâté de l'AppleSoft et du Basica de l'IBM, j'avais été émerveillé de la souplesse et de la puissance de l'AmigaBasic. Évidemment, on peut faire encore beaucoup mieux avec cette machine, mais au moyen de langages beaucoup plus ésotériques et rébarbatifs. Ne rougissez donc pas de programmer en AmigaBasic !
Un mot sur les BASIC
Cela dit, vous l'avez surement remarqué vous-même, ce bon vieux AmigaBasic a quelques inconvénients : un éditeur particulièrement irritant de lenteur dans sa gestion des fenêtres, un interpréteur gigantesque (110 koctets) qui laisse peu de place aux programmes graphiques gloutons en pixels et en couleurs, quelques bogues plus ou moins bien connus, et surtout une lenteur frustrante quand on a goûté aux vraies possibilités de la machine. A mon avis, le meilleur remède à cette lenteur est de doper l'AmigaBasic avec une ou deux petites routines machine bien placées, mais cela sous-entend qu'il faut se mettre à l'assembleur... quelqu'un parlait ici de langage ésotérique ?
Il existe un compromis d'accès plus commode entre le BASIC interprété d'origine et la rapidité du langage machine : les BASIC compilés...
Certains sont des langages entièrement nouveaux (True Basic, F-Basic) ; d'autres se veulent compatibles avec AmigaBasic, c'est-à-dire que tout programme tournant sous AmigaBasic devrait pouvoir être compilé et ainsi transformé en du code 68000 directement exécutable. Le plus ancien est le AC/Basic. Voici maintenant le HiSoft Basic (et le GFA ? va-t-on me dire. Ah ! Le GFA ! C'est une autre histoire... mais nous en reparlerons un peu).
Bien entendu, il ne faudrait pas espérer rivaliser avec des programmes directement écrits en assembleur, ni même avec des programmes en C, quoique, pour le C... Mais attention, on ne peut pas gagner sur tous les tableaux : un interpréteur a l'avantage que si vous ne comprenez pas ce qui se passe dans votre algorithme, vous pouvez arrêter votre programme et examiner l'état de toutes les variables. Ce ne sera plus possible avec un BASIC compilé ; la notion de mode direct a totalement disparu (en fait, il y a quand même un moyen : passez votre module dans un débogueur pour assembleur. C'est possible avec HiSoft, dixit la notice. Mais pas pour les débutants...).
L'avantage d'un BASIC compatible est qu'on peut reprendre les programmes déjà écrits pour l'AmigaBasic et leur donner une nouvelle jeunesse. Mais ces nouveaux BASIC présentent tous des extensions qui pallient avec plus ou moins de bonheur les lacunes de l'ancêtre et c'est là-dessus, à mon avis, qu'il faut juger de leur intérêt.
Le HiSoft Basic a déjà été présenté par nos confrères de Commodore Revue (avril 1989) et d'AmigaWorld (août 1989) et sans doute par d'autres. Pour apporter un peu d'originalité à cet article, je vous confierai mes premières impressions d'utilisateur après un galop d'essai un peu plus poussé que le simple passage des programmes de "benchmark" (banc d'essai) : j'ai essayé de refaire en BASIC le programme FracGen des disquettes Fish 142 ou 188, avec lequel on peut faire de si beaux dessins. J'ai travaillé avec la version 1.04 du HiSoft, datée du 18 mars 1989.
Présentation matérielle
Le HiSoft Basic est un ensemble éditeur+compilateur intégré, c'est-à-dire qu'il vous propose d'écrire vos fichiers sources dans un éditeur à lui, à partir duquel vous pourrez faire la compilation par une simple pression de touches, le tout depuis le Workbench. Toutefois, si vous tenez particulièrement à écrire vos sources dans un autre éditeur, libre à vous mais il vous faudra compiler à partir du CLI et le débogage sera moins agréable.
Pour 1100 F environ, vous avez droit à deux disquettes et un manuel. La première disquette est une disquette Workbench contenant l'éditeur et le compilateur, la deuxième disquette contient de nombreux exemples de programmes. Le manuel s'appuie ouvertement sur le manuel AmigaBasic. Ce n'est pas un ouvrage d'initiation au BASIC au contraire, il renvoie le lecteur à un certain nombre de titres - tous anglais - pour cela. Par contre, il décortique en détail deux programmes plus avancés : une application des fichiers à accès direct (un répertoire téléphonique) et une application des sous-programmes récursifs (les tours de Hanoï). Le reste du manuel explique, l'emploi de l'éditeur et du compilateur, puis passe aux définitions de référence des ordres BASIC, en renvoyant de temps en temps le lecteur au manuel AmigaBasic. Tout cela malheureusement est en anglais.
Autant dire tout de suite qu'il vous faudra au moins 1 Mo de mémoire pour travailler à l'aise. Je n'ai pas fait l'essai avec 512 ko, mais la notice n'est pas très encourageante ; si si, ça doit marcher, mais pour des petits programmes, et puis les extensions mémoire sont maintenant à un prix très raisonnable, n'est-il pas vrai ?
Le compilateur existe sous deux formes : une version réduite si vous n'avez que 512 ko de mémoire, et la version complète, qui est un fichier respectable de 267 ko. Seule la version complète vous fournira des fichiers exécutables autonomes. Les fichiers fournis par la version réduite réclameront la présence de la hisoftbasic.library - qui n'est pas dans le domaine public ! Il sera donc impossible de diffuser ces fichiers réduits, sauf auprès des autres possesseurs de HiSoft Basic. Ayez donc 1 Mo de mémoire ou plus et n'en parlons plus.
Le compilateur reste en mémoire après sa première invocation, pour gagner du temps sur les compilations ultérieures. La plupart de ses nombreuses options peuvent être fixées quand on passe par la commande "Amiga+C" - compilation seule. Une grosse fenêtre de requête s'ouvre avec 13 gadgets, couvrant la presque totalité des 15 options possibles : garde-fous pour l'exécution (surveillance des dépassements de dimensions de tableaux, "overflows", dépassement de la pile), code liable ou pas, messages d'erreurs ou non, taille de la zone de mémoire pour les tableaux ("heap"), arrêt par "Ctrl-C" ou non, module objet autonome ou non, etc. On peut également fixer ces options par des commandes ad hoc dans le programme.
Une fois votre choix arrêté, vous cliquez "Compile" et la compilation démarre. S'il y a des erreurs, la compilateur suggérera d'en rester là et de revenir à l'éditeur, en vous signalant le type d'erreur et le numéro de la ligne fautive (bien sûr, vous ne numérotez plus vos sources BASIC, mais l'éditeur vous retrouvera immédiatement cette ligne, via une commande spéciale "Amiga-G"). Si vous refusez, il continue jusqu'à l'erreur suivante, etc. A la fin, il refuse de fabriquer le module objet et vous revenez à l'éditeur, où vous irez de ligne fautive en ligne fautive en pressant "Amiga-J" (même philosophie que Devpac). Bien entendu, l'erreur n'est pas toujours au numéro de ligne indiqué. Si vous avez oublié un "NEXT" ou un "END IF", le compilateur ne protestera que lorsqu'il se trouvera face à une impossibilité logique et ce sera à vous de placer le "NEXT" ou le "END IF" au bon endroit.
Vous finirez bien par expurger votre source de toutes ses erreurs. Le compilateur aura alors créé un module objet, généralement en mémoire (c'est l'option par défaut). Vous pressez "Amiga-X" et l'exécution démarre... Si votre programme tente des choses contre-nature comme de gonfler un entier court au-delà de 32768 ou d'ouvrir une fenêtre dans un écran qui n'existe pas, votre programme avortera sur une requête rouge et noire (un petit) expliquant plus ou moins clairement ce qui ne va pas dans vos agissements - et il vous dit à quelle ligne cela se passe - et vous vous retrouverez dans l'éditeur, pour le tour suivant. Corrections faites, vous pourrez abréger les cérémonies en pressant directement "Amiga-X" : vous passerez automatiquement par le compilateur, avec les mêmes options, puis par l'exécution.
Une indication sur la rapidité du compilateur. Pour un programme de 900 lignes et de 24000 octets (enlever quelques % de commentaires), la compilation demande 37 secondes. Ce n'est donc pas l'exécution immédiate d'un interpréteur, mais c'est tout de même supportable... Pour les très gros programmes, on peut faire comme les pros, compiler par petits bouts et lier le tout.
Différences et extensions par rapport à l'ancêtre
Comme on s'y attendait, HiSoft Basic présente de nombreuses nouveautés par rapport à AmigaBasic. Le domaine le plus évident concerne les instructions de contrôle. Outre un "IF THEN... ELSE... END IF" (sans bogue cette fois) et le "WHILE... WEND", on a droit à une structure de boucle très générale "DO UNTIL/WHILE LOOP UNTIL/WHILE" où le ou les tests peuvent aussi bien être sur le "DO" que sur le "LOOP" final ou à cheval sur les deux instructions, avec sortie possible depuis l'intérieur de la boucle par un "EXIT DO" ; encore plus général, des boucles "REPEAT xxx... EXIT xxx... END REPEAT xxx" qu'on peut imbriquer à volonté, l'ordre "EXIT" permettant de sortir de n'importe quel niveau ; également les instructions de triage "SELECT CASE... END SELECT".
Moins évident, mais tout aussi important, davantage peut-être, la gestion des sous-programmes est considérablement améliorée. Outre les classiques "GOSUB... RETURN", les "SUB... END SUB" peuvent maintenant avoir de véritables variables locales en plus des variables "STATIC" ou des variables partagées avec le programme principal ("SHARED"). De plus, ils sont complètement récursifs, pour la plus grande joie des amateurs de fractales et des nostalgiques du LOGO. Les "DEF FN ... END DEF" introduisent maintenant de véritables sous-programmes avec autant de lignes que vous le voulez, également avec des variables locales, statiques ou partagées, et le tout récursif. Les arguments peuvent être transmises par valeurs, ou par adresses si vous permettez au sous-programme de modifier ces arguments. Que demander de plus ? (eh bien si ! J'aimerais bien qu'on puisse transmettre le nom d'un autre sous-programme parmi les arguments. C'est peut-être d'ores et déjà possible avec un peu d'acrobatie - à vérifier - mais j'aimerais pouvoir le faire en toute quiétude).
Il y a de nombreuses améliorations plus ponctuelles : des instructions "BLOAD", "BSAVE", "FEXIST" (vérifie l'existence d'un fichier), "MKDIR" et "RMDIR" (crée ou supprime un répertoire), "PCOPY" (réalise une copie d'écran graphique selon les spécifications du fichier Preferences), "REDIM" permet de redimensionner un tableau sans perdre les éléments déjà créés. De nombreuses instructions préexistantes ont été améliorées : "PRINT PTAB(x,y)" positionne une impression de texte au pixel près dans les deux directions ; "COLOR" permet maintenant de choisir parmi les divers modes d'impression JAM1, JAM2, COMPLEMENT, etc. - les auteurs d'éditeurs graphiques appécieront le mode "COMPLEMENT", "SCREEN" et "WINDOW" donnent accès à pratiquement tous les modes d'écrans possibles (mais le manuel renvoie au ROM Kernel Manual pour les détails...).
Un point intéressant, à propos des fonctions de bibliothèque : dans le cas des bibliothèques en ROM (Exec, Dos, Graphics, Intuition...), on n'a pas besoin des fichiers "bmap" pour l'exécution des modules autonomes, seulement lors de leur compilation et la plupart d'entre eux se trouve dans le répertoire "libs" de la disquette système fournie par HiSoft.
Enfin, et encore plus important que tout ce qui précède, la gestion de la mémoire est beaucoup plus rigoureuse. Essayez donc en AmigaBasic de répéter le cycle ouverture-fermeture d'un écran graphique et d'une fenêtre. Vous aboutissez très vite à un "Out of heap". Pas de problème en HiSoft, même en variant le type des écrans dans la boucle. Il est bien vrai qu'on ne pouvait lâcher des sous-programmes récursifs en liberté sans une gestion pointue de la mémoire. Il reste néanmoins quelques problèmes (voir plus loin).
Un autre bogue de l'AmigaBasic, lié à "CHDIR" (non-restitution d'une structure "lock" quand on quitte BASIC et permanence de l'icône de la disquette) n'existe plus. HiSoft Basic va même très loin : il ferme pour vous tout ce que vous avez oublié de fermer, fichiers, fenêtres, écrans. N'en profitez pas pour prendre de mauvaises habitudes ; quand vous passerez au C ou à l'assembleur...
Compatibilité avec AmigaBasic
Je n'ai pas vraiment étudié moi-même la compatibilité avec AmigaBasic et je rapporterai simplement les conclusions de l'article d'AmigaWorld. La plupart des programmes se compilent sans problèmes ou moyennant un léger réaménagement, mais quelques-uns ne fonctionnent plus correctement, alors que tout se passe bien avec AC/Basic. Concluez par vous-même si vous tenez à une compatibilité à 100%.
On peut s'interroger sur ces problèmes de compatibilité. Cela ne vient évidemment pas des instructions inutiles qui ont disparu, les "LOAD", "SAVE", "LIST" du mode direct. Plus gênant peut-être, certaines instructions ont changé de sens. Par exemple, "CLEAR" remet tout à zéro mais ne sert plus à réserver de la place en mémoire. Comme il n'accepte plus d'argument, une instruction "CLEAR,50000" devrait provoquer une erreur à la compilation mais ce n'est pas le cas. L'instruction "CHAIN" permet de passer d'un fichier compilé à un autre fichier compilé mais en fermant toutes les fenêtres et tous les fichiers (ce que ne fait pas AmigaBasic).
J'ai eu quelques surprises avec HiSoft Basic, par rapport aux habitudes que j'avais prises avec AmigaBasic. D'abord, quand on utilise les fonctions des bibliothèques du système (Dos, Graphics, Intuition...) il ne faut surtout pas déclarer les fonctions qui ne renvoient aucun résultat (comme "Move" ou "Text") sinon le compilateur s'arrête en vous jetant un message "misused library function" à la face (fonction mal employée). AmigaBasic n'était pas si strict ; la déclaration était inutile, sans plus de drame. J'ai perdu une bonne heure avant de comprendre ce qui se passait. Le plus piquant est que HiSoft a jugé bon d'ajouter un fichier spécial d'explications sur les fonctions de bibliothèques à côté des "Readme" de dernière heure, et qu'ils n'ont pas évoqué cette méchanceté. De surcroît, le message d'erreur en question n'est pas documente dans le manuel.
Une autre surprise : en AmigaBasic, un programme comme :
Toujours dans le domaine de la compatibilité, mais en rubrique "tristement compatible", pourquoi donc HiSoft a-t-il conservé des limitations aux identificateurs d'écran et de fenêtre ? Si vous avez exécuté un "SCREEN 1,320,400..." vous ne pourrez pas fermer cet écran 1 puis ouvrir un autre écran 1 avec une autre résolution (par contre, vous pourrez changer le nombre de couleurs). Enfin, ce numéro d'écran est forcément entre 1 et 4. Largement suffisant, dites-vous ? Voire... De même, les numéros de fenêtre sont forcément entre 1 et 8, et si vous avez ouvert une fenêtre 4 sur un écran 320x400, vous ne pourrez plus réouvrir plus tard de fenêtre 4 sur un écran de résolution différente ; j'ai trouvé cela beaucoup plus limitatif. Enfin... restons souple et adaptable, comme je le disais plus haut.
Encore dans le domaine des déceptions. En AmigaBasic, j'avais essayé une petite animation de BOB : prenez 4 ou 5 BOB que vous lancez au hasard et que vous faites rebondir sur les bords de la fenêtre. Quoiqu'en dise le manuel, presque tous vos BOB vont disparaître. Cette expérience avait marqué la fin prématurée de mes essais d'animation en AmigaBasic. Eh bien, j'ai eu le regret de constater que HiSoft était strictement compatible pour ce programme. Fin de ma HiSoft-bob-experience.
Comparaison avec d'autres BASIC
Une question que chaque basicard convaincu des insuffisances d'AmigaBasic se pose : parmi tous ces nouveaux BASIC tous plus performants les uns que les autres, quel est celui qu'il me faut ? Comme je n'ai pratiqué que AmigaBasic et HiSoft, je ne donnerai pas de réponse catégorique. Je vais simplement rapporter brièvement ce que j'ai glané à droite et à gauche. J'ai entendu parler de quatre BASIC possibles en plus du HiSoft :
AC/Basic est l'un des plus anciens. D'après le récent papier dans AmigaWorld, il est résolument compatible avec AmigaBasic, mais il fournit des modules objets beaucoup plus longs que HiSoft, avec des temps d'exécution de 30 à 100% plus longs.
True Basic est un produit sérieux, avec un souci affiché de portabilité entre les machines de marques différentes. Il me semble que la conséquence immédiate est qu'il doit superbement ignorer tout ce qui fait que nous préférons l'Amiga aux autres machines...
GFA Basic a fait couler beaucoup d'encre ces derniers temps. Il a un éditeur (imposé) assez inconfortable (mais nous sommes éminemment adaptables). A peu près totalement incompatible AmigaBasic, avec un parti-pris d'originalité confinant parfois à la provocation gratuite (par exemple, variables suffixées par % pour des entiers longs ou par & pour des entiers courts). J'ai le regret de confirmer qu'il y a des gens allergiques à GFA - moi au moins. J'ai toutefois bravement supporté mes démangeaisons pour écrire et faire tourner quelques tests de performance et je confirme que GFA est bigrement rapide (voir plus loin) !
Il n'a pas encore de compilateur qui fournisse des modules autonomes, mais ça devrait bientôt venir. Question : les performances de GFA seront-elles encore améliorées par le compilateur à venir ? Actuellement, les programmes édités par GFA demandent la présence d'un gros module "runtime" de 90 ko (dans le domaine public) en plus du programme proprement dit (Bruce Lepper : Dominique Lorre de Micro Application prépare la version française de ce compilateur qui est compatible A-Link et B-Link et produit un code directement exécutable. Sur certaines opérations, il dit qu'il y a un gain de jusqu'à 700% - mais pour un test de ses performances en utilisation "normale", nous attendons sa sortie. Qui sait, il y aura peut-être de quoi faire disparaître des démangeaisons...).
F Basic n'est disponible qu'auprès de ses créateurs américains, Delphi Noetics Systems, Inc. Sans doute encore plus exotique que GFA. Il se prétend tout bonnement aussi rapide que le C ; il faut dire qu'on peut y définir des structures, manipuler des pointeurs et agir au niveau des registres du 68000... qu'a-t-on de plus en C ? Très puissant et complet, avec même un débogueur au niveau du code compilé, mais d'emploi délicat et assez peu convivial (Amazing Computing et AmigaWorld, octobre 1988). De plus, il semble qu'il ne fournisse pas de modules objets autonomes.
Une expérience avec HiSoft Basic
Comme je le disais plus haut, en guide de premier essai, j'ai essayé de refaire un FracGen en BASIC. Le principe est expliqué dans la figure. Vous partez d'un germe, une suite de segments qui vont d'un point à une autre ; ce germe constitue la génération 0 du dessin et vous initialiser le compteur de générations à n=0. Dans la génération n+1, vous allez remplacer chacun des segments de la génération précédente par une réduction du germe à l'échelle adéquate (voir figure) et vous continuez tant que les segment ne sont pas trop petits ou que "n" n'est pas trop grand. Pour faire plus joli, on complique la recette avec des changements de couleur et des retournements variés du germe initial.
La routine centrale est donc la routine de tracé, un sous-programme récursif. Je n'ai pas eu de problème particulier, à part le danger classique des programmes récursifs, la prolifération des variables locales au fur et à mesure qu'on s'enfonce dans les générations. Ces variables sont prises dans deux zones de mémoire bien distinctes, la pile (stack) et le "tas" (heap) ; les variables simples viennent de la pile et les tableaux ou les chaînes de caractères du "tas". La pile peut se régler avant l'exécution (par l'instruction STACK du CLI, ou bien sous Workbench en modifiant le champ adéquat du fichier icône, via le menu "Info") mais le "tas" est fixé une fois pour toutes à la compilation. HiSoft surveille ce vous faites. Si vous tirez trop dans le "tas", une terrible requête rouge et noire explose sur l'écran avec un message "Don't panic!" et une invitation à cliquer. Humour anglais, je suppose, car l'étape suivante est le plantage total de l'Amiga. Si vous abusez de la pile, HiSoft fait comme tous les autres programmes Amiga, la machine se plante sans avertissement. Moralité : surveillez tout vous-même avec la fonction "FRE" et une bonne marge de sécurité (depuis que j'ai pris les mesures nécessaires, je n'ai plus vu le Guru).
Un regret : que le "tas" ne puisse pas être réglable comme la pile, à l'exécution. Un conseil : dans les routines intensément récursives, évitez de créer des tableaux de variables locales, préférez les variables simples à prendre dans la pile, même si cela force à ajouter quelques lignes au programme. Dans le cas particulier de la courbe initiale de FracGen, le temps de tracé est passé tout bonnement de 80 à 14 secondes ! Comme dans cet exemple, il n'y a que trois secondes de calcul algébrique proprement dit et beaucoup moins pour les tests de contrôle, il faut bien croire que le reste du temps se passe dans des opérations d'affectation de mémoire, apparemment bien plus rapides dans la pile que dans le tas.
L'édition graphique du germe pose le problème du contrôle de la souris et de son bouton. Il y a trois fonctions évidentes à remplir déplacement d'un point (par simple glisser), l'addition d'un nouveau point (cliquer une fois sur l'un des segments du germe) et la suppression d'un point (j'ai opté pour le double-clic sur ce point ; j'aurais préféré détecter une pression du bouton droit, mais cela ne figure pas dans l'arsenal HiSoft). Seul le double-clic m'a posé quelques problèmes de synchronisation, il ne faudra pas aller trop vite...
La fonction "MOUSE(0)" de HiSoft est la même que celle d'AmigaBasic, fournissant une réponse entre -2 et +2 selon les cas de figure (simple clic, double-clic, glisser...). En fait, les évènements "souris" sont détectes si rapidement que l'instruction "ON MOUSE GOSUB ..." arrive toujours avec "MOUSE(0)=-1" (c'est-à-dire vous êtes en train d'appuyer sur le bouton). A vous de prendre la suite et de déchiffrer ce que fait l'utilisateur en comptant les coups et en consultant "TIMER".
J'avais déjà fait des éditeurs de ce genre en AmigaBasic, dans des programmes alternant cette édition des paramètres du calcul et écran graphique où on fait un dessin selon ces paramètres (Cf. mon programme IFS). Tôt ou tard, la souris devenait sourde et muette, et il fallait cliquoter et agiter les menus à tout va avant qu'elle ne reprenne vie. Je n'ai rien constaté de tel avec HiSoft ; tout au plus, de temps en temps, je me retrouve avec un éditeur graphique non activé (cela se voit avec le bandeau titre en écriture "fantôme") et il faut cliquer un coup pour rien. Autrement dit, l'instruction "WINDOW p" quand on change d'écran ne vous conduit pas forcément à une fenêtre "p" activée.
Concernant le réglage des couleurs et la sauvegarde IFF, j'ai repris mes routines en assembleur que j'avais écrites pour ÀmigaBasic. D'après le manuel, il suffit de remplacer les vieux "CALL" par des "CALL LOC..." et de veiller à ce que les routines machines respectent le registre a6. Malheureusement pour moi, AmigaBasic n'ayant pas cette exigence, je n'avais pas pris cette précaution. J'ai donc dû reprendre mes routines mais j'ai maintenant une disquette BASIC+ASM.3 compatible HiSoft qui offre un large éventail de routines IFF/ILBM, d'affichage de fichiers texte, de palette et une boîte de requête de fichiers (si vous êtes intéressés, écrivez-moi). À propos de requête de fichiers, HiSoft offre un programme de démo pour utiliser celui de arp.library, si vous ne voulez pas du mien...
Toute modestie mise à part, j'aimerais bien que le vrai FracGen ait un éditeur dans le genre de celui que j'ai écrit avec HiSoft. La mise au point des germes est bien plus confortable. Et puis, je ne rougirais pas non plus de la routine de calcul : pour le même germe au démarrage, pour la même précision, il me faut 14 secondes, à comparer aux 11 secondes du vrai FracGen et je peux encore grappiller quelques dixièmes de seconde par-ci par-là, en enlevant quelques-unes des options garde-fou du compilateur ou en améliorant encore l'écriture de la routine. Qui disait donc que le BASIC ne pouvait pas se mesurer au C ?
Tests de performance
Les programmes "benchmarks" sont des petits programmes qui permettent de tester les vertus de tel ou tel programme dans tel ou tel domaine, les calculs en entier ou en flottant, les opérations sur les chaînes de caractères, les entrées-sorties sur disquette, etc. Le jeu consiste à faire tourner les mêmes programmes (honnêtement réécrits) avec les différents langages.
J'ai rassemblé dans le tableau ci-joint des résultats concernant divers BASIC, et, pourquoi pas, les langages sérieux que sont C et Modula-2. En général, j'ai arrondi les temps en secondes entières. Je ne garantis que les chiffres concernant HiSoft et GFA (sauf la dernière ligne pour GFA) parce que j'ai fait tourner les programmes moi-même. Les autres chiffres ne sont pas toujours cohérents d'une source à l'autre et il y a parfois des temps aberrants (que je n'ai pas recopiés).
J'ai pris ces chiffres aux sources suivantes :
- 1. AmigaWorld, vol.5-8, août 1989.
- 2. Amazing Computing, vol.3-10, oct 1988.
- 3. The Amigan Apprentice, vol. III-2, mai 1988.
- 4. Commodore Revue, n°10, mars 1989.
Les tests successifs sont :
- Sieve : recherche des premiers nombres entiers jusqu'à 7000 ou 8190.
- Calc : suite de multiplications et de divisions, en simple précision (sng) ou en double précision (dbl).
- Savage : suite d'opérations transcendantes avec calcul d'une erreur moyenne. On trouvera les listings de Sieve, Calc et Savage en annexe à cet article. Attention : la comparaison avec GFA est pipée parce que la précision des variables dans GFA n'est pas ce que tous les autres langages appellent "double précision" (voir annexe 2).
- Boucle vide : FOR i&=1 TO 1000000 : NEXT. En C, on obtient 39 ou 83 selon qu'on utilise les registres ou non.
- Pset : écrit 200x100 points dans l'écran Workbench.
- DrawLine : 5000 fois LINE (0,0)-(639,199) dans l'écran Workbench.
- PrintString : écrit 1000 fois une même chaîne de caractères sur l'écran. Si je fais 1000 fois "PRINT PTAB(10)a$", les temps HiSoft tombent à deux et trois secondes ; autrement dit, c'est le défilement de l'écran qui fait perdre du temps (en GFA, il faut cinq secondes pour faire 1000 fois "PRINT AT(1,10);a$").
- CR est le test défini dans la Ref.4, essentiellement une combinaison complexe de calculs sur les entiers et les flottants. Le chiffre pour le C correspond au Lattice 5.0 (alors qu'il s'agissait du 4.0 dans les lignes Calc).
La différence entre les temps des colonnes (a) et (b) est surtout due à l'option "EVENT ON". Cette option peut avoir des conséquences catastrophiques... ou imperceptibles, selon le type de programme. On peut la débrancher sur une partie du programme, dans un sous-programme de calcul pur par exemple, puis la rebrancher.
Il y a une erreur : les résultats de HiSoft pour Sieve doivent être divisés par 10.
Je crains d'avoir été assez bavard, mais je voudrais souligner que l'intérêt d'un langage ne se limite pas aux promesses de son manuel de référence ou aux résultats des tests de performance. Il tient beaucoup à sa facilité d'emploi et à sa fiabilité, ce qui ne se mesure qu'à l'usage. On découvre alors ce qui n'est pas dit dans le manuel.
HiSoft se présente comme un super AmigaBasic. Son apprentissage est immédiat quand on connaît AmigaBasic. Il pallie un grand nombre des défauts de celui-ci, manifestement pas tous et on peut encore souhaiter mieux. L'introduction d'un type "structure", notamment, permettrait une programmation naturelle des fonctions du système et en ferait un rival très sérieux pour les "grands" langages. Le père Noël passera peut-être chez HiSoft... D'ici là, on reste avec un BASIC, c'est-à-dire un bon compromis entre la facilité d'emploi et la complexité de toutes les possibilités de la machine, mais un BASIC apparemment robuste et très rapide et, me semble-t-il, le meilleur compromis rapidité-convivialité du moment, tous langages confondus.
Annexe 1
Les programmes Sieve, Calc et Savage et HiSoft Basic :
Les erreurs fournies par les programmes Calc et Savage donnent des indications sur la précision des produits et divisions (pour Calc) et sur celle des fonctions transcendantes (pour Savage). La "double précision" de GFA est en gros 50 à 100 fois moins précise que celle des autres langages ; en revanche GFA calcule plus vite, ceci pouvant compenser cela. On constate aisément que l'éditeur de GFA n'accepte pas plus de 12 ou 13 décimales alors que si on fait "PRINT a" dans Calc avec HiSoft, on retrouve les 15 décimales du listing. A noter que l'erreur dans le test de Savage est surtout due aux ATN de grands nombres ; si on limite l'excursion de i à 50, l'erreur tombe à 5.E-15 (HiSoft) ou 5.E-I3 (GFA).
En simple précision, GFA déclare forfait (cela n'existe pas). Pour Calc, l'erreur rendue par HiSoft est nulle ! Pour obtenir autre chose que 0, il faut faire cinq fois de suite c=c*a, puis cinq fois c=c/a ; l'erreur passe alors à 1.E-07. Le test de Savage en simple précision passe en neuf secondes avec une erreur de 1.E-4 (ou 3.E-6 si on limite i à 50).
|
Nom : HiSoft Basic 1.04. Éditeur : HiSoft. Genre : programmation BASIC. Date : 1989. Configuration minimale : Amiga OCS, 68000, 512 ko de mémoire. Licence : commercial. Prix : 1100 FF environ. |
|
