Obligement - L'Amiga au maximum

Vendredi 29 mars 2024 - 08:03  

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

 


Dossier : La programmation sur Amiga
(Article écrit par Stéphane Schreiber et extrait d'Amiga Spécial Environnement - juillet 1994)


On dira ce que l'on voudra, mais pour exploiter pleinement son Amiga, il faut bien utiliser des programmes. Donc, il faut des programmeurs pour les créer, ces programmes. Et qu'est-ce qu'ils utilisent, ces programmeurs ? Des outils de programmation, oui. Donc des programmes. Programmés par d'autres programmeurs. Avec d'autres programmes. Jeu : jusqu'où peut-on remonter comme ça ?

Ou bien, exprimé d'une autre manière : qui était là le premier, le programme ou le programmeur ? Le programmeur de l'outil de programmation, ou bien l'outil de programmation utilisé par le programmeur de l'outil de programmation ? Allez, ne vous cassez pas trop la tête, la réponse est simple : le programmeur était là le premier, puisque c'est lui qui a créé le premier outil de programmation. Entièrement. Sans utiliser un autre outil de programmation, sinon on n'en sortira jamais.

Quel langage ?

L'Amiga est fort généreusement pourvu en langages de programmation. Des plus utilisés (C, Assembleur, Pascal, Modula, BASIC) aux plus spécialisés (Lisp, Forth, Logo) en passant par quelques hybrides intéressants (Draco, E), tous les langages informatiques sont représentés. Si le réseau commercial traditionnel fournit les meilleurs compilateurs, le domaine public n'est pas en reste. D'ailleurs, il est même arrivé que certains environnements de développement initialement placés dans le domaine public se retrouvent finalement vendus dans le commerce. DICE de Matthew Dillon en est le meilleur exemple. Donc, pas de panique, quel que soit votre langage de prédilection, vous trouverez toujours un compilateur spécifique.

Le C

A tout seigneur tout honneur, commençons par le langage le plus utilisé, et pas seulement sur Amiga. Depuis que messieurs Kernighan et Ritchie l'ont inventé, son "ascension" a été fulgurante. Peut-être est-ce dû au fait que ses auteurs l'ont également utilisé pour écrire le système d'exploitation Unix ? En tout cas, les faits sont là : de nos jours, pas un programmeur professionnel ne saurait se passer du C. Sa dernière évolution, le C++, en fait un langage orienté objet très utilisé sur les grosses plates-formes. Moins sur Amiga cependant, où il n'existe toujours pas de vrai compilateur C++, mais seulement des préprocesseurs transformant le code C++ en code C standard.

SAS/C

Ex-Lattice, le SAS est sans doute actuellement le meilleur environnement de développement en C qui existe sur notre Amiga. C'est d'ailleurs lui qui a été utilisé par les ingénieurs de chez Commodore lors de la refonte totale du système d'exploitation nécessaire au passage du 1.3 vers le 2.0.

SAS/C
SAS/C

Le SAS/C en est actuellement à sa version 6.52, autant dire qu'il n'est pas né d'hier. Il se compose d'un éditeur, d'un préprocesseur, d'un compilateur, d'un éditeur de liens, d'un débogueur source et de plusieurs utilitaires aussi divers que variés, dont un "make" extrêmement puissant. De plus, il inclut un système d'aide au format AmigaGuide extrêmement pratique, qui, couplé aux Autodocs de Commodore, permet de toujours avoir sous les yeux un descriptif des fonctions du système et des bibliothèques du compilateur.

Même s'il ne s'agit pas d'un véritable environnement intégré comme on peut en trouver sur d'autres plates-formes (ahhh, le Borland C...), tous ses éléments sont "reliés" entre eux via ARexx, et se comportent comme s'il ne s'agissait que d'un seul et même programme : le compilateur détecte une erreur ? Aussitôt, l'éditeur se positionne sur la ligne concernée. En fait, ce qui pourrait à priori ressembler à un gros défaut se transforme rapidement en un plus extraordinnaire. Par exemple, nombreux sont les utilisateurs du SAS/C qui ont remplacé le peu pratique SE (l'éditeur fourni dans le paquet) par CED de Great Valley Products, nettement plus efficient : celui-ci étant également compatible ARexx, le lien éditeur/compilateur/débogueur original est de fait conservé intact.

SAS/C
Le débogueur SAS/C

Le compilateur est quant à lui très efficace. Il s'agit d'un compilateur deux passes classique, à ceci près qu'il présente la particularité d'être implémenté sous forme de deux bibliothèques partagées (sc1.library et sc2.library). L'avantage de ce système n'est peut-être pas évident de prime abord, mais il permet de minimiser les accès disque lors des compilations (il faut toutefois posséder une machine munie de beaucoup de mémoire, c'est-à-dire au moins 8 Mo, pour en profiter). De plus, cela autorise une mise à jour aisée et rapide du compilateur, les nouvelles versions des bibliothèques étant offertes en téléchargement sur la plupart des BBS.

Le code produit est généralement de bonne qualité, à condition toutefois d'activer l'optimisateur. Sans cela, des instructions redondantes, voire parfaitement inutiles, sont parfois générées. En contrepartie, l'optimisateur rallonge les temps de compilation. Que voulez-vous ? On ne peut pas tout avoir à la fois...

Le plus gros "morceau" du SAS est sans conteste Code-Probe, le débogueur source. Il est capable de suivre l'exécution d'un programme instruction par instruction, aussi en C que directement en Assembleur. Il gère les points d'arrêt conditionnels ou non, la surveillance en temps réel des variables (l'affichage est réactualisé après chaque instruction exécutée), la recopie du contenu des structures et unions propres au C, et possède un jeu de commandes puissantes qui, additionnées à celles d'ARexx, le rendent extrêmement efficace. Dommage cependant que plusieurs bogues ennuyeux (pour un débogueur, c'est tout de même un comble !) rendent parfois certaines fonctions inexploitables... Sachez pour en finir avec CodeProbe, qu'une version spéciale en est également fournie, qui permet le débogage à distance d'un Amiga par un autre Amiga.

A noter que contrairement à ce qui se passait avec ses premières versions, le SAS peut maintenant aussi bien être utilisé depuis le Workbench que depuis le Shell, sans aucune perte de ses fonctionnalités ni de sa puissance. En fait, il est carrément plus accessible et agréable depuis le Workbench !

Aztec C

Produit par la société Manx, l'Aztec n'est pas non plus tout jeune. Il a longtemps été le plus féroce concurrent du Lattice, avant de se laisser distancer, peu de temps après la sortie de sa version 5.0. Et pourtant, ce ne sont pas les qualités qui lui manquent. Il possède exactement les mêmes atouts que le Lattice (mais pas que le SAS, attention, ne confondez pas), dont l'utilisation des pramas (pour le passage des paramètres par les registres plutôt que par la pile), la gestion d'ARexx, etc.

Son plus gros défaut est de considérer par défaut les entiers (int, en C) sur 16 bits au lieu de 32, ce qui peut poser des problèmes avec certaines fonctions du Kickstart, mais cela peut s'arranger par une simple option de la ligne de commande. Par contre, le code produit dans ce cas est légèrement moins efficace. Des programmes comme Professional Page, pour ne citer que lui, ont été développés avec ce système.

Le paquet de l'Aztec C inclut un débogueur source très puissant dans lequel, contrairement au SAS, je n'ai pu rélever aucune bogue particulièrement gênant. Cependant, son utilisation reste nettement moins conviviale que celle de CodeProbe.

En fait, si l'on me donnait à choisir entre le SAS et le Manx, j'opterais sans hésiter pour le premier, d'une part pour la qualité du code produit (même s'il n'est pas toujours parfait), et d'autre part pour celle de l'environnement de développement. Pour les programmeurs débutants, c'est un véritable régal. Les "vieux habitués" quant à eux préféreront peut-être l'environnement Shell du Manx.

DICE Pro

DICE (fringant acronyme de Dillon Integrated C Environment) est un outil particulièrement intéressant. Son auteur, Matt Dillon, en distribuait les premières versions en partagiciel, une version bridée étant quant à elle placée dans le domaine public (bref, il fallait s'enregistrer dans les fichiers de l'auteur pour recevoir une version pleinement exploitable). Par la suite, et devant le succès de ce compilateur, DICE est rapidement devenu un produit purement commercial.

DICE Pro
Options de compilation de DICE Pro

Ce succès est plus particulièrement dû à deux de ses qualités : d'une part, Matt Dillon assurait une assistance très pointue auprès de ses utilisateurs enregistrés, et d'autre part, le compilateur produisait (et produit encore !) un code objet extrêmement optimisé.

Aujourd'hui, DICE en est à sa version "Pro", et ce n'est pas la moindre des choses, on pourra bientôt se procurer une version française par l'intermédiaire de la société Someware, peut-être même au moment où vous lirez ces lignes (rappelons qu'aussi bien le SAS/C que l'Aztec restent désespérément anglophones). Le paquet de DICE inclut tous les outils classiques pour un compilateur C : un éditeur dédié (le fameux DME qui fut longtemps une référence en la matière), un assembleur, un éditeur de liens, un débogueur source et un "make", ou plutôt un Visual Make, entièrement sous Intuition, ce qui facilite énormément la gestion des gros projets. Entièrement pilotable par ARexx, DICE Pro est compatible avec toutes les versions du Workbench et dispose des includes 3.1 de Commodore.

L'Assembleur

Si le C permet de programmer facilement le système multitâche de l'Amiga, l'Assembleur s'impose dès que l'on souhaite s'en passer ou bien optimiser certaines fonctions. Les deux domaines les plus directement concernés par ce langage sont bien évidemment les jeux et les démos, mais l'Assembleur peut également être préféré pour de petits projets, ou pour des routines à lier à un programme plus conséquent. En fait, tout programmeur un peu sérieux devrait connaître l'Assembleur, quel que soit son langage de prédilection.

Devpac

Et si je vous disais que les toutes premières fois que j'ai eu à faire au Devpac, c'était sous système CP/M, sur un... MSX, puis un Amstrad CPC 6128, le croiriez-vous ? Et pourtant, c'est vrai ! Par la suite, HiSoft a su profiter du succès de l'Atari ST pour adapter son logiciel au 68000 (une excellente version, soit dit en passant), avant de le porter sur Amiga. Évidemment, le Devpac d'aujourd'hui n'a strictement plus rien en commun avec son illustre ancêtre 8 bits, mais tout de même, cela fait chaud au coeur de voir un programme survivre au temps de cette manière...

Devpac 3.01
Devpac 3.01

Devpac Amiga en est aujourd'hui à sa version 3.04, laquelle est indispensable si vous possédez un Amiga 4000/40 (la version précédente du débogueur, la 3.02, ne fonctionnait pas avec un 68040). Le paquet inclut un éditeur, un macro-assembleur deux passes, un débogueur source et un éditeur de liens. L'éditeur est simple, sans prétention, mais parfaitement adapté à l'écriture de sources Assembleur. Certes, et c'est sans doute là son plus gros défaut, il n'est pas compatible ARexx, mais il est multiprojet et multivue (c'est-à-dire qu'il permet de travailler sur plusieurs fichiers à la fois, et d'avoir plusieurs fenêtres affichant différentes vues d'un même fichier). De plus, il est rapide et peu gourmand en mémoire. Personnellement, je l'utilise aussi pour toutes les tâches qui ne nécessitent pas l'emploi d'un traitement de texte (édition de la startup-sequence, etc.).

Bien que le Devpac ne soit pas un vrai environnement intégré, on peut assembler un programme directement depuis l'éditeur. En cas d'erreur dans le source, l'éditeur se positionne automatiquement sur la ligne fautive. L'assemblage peut se faire soit sur disque, soit en mémoire, une option très pratique qui accélère grandement l'opération. GenAm (c'est le nom de l'assembleur) reconnaît les instructions de tous les processeurs de la gamme 68000 jusqu'au 68040, y compris les coprocesseurs arithmétiques 68881 et 68882 et la MMU 68851, et peut produire indifféremment un programme exécutable ou un fichier objet. Cette dernière possibilité est d'ailleurs très intéressante, puisqu'étant indépendant de l'éditeur, il peut être appelé depuis un script Shell ou un fichier Make, par exemple dans le cadre d'un gros projet. L'éditeur de liens fourni par HiSoft étant BLink, une version domaine public de l'ancêtre de SLink du SAS/C, il peut parfaitement s'intégrer à un projet écrit avec ce compilateur.

Reste le débogueur, j'ai nommé MonAm. Bien que très puissant, c'est certainement le moins convivial des trois outils composant le Devpac. Son interface utilisateur ferait rire même le plus stupide des programmeurs sous MS-DOS. Cependant, on s'y fait assez rapidement, à tel point qu'il m'arrive souvent de l'utiliser pour déboguer des programmes écrits en C !

Seka

L'histoire du Seka n'est pas triste non plus. A ma connaissance, sa première version date de la grande époque de l'Atari ST, où, pour une raison qui m'échappe encore, il était extrêmement utilisé par les demomakers. Lent, peu convivial, doté d'un éditeur à la limite du ridicule (même Ed du Workbench 1.3 était meilleur !), il a cependant fait les beaux jours (et les beaux programmes) de nombreux programmeurs.

La première version Amiga n'était d'ailleurs pas franchement meilleure, mais là encore, les demomakers se sont précipités dessus. Certains sont même allés jusqu'à le réécrire, ce qui fait qu'on en trouve plusieurs versions différentes, signées de multiples auteurs. Aux dernières nouvelles que j'ai pu en avoir, le Seka gérait les fichiers includes et la définition de macro-instructions, ce qui, de nos jours, est tout de même la moindre des choses pour un Assembleur.

Le Seka n'est cité ici que par souci d'exhaustivité, car même si la version commerciale n'est plus disponible depuis longtemps, il est encore possible de s'en procurer une de ces versions "personnalisées" qui elles, sont dans le domaine public (on les trouve en général sur les compilations d'utilitaires réalisées par les groupes de demomakers).

Le BASIC

Le BASIC a longtemps été considéré, à juste titre d'ailleurs, comme "le langage des débutants en programmation". Facile à apprendre, disposant d'instructions puissantes, et surtout interprété (par opposition aux langages compilés), il est effectivement parfaitement adapté à l'initiation à la programmation et à la réalisation rapide de petits programmes complets. Comme tous les autres langages, il a su évoluer au fil du temps : les numéros de lignes ont disparu ou sont devenus optionnels (l'instruction GOTO n'est presque plus utilisée !), il permet de gérer des structures complexes comme en Pascal ou en C, et il peut être compilé pour produire un programme exécutable indépendemment de l'interpréteur.

AMOS

Bien qu'édité par l'anglais Europress Software, AMOS est l'oeuvre d'un Français bien de chez nous : François Lionet. Dans ses premières versions, ce BASIC était plus spécialement destiné à la création de jeux, grâce à des instructions dédiées à la gestion de sprites, BOB et autres objets graphiques du même acabit. Il n'en restait pas moins un BASIC assez classique, qui permettait également la création d'applications plus sérieuses (on a d'ailleurs vu des bases de données, des gestions bancaires, etc. programmées en AMOS).

Le seul reproche que l'on puisse lui faire est de ne pas s'intégrer au système multitâche de l'Amiga : par exemple, AMOS n'utilise pas du tout les écrans, fenêtres, menus et gadgets d'Intuition, mais dispose à la place de son propre système. Ceci est certes nécessaire pour permettre la création de jeux dignes de ce nom (la vitesse d'exécution étant effectivement primordiale), mais en même temps, cela le restreint presque inévitablement à ce domaine particulier (bien que plusieurs groupes de demomakers et non des moindres aient également adopté ce langage !).

Après un petit détour par le bas avec Easy AMOS (une version allégée spécialement dédiée aux novices en programmation), AMOS est remonté vers le haut avec AMOS Professional, une version plus musclée comprenant de nombreuses nouvelles instructions, un sous-langage spécialement dédié à la création d'interfaces graphiques dignes de ce nom (mais hélas toujours pas sous Intuition), un système intégré d'hypertexte, un puissant débogueur et bien d'autres choses encore. Malheureusement, AMOS Pro est sorti peu de temps avant l'avènement des Amiga AGA, et bien qu'il soit (partiellement) compatible avec ceux-ci, il ne sait pas en exploiter toutes les subtilités (notamment l'affichage en 256 couleurs). Une version gérant les modes AGA est certes promise depuis longtemps par Europress, mais Soeur Anne ne voit toujours rien venir...

AMOS Pro
AMOS Pro

Blitz Basic

En fait, le Blitz Basic a justement profité de la faiblesse d'AMOS concernant le jeu de composants AGA pour s'imposer comme nouveau BASIC à la mode sur Amiga. D'origine néo-zélandaise, le Blitz Basic est relativement déroutant au premier abord, surtout pour ceux habitués à une version plus classique du langage. En fait, il s'apparente plus à une espèce de gros Assembleur disposant d'instructions particulières qu'à un véritable BASIC, même s'il en reprend les constructions les plus élémentaires (PRINT, boucles FOR... NEXT, instructions conditionnelles IF... THEN... ELSE, etc.). L'intention des auteurs du Blitz Basic était de donner au programmeur un maximum de contrôle sur sa machine, tout en gardant la simplicité du BASIC. Ce but n'est cependant qu'à moitié atteint, car côté simplicité, il reste encore quelques efforts à faire...

Blitz Basic
Blitz Basic 2.1

L'un des plus gros points forts du Blitz Basic est sans nul doute de laisser le libre choix entre une programmation système respectant totalement le multitâche (idéale pour la création d'applications "sérieuses") et une programmation directe du matériel (idéale pour les jeux, démos, etc.). Son deuxième point fort est d'être compatible avec les modes AGA et de permettre d'en exploiter toutes les ressources. Et son troisième point fort est d'inclure le compilateur dans le paquet d'origine, par opposition à celui d'AMOS, vendu séparément (d'ailleurs, le Blitz Basic a ceci d'original qu'il ne fonctionne pas en mode interprété, mais uniquement compilé !).

