Suivez-nous sur X
|
|
|
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
|
|
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
|
|
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
|
|
A propos d'Obligement
|
|
David Brunet
|
|
|
|
Dossier : Les langages de programmation sur Amiga et Atari ST (1988)
(Article écrit par Ivan Roux et extrait de Tilt Hors Série - mars 1988)
|
|
Programmer un Atari ST ou un Amiga après avoir possédé un Amstrad ou un C64 revient assez à piloter une
Ferrari en sortant d'une deux-chevaux... Faut-il alors être un surdoué du clavier, un Mozart de la ligne de
code ? Pas forcément : l'amateur ou le débutant trouveront sur les deux machines des langages de programmation
adaptés à leurs besoins et à leurs talents...
La vague des ordinateurs 16/32 bits a entraîné dans son sillage une nouvelle génération de langages.
Prédit à une mort lente, BASIC fit peau neuve et franchit le cap. Pascal figure toujours à l'affiche et
garde ses fidèles. C a les honneurs et la bénédiction des développeurs. Lisp et Prolog talonnent le
peloton. Et l'assembleur reste l'ultime recours pour pénétrer dans les entrailles des machines, ST comme
Amiga. Dans sa musette, le programmeur atarien a tout. Des disquettes BASIC, assembleur, C, Pascal, Modula 2,
Logo, Forth, etc. En fouillant, on découvre avec surprise plusieurs versions d'un même langage.
Jetons en vrac les denrées sur le bureau et faisons le compte. Pas moins de quatre BASIC, quatre C, quelques Pascal,
autant d'assembleur. Ouf ! De quoi satisfaire les appétits et programmer tous les types d'applications. Le
programmeur Amiga est moins chanceux et doit se contenter d'une douzaine de langages toutes versions confondues.
En consultant le catalogue des logiciels, on a l'impression qu'ils se bousculent au portillon. Aux États-Unis, peut-être.
On y trouve tout. Mais en France, c'est la pénurie à cause des aléas de l'importation. Notons que certains langages,
comme Pascal, existent sous deux appellations : Amiga Pascal et MCC Pascal. Ils sont identiques, à l'emballage près.
Combien de machines, dans le passé, ne disposaient que d'un maigre BASIC, d'un embryon de Logo et c'est tout.
De ce point de vue, le ST ratisse large. C'est une machine idéale pour sortir des lignes de codes dans la joie
et le confort. En effet, doté d'un processeur 68000 Motorola (Amiga aussi) et d'une mémoire confortable (512 ko
minimum), on n'est plus forcé de gérer la mémoire à l'octet près. Et les logiciels tournent à bonne vitesse.
Certains répondront que l'on peut faire mieux. D'accord. Mais la comparaison s'entend avec les ordinateurs 8
bits de l'époque héroïque.
Il est utile de remarquer que l'accès aux routines de GEM et de Workbench, les intégrateurs graphiques respectifs des
ST et Amiga, est possible à partir de certains langages. De cette façon, la création des fenêtres, des boîtes de
dialogue et menus est grandement facilitée et vos programmes auront un cachet "pro". Avant de passer en revue
quelques-uns des langages directement exploitables sur les machines, notons que l'emploi d'émulateurs (PC et Macintosh)
permet de travailler avec les logiciels de ces marques. Exemple : Turbo Pascal de Borland fonctionne sur Atari, plus
lentement que sur un PC, mais sûrement.
GFA Basic, créé par un jeune Allemand de 26 ans, est un modèle du genre.
Le STOS, nouveau venu sur le marché, va-t-il réussir à le détrôner ?
Si je vous dis qu'il existe, sur Atari ST, un BASIC sans numéros de ligne, admettant les procédures avec passage
de paramètres, vous répondez, sans l'ombre d'un doute : GFA Basic. Pour la petite histoire, il a été créé
par Frank Ostrowski, un jeune Allemand de 26 ans. Il réécrit pour son usage personnel les routines de l'interpréteur
BASIC sur Atari 400.
Publié dans un magazine, son programme est remarqué par la firme GFA qui lui propose de développer un nouveau
BASIC pour ST. Nous sommes loin des états-majors de Microsoft ou de Borland, mais le résultat est là : GFA est
un modèle du genre. Deux raisons majeures expliquent son succès. Sa rapidité d'exécution et son environnement
(le compilateur, les ouvrages consacrés).
Au départ, l'auteur du langage s'est posé la question suivante : qu'est-ce qui ralentit un programme ?
Voyons, à l'aide d'exemples simples, quelques éléments de réponse. Dans un programme, on utilise fréquemment
des compteurs, simples variables dont on augmente ou diminue la valeur. En BASIC classique, cela correspond à
"X=X+1". L'équivalent en GFA Basic est "INC X" qui est exécuté plus vite.
En effet, la première formule cherche X et l'additionne à la valeur de l'incrément (ici égal à 1), puis le
résultat est rangé dans X. La seconde incrémente X directement. Voyons le passage de paramètres à un sous-programme,
impossible à réaliser en BASIC "papi". Il faut, avant d'appeler la routine, recopier les variables à "passer"
dans les variables traitées par la routine. Au retour, on recommence l'opération en sens inverse afin de les mettre
à jour.
Que de temps perdu à cause de ces transferts inutiles ! Au bas mot, quelques millièmes de seconde. En GFA, il suffit
de donner le nom de la routine (ou procédure) et la liste des paramètres. Exemple : "ECRIS_NOM (10, Toto)"
écrit le mot "Toto" en ligne 10. On retrouve ici un brin de Pascal mais la comparaison s'arrête là. Cependant,
d'autres BASIC connaissent les procédures, ce n'est pas une exclusivité. GFA se distingue, aussi, par un appel
simple des routines du système d'exploitation. Plus besoin d'aller se perdre aux confins de la mémoire (et d'y rester
planté), il se charge de l'affaire. On spécifie le nom de la routine à activer ainsi que les valeurs dont elle a
besoin.
Oui, mais où trouver tous les renseignements ? Il existe plusieurs ouvrages édités par Micro Application, bien
documentés et lisibles, même par le néophyte. Vous y trouvez les réponses à toutes sortes de problèmes et des
disquettes bourrées d'exemples sont fournies en prime. Le dernier atout de ce BASIC, et non des moindres, est
le compilateur. Cet utilitaire, vendu à part, traduit votre programme chéri en quelque chose qui ressemble à
du langage machine. L'intérêt de la manipulation est d'accroître la vitesse et le programme compilé peut être
lancé directement à partir du bureau, sans avoir recours à l'interpréteur.
Les gens de GFA ont une telle confiance en leur langage qu'ils sortent des logiciels (toute la gamme GFA Draft,
Artist, Vector, etc.) écrits en BASIC. C'est une preuve, sinon un indice, de fiabilité et de qualité. Même si,
à l'usage, on tombe sur quelques beaux bogues.
Restons encore avec BASIC pour saluer l'arrivée d'un nouveau venu :
le STOS de Jawx-Cédic Nathan. Il s'agit d'un nouveau système d'exploitation pour ST composé d'utilitaires,
d'un macro assembleur et d'un BASIC. Les commandes du système ressemblent étrangement à celles de MS-DOS.
Faut-il comprendre que les PC lorgnent sur Atari ? Allez savoir... Évidemment, STOS n'a nul besoin de GEM
et dispose de son propre intégrateur graphique. Côté BASIC, quoi de neuf ? Il respecte la tradition. Numéros
de lignes, syntaxe proche de Microsoft (tiens tiens, encore un clin d'oeil d'IBM). À propos des numéros de lignes,
est-ce une bonne idée de les garder en plus des labels ? "Gosub Vide_tes_poches" est plus parlant que
"Gosub 3500". Cela dit, "Delete 1000-2000" est plus simple que de balader la souris dans les écrans.
STOS Basic permet de composer à quatre mains, c'est-à-dire d'éditer quatre programmes simultanément. Les instructions,
très nombreuses, couvrent tous les domaines : musique, graphisme, entrées-sorties. Tapez "BOOM" puis "BELL"
et vous obtiendrez une explosion suivie d'un son de cloche. Plus sérieusement, l'instruction "SCREEN COPY"
est tout à fait intéressante. Comme son nom l'indique, elle permet de transférer des portions d'écrans. Avec
un peu d'idée, on peut créer des défilements et des masquages puisque les déplacements sont quasi instantanés.
STOS Basic gère la mémoire sous la forme de banques. Ce sont des espaces alloués dans lesquels vous mettez ce que
bon vous semble, par exemple des images, des musiques ou des routines en assembleur. Ces banques sont intégrées
au programme et sont sauvées avec le texte source. Au lieu de créer un fichier indépendant pour stocker l'écran de
présentation, déclarez-le en banque, c'est beaucoup plus simple. Le système complet est trop récent pour présager
de son avenir. En tout cas, il mérite que l'on fasse attention à ses extensions futures. Entre autres, un compilateur.
Amiga n'a pas moins de trois BASIC répertoriés sous les noms de True, AC et AmigaBasic. Ce dernier est facile à
trouver puisqu'il est livré avec la machine. A l'instar de GFA sur Atari ST, ils vous dispensent du numérotage des
lignes et admet le passage de paramètres aux sous-programmes. L'instruction "Call"
suivie du nom et de la liste de valeurs appelle la routine correspondante définie par "Sub"
et "Endsub". Néanmoins, vous pouvez vous servir du "Gosub" traditionnel mais il présente en fait peu d'intérêt.
Sur Amiga, un BASIC riche et performant ouvre la porte à des réalisations sophistiquées
L'Amiga parle et le BASIC ne l'a pas oublié. Tapez "Say dhihs ishs bhasikh" et vous entendrez John Wayne répondre
"This is BASIC". Si le charabia phonético-yankee vous rebute, l'instruction "Translate$" convertit pour vous
les mots anglais en phonèmes. Sur ce sujet le manuel est prolixe. Il consacre une annexe entière à décrire comment
obtenir différentes intonations, et accentuations, etc. Le son sans l'image, c'est comme les pâtes sans beurre.
Passons à table et goûtons l'éditeur Object. Cet utilitaire d'animation, fourni avec le BASIC,
permet d'intégrer des séquences d'images dans les programmes. Après avoir défini votre objet (à l'écran),
vous sauvez ses attributs de taille et de couleur dans un fichier. Puis, à partir du programme, vous le
chargez. A l'aide d'instructions spécifiques, vous générez les animations. Un vrai régal pour l'oeil !
Ce BASIC est riche et performant. La grande variété des instructions soulage le programmeur en lui évitant
l'écriture de routines inutiles.
Choisir un assembleur ? Pas facile... Quel est le meilleur ? Le plus rapide ?
Le plus facile à utiliser ?
Les parties de programme qui doivent être impérativement très rapides (comme l'animation de dessins) sont,
la plupart du temps, écrites en assembleur. On confond généralement les termes "langage machine"
et "assembleur". Le premier désigne le code binaire, découpé en mots de 16 bits, exécutable par le processeur.
Le second est un programme dont le but est de créer ce code à partir d'un fichier-texte source. Il
passe au crible les mnémoniques et les paramètres associés, et assemble (d'où son nom) le tout pour donner
le programme exécutable. Auparavant, vous avez tapé votre programme à l'aide d'un éditeur qui est, ni plus ni
moins, un banal traitement de texte. En fait, il n'y a pas, pour une machine donnée, un assembleur meilleur qu'un
autre. Disons que certains assemblent plus rapidement et offrent des commodités. Mais ils présentent, en
gros, les mêmes fonctions.
STOS, encore lui, et Profimat de Data Becker sont deux assembleurs ST bien sous tous rapports. Ils permettent
d'insérer des macro-instructions dans le code source et, surtout, l'assemblage conditionnel. Résultat :
on peut n'assembler que certaines parties en plaçant des "IF" suivis de conditions. La fin de la partie est
marquée par "ENDIF". Les commandes classiques de chaînage et de recopie du contenu de la mémoire ("dump",
visualisation de la mémoire en nombres) sont présents. Ces deux produits sont réservés aux utilisateurs avertis.
Sur Amiga, pas besoin d'éditeur-assembleur externe. En effet, AmigaDOS dispose de son propre éditeur.
Pour y accéder, il faut être sous CLI, le langage de commande du système, et taper "ED nom de fichier".
Il est rudimentaire et franchement rébarbatif à utiliser. Mais il existe un second éditeur, Micro-Emacs,
présent sur la disquette Basic Extras. Beaucoup plus simple d'emploi, il permet de créer des fichiers-sources
assembleur, C, Pascal, etc. La commande du CLI permettant l'assemblage est "ASSEM" suivie des noms de fichiers
(source et objet) et de paramètres optionnels. Cet utilitaire accepte les macros. En revanche, il n'autorise pas
l'assemblage conditionnel. Mais ce n'est pas vraiment dramatique. AmigaDOS inclut un grand nombre de modules
utilitaires. Ajoutons l'éditeur de liens "ALINK" pour "lier" les différents codes sources et bibliothèques de routines.
En définitive, quand on achète un Amiga, on dispose du BASIC et de l'assembleur. C'est toujours ça de pris.
Destiné à l'écriture de langages évolués, le C convient aussi à l'écriture des jeux...
Le langage C est omniprésent sur Atari ST et Amiga. Il a même servi à l'écriture de GEM et du système (TOS), le logiciel
de base de la machine. Il existe trois compilateurs C pour ST : Lattice C, Megamax et Mark Williams. Amiga compte
l'Aztec C et Lattice. Ils fonctionnent à merveille, avec des différences (temps de compilation, optimisation du code, etc.)
et sont plutôt réservés aux programmeurs chevronnés. Pour les autres, Loriciels édite un interpréteur C (IC)
qui a l'avantage de ne coûter que 390 FF mais l'inconvénient de ne pas correspondre à la norme définie par Kernighan
et Ritchie (les gourous du C).
Quelques mots de généralités. C est plutôt destiné à l'écriture de systèmes d'exploitation, de langages évolués ou
autres applications requérant une très grande vitesse d'exécution et un minimum de place mémoire. Il convient aussi
à l'écriture de jeux. En fait, il piétine les plates-bandes de l'assembleur jusqu'ici réservé à ces types de programmes.
On dit souvent que C est proche de l'assembleur. C'est vrai si l'on considère que le code généré à la compilation est
compact et exempt de lourdeurs. Mais C ressemble, dans sa forme, à un langage évolué de type Pascal.
L'élément fondamental est la fonction (équivalent à une procédure). Mises bout à bout, imbriquées ensemble, elles
forment le programme. Notons la présence de différents types de variables numériques, réels et entiers.
Cependant, il est préférable de travailler avec des entiers plus simples à traiter, donc plus économiques.
Les langages compilés, c'est bien mais pas pratique à modifier. Il faut reprendre le programme source, corriger le
texte puis le recompiler, etc. Patience et longueur de temps... D'où la bonne idée de proposer un interpréteur C.
Profitons de l'aubaine et observons d'abord ses mérites. Il dispose d'une "boîte à outils", la bibliothèque de fonctions
accédant à GEM. La liste se trouve dans le manuel et est bien commentée. L'éditeur pleine page est soigné. Il admet la
souris pour se déplacer dans le texte et détecte certaines erreurs de syntaxe à la saisie. Quand on ouvre l'accolade
d'un bloc, il place automatiquement l'accolade fermante sur la ligne du dessous. Maintenant que nous avons écrit quelques
lignes de programme, faisons-le tourner. Clic sur l'option "Execute" (le RUN local). Aie ! Erreur numéro machin. Un
coup d'oeil sur le programme, le coupable est repéré et châtié. C'est reparti pour un tour. Et ça marche ! La suite
des carrés de 1 à 20 s'affiche. La modification du programme a duré quelques secondes. Avec un compilateur, il aurait
fallu attendre de longues minutes.
Passons aux défauts. Ajoutons un Scanf(i) à la suite du listing et voyons le résultat. Il n'est pas beau du tout :
quatre sympathiques bombes m'indiquent que je viens d'atterrir dans la salle d'accueil de l'Atari ST, le bureau GEM.
C'est franchement frustrant d'être éjecté de l'interpréteur de cette façon. Les programmes écrits avec IC
sont compilables avec Lattice (et d'autres ?). En effet, il sauve les fichiers soit dans son format propre, soit en
ASCII. Aucun problème pour récupérer ces derniers. Soyons juste avec IC : son prix défie toute concurrence. Il
est parfait pour apprendre sans contrainte et pour écrire de petites choses. Le passage dans la cour des professionnels
reste encore hypothétique.
Le langage Pascal est tout indiqué pour s'aventurer dans la programmation structurée. L'usage du "goto"
y est proscrit, adieu aux programmes-spaghettis truffés de branchements. Pascal impose des règles strictes.
Toutes les variables et données doivent être déclarées avant d'êtres utilisées. Le programme est articulé
en blocs de procédures et de fonctions. Chacune est identifiée par un nom, afin de pouvoir être appelée de l'extérieur,
et contient plusieurs instructions.
Suivant la valeur des paramètres fournis à la procédure, elle effectue telle action ou telle autre. Les
"boîtes" ne sont pas reliées entre elles par des fils (les branchements), mais elles sont empilées et
imbriquées les unes dans les autres. L'idée de Niklaus Wirth, le créateur de Pascal, est de favoriser
l'étude du problème, l'algorithmique, avant de se précipiter, sans réflexion préalable, sur son clavier.
Le raisonnement précède l'écriture du programme proprement dit.
En BASIC, on a souvent tendance à négliger la réflexion pour aller vite. Résultat : programmes lourds,
illisibles qui marchent suivant l'humeur et la météo. Avec Pascal, on peut tout faire à condition d'y
réfléchir avant. En plus, c'est un langage compilé. En cas d'erreur, on fait la navette entre éditeur
et compilateur.
Un Pascal riche et puissant, idéal pour développer des applications sérieuses
et professionnelles...
Le Personal Pascal d'OSS (Optimized Systems Software) pour ST est très avantageux. La documentation (en anglais),
détaillée et complète, fournit une liste de nombreuses procédures utilisant les ressources de GEM. Cette bibliothèque
de routines, prête à l'emploi, facilite grandement la création de graphismes, de fenêtres et de menus.
L'option de débogage permet d'afficher, durant la compilation, l'endroit défaillant, et déclenche le retour direct
à l'éditeur.
Ce dernier est un peu rudimentaire, il ne fonctionne pas avec la souris. "Help"
affiche les commandes de déplacement et de sauvegarde du texte. L'appui sur la touche de fonction
"F9" sauve le texte courant et charge automatiquement le compilateur. Pour un petit programme d'une page écran,
comptez une vingtaine de secondes avant d'avoir le fichier compilé sur disquette.
Ce Pascal, riche et puissant, est un bon support pour développer des applications sérieuses et professionnelles.
A noter qu'une nouvelle version a été annoncée pour le premier trimestre de cette année.
Le Pascal de l'Amiga (MCC de MetaComCo) est une horreur. Pas d'éditeur intégré, vous devez entrer
le programme en utilisant celui du CLI (Command Language Interface) ou Micro Emacs. La notice
technique est un chef-d'oeuvre de flou informatique. Ainsi, compiler quatre lignes toutes
simples nécessite un effort cérébral intense et de la patience. Les commandes sont longues et
compliquées à retenir (pensons aux débutants). En fait, le manuel dévie dans la description du
langage. On aurait préféré comprendre comment se servir du logiciel. Côté outillage, aucune bibliothèque
de procédures ne permet d'exploiter le Workbench, c'est fâcheux. Ce Pascal est sans doute un bon
compilateur mais c'est difficile à vérifier. Si vous ne pouvez pas vous en passer, cette version est
un pis-aller, faute de mieux.
Tableau récapitulatif
| Logiciels |
Éditeur |
Machine |
Prix |
| AmigaBasic |
Commodore |
Amiga |
- |
| Amiga Lisp |
MetaComCo |
Amiga |
1980 FF |
| Aztec C |
Manx |
Amiga |
3940 FF |
| Compilateur GFA |
Micro Application |
Atari ST |
295 FF |
| GFA Basic |
Micro Application |
Atari ST |
495 FF |
| Interpréteur C |
Loriciels |
Atari ST |
390 FF |
| Lattice C |
MetaComCo |
Atari ST |
990 FF |
| Lattice C 4.0 |
Lattice |
Amiga |
1790 FF |
| Mark Williams C |
Mark Williams |
Atari ST |
1490 FF |
| MCC Pascal |
MetaComCo |
Amiga |
880 FF |
| Megamax C |
Megamax |
Atari ST |
1690 FF |
| Personal Pascal |
OSS |
Atari ST |
890 FF |
| Profimat |
Micro Application |
Atari ST |
495 FF |
| STOS |
Cédic-Nathan |
Atari ST |
590 FF |
|