Les autres langages

On trouve sur Amiga bien d'autres langages de programmation. On pourrait par exemple citer le Pascal, le Modula II ou encore le Forth, pour lesquels des compilateurs existent tant dans le commerce que dans le domaine public. Malheureusement, leur diffusion en France est plutôt restreinte, et il est assez difficile de se les procurer (au grand dam des étudiants en informatique, d'ailleurs).

ARexx

ARexx est certainement le langage de programmation le plus directement accessible à tout un chacun, puisqu'il est livré par Commodore avec le Workbench (depuis la version 2.0 du système, pour être précis). Il s'agit d'un langage interprété, au même titre que le BASIC, mais dont le but est totalement différent.

ARexx peut être apprécié de deux points de vue : dans le premier, c'est un langage d'écriture de scripts, comparable à un véritable BASIC. Mais ce n'est pas là son intérêt le plus évident, puisqu'ARexx peut égale-ment être utilisé en tant que langage de macro-commandes par de nombreuses applications (de plus en plus nombreuses applications) : dans un traitement de texte, par exemple, on pourra écrire une macro ARexx qui effectuera une mise en page type (titres, sous-titres, etc.).

Plus fort encore, ARexx peut même permettre à plusieurs applications de communiquer entre elles ! Par exemple, dans Professional Page, un "Génie" (c'est le nom des macros de Professional Page) exécute Art Department Pro, et lui transmet l'image bitmap de la boîte courante, à des fins de modification, d'ajout d'effets, etc.. Lorsque l'utilisateur en a terminé avec l'image, le Génie la réimporte automatiquement dans Professional Page.

ARexx est un langage unique et très pratique, que tout utilisateur d'Amiga devrait sinon maîtriser, au moins connaître.

Amiga E

Le choix de ce langage n'est pas totalement innocent, le E commençant à s'imposer chez plus en plus de programmeurs à la recherche d'un langage puissant et s'intégrant au multitâche, tout en restant simple à apprendre. Distribué dans le domaine public, le E se présente comme un hybride de trois autres langages, à savoir le C, le Pascal et le BASIC, dont on n'aurait gardé que les qualités, en excluant bien méticuleusement les défauts.

C'est un langage structuré, sans numéro de lignes, offrant une gestion directe des fonctionalités du système (Intuition, Exec, etc.). Comme le C ou le Pascal, il oblige à déclarer les variables avant leur utilisation, mais comme le BASIC, il possède des instructions simples, facilement accessibles aux débutants.

Le compilateur E traite des fichiers ASCII écrits avec n'importe quel éditeur, mais, revers de la médaille, il ne s'utilise malheureusement que depuis le Shell. Cela dit, avec quelques scripts AmigaDOS ou ARexx de derrière les fagots, on arrive à se créer relativement facilement un environnement de travail presque idéal.

Si vous êtes à la recherche d'un premier langage de programmation sur Amiga, jetez donc un oeil sur le E, vous risquez d'être convaincu. Et même si vous avez déjà de l'expérience dans ce domaine, tentez tout de même l'expérience : après tout, au prix du partagiciel, vous ne risquez pas grand chose.

Le DevKit

Voici une acquisition que toute personne désirant programmer sérieusement sur Amiga devrait envisager. Le DevKit de Commodore, actuellement en version 3.1, est un jeu de plusieurs disquettes contenant tous les fichiers includes (C et Assembleur) propres au système, les indispensables bibliothèques reliables amiga.lib et debug.lib (tous ces éléments sont normalement fournis avec votre compilateur C ou votre Assembleur, mais peut-être pas dans leur dernière version), les fameux Autodocs (une documentation des fonctions du Kickstart au format hypertexte AmigaGuide), et surtout une foultitude d'utilitaires de débogage, dont les plus connus sont Enforcer, Sushi, Wack, ou encore MemWall.

L'intérêt du DevKit est surtout d'être régulièrement mis à jour par Commodore à chaque nouvelle version du système d'exploitation. De plus, il précède, souvent de beaucoup, la publication des Amiga ROM Kernal Manual, ces véritables "bibles" de l'Amiga, elles aussi indispensables à tout projet de développement sérieux. Actuellement, la version 3.1 du DevKit (correspondant au Kickstart et Workbench version 40) est distribuée en France par Someware.

Le domaine public

Quoi de plus logique, le domaine public est une source intarissable de bienfaits pour le programmeur, qu'il soit en herbe ou chevronné. On y trouve de tout, depuis l'utilitaire dont on se demande comment on a pu s'en passer avant, jusqu'aux exemples de listings sources dans les domaines les plus variés et les langages les plus exotiques.

Citer ici toutes les productions du domaine public ayant trait à la programmation serait purement suicidaire de ma part. Sachez simplement que dans la majorité des cas (sans me mouiller, j'irais jusqu'à 90%), le domaine public est l'endroit idéal où trouver la solution à vos problèmes de programmation, quels qu'ils soient.


[Retour en haut] / [Retour aux articles]