Obligement - L'Amiga au maximum

Vendredi 24 novembre 2017 - 15:48  

Translate

En De Nl Nl
Es Pt It Nl


Rubriques

 · Accueil
 · A Propos
 · Articles
 · Galeries
 · Glossaire
 · Hit Parade
 · Liens
 · Liste jeux Amiga
 · Quizz
 · Téléchargements
 · Trucs et astuces


Articles

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

 · Articles in english
 · Articles in other languages


Twitter

Suivez-nous sur Twitter




Liens

 · Sites de téléchargements
 · Associations
 · Pages Personnelles
 · Moteurs de recherche
 · Pages de liens
 · Constructeurs matériels
 · Matériel
 · Autres sites de matériel
 · Réparateurs
 · Revendeurs
 · Presse et médias
 · Programmation
 · Développeurs logiciels
 · Logiciels
 · Développeurs de jeux
 · Jeux
 · Autres sites de jeux
 · Scène démo
 · Divers
 · Informatique générale


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


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


Partenaires

Annuaire Amiga

Amedia Computer

Relec

Hit Parade


Contact

David Brunet

Courriel

 


Test de vbcc 0.8
(Article écrit par Mathias Parnaudeau - juin 2004)


Même si de très nombreux langages sont disponibles, la programmation sur Amiga fait la part belle au C. Le passage au PowerPC permet de faire le ménage dans les compilateurs disponibles et ce n'est pas plus mal pour clarifier la situation et assurer une gestion correcte, au niveau des bibliothèques par exemple. Au final, il reste deux compilateurs complémentaires : GCC le standard et vbcc le complément qui mérite qu'on fasse la lumière sur lui, en présentant ses caractéristiques et ses particularités.

Pas si accessoire

Malgré sa position d'outsider, vbcc possède de réelles qualités et après un an et demi d'expérience, il s'avère être un très bon choix, notamment pour les débutants. Dès l'installation, on reste en terrain connu : désarchivage Lha, renseignement des chemins pour les includes dans le fichier de configuration, exécution de ce fichier et voilà ! Cet argument est cependant moins caractéristique depuis que GCC s'installe tout seul avec le SDK MorphOS ou AmigaOS 4 et même en 68k avec le paquetage GoldEd. En revanche, la grande force de vbcc, c'est de pouvoir générer des exécutables pour des cibles différentes (Amiga 68k, WarpOS, MorphOS...) en spécifiant juste un argument à la compilation ! La compilation croisée ne peut pas être plus accessible !

vbcc souffre de manques (pas de débogueur ni de profileur exploitable) et de bogues mais il est activement géré. Les réponses arrivent rapidement et l'auteur donne des détails très instructifs, de quoi évoluer dans sa compréhension des compilateurs (édition de liens, formats de bibliothèques...). Voici un exemple pour illustrer cette réactivité : un projet 68k nécessitait la gestion des nombres et fonctions mathématiques 64 bits et ce fut implémenté en quelques jours ! J'ai pu recevoir directement un correctif par courriel sans attendre. D'autres problèmes remontés ont pu être corrigés rapidement, comme un bogue dans la conversion de flottants en entiers 64 bits. Les fonctions DoSuperNew et SetSuperAttrs ont été ajoutées dans la libamiga pour MorphOS juste pour avoir signalé leur absence à l'auteur. Ainsi, vu cette écoute, on comprend que plus les développeurs utiliseront vbcc, plus celui-ci sera amélioré et complet.

La compilation croisée et l'assistance technique constituent de réels avantages mais malgré tout, vbcc traîne parfois la réputation de second, pas forcément capable d'assurer le portage d'applications Linux ou de s'attaquer à de gros développements. Il n'en est rien ! Des preuves indiquent que vbcc est tout à fait à la hauteur pour compiler des projets conséquents. En effet, des outils classiques (xlHTML, TinyGL, l'économiseur d'écran Matrix...) ont été obtenus grâce à lui mais il est possible d'aller plus loin : GLQuake, la bibliothèque vorbis 68k et SDL, Zip-Zap, SX Rally, SongPlayer 1.62, Smart Lines... tous ont aussi été compilés avec succès. Et signalons que le compilateur se recompile lui-même (et pour la première fois avec l'option d'optimisation -O1, grâce à la puissance et à la mémoire du Pegasos).

Particularités de vbcc

Après les points forts qui ont dû donner envie d'offrir sa chance à vbcc, nous aborderons ici tout ce qui fait son identité. La documentation, au format PDF ou HTML, fournit bien entendu des informations mais elle contient des lacunes. C'est pourquoi cette partie se propose de revenir sur plusieurs points qui sont autant de compléments à la documentation officielle.

Chaque compilateur est différent par ses options, ses directives, son interprétation des erreurs et "warnings", ses capacités de débogage... vbcc n'échappe pas à la règle. Voici donc des informations et des conseils.

vbcc se distingue de GCC. Déjà, si vous n'aviez pas bien compris ce qu'était la ixemul et que ça vous causait des soucis, soyez rassuré, vbcc n'a rien à voir avec ça. En revanche, certaines fonctions des bibliothèques livrées avec GCC ne sont pas forcément présentes : strdup, alloca, rint, etc. Le passage au PowerPC a mis en évidence le problème d'alignement des structures et les deux compilateurs cités ont adopté deux notations différentes. GCC utilise les directives "pragma pack" alors que pour vbcc ce sont les pragmas "amiga-align" et "default-align". A la différence d'AmigaOS 4, seul GCC est géré sur ce point dans les includes MorphOS, ce qui n'encourage pas à choisir vbcc. On se rend compte que les théories de l'évolution s'appliquent ici : s'adapter ou périr. Heureusement ici, Stéphane Saragaglia a écrit un script Perl (aurora.gotdns.org/amiga/UpdateMosIncForVbcc.pl) qui corrige les includes MorphOS et permet leur utilisation avec vbcc sans se soucier par la suite des alignements et des pragmas correspondants.

La gestion de la norme ISO 1999 est activable avec -c99, ce qui devient à l'usage rapidement systématique. Ne serait-ce que pour programmer en C en suivant ses dernières spécifications et ensuite, cela autorise les commentaires à la C++ ou les macros varargs. Ces dernières peuvent d'ailleurs poser un problème dont la cause réelle provient en fait des inlines. Ainsi, il existe la directive de compilation -DNO_INLINE_STDARG qui a pour effet d'utiliser des stubs d'amiga.lib à la place des inlines. Ça peut devenir utile pour la programmation MUI notamment.

La création d'une bibliothèque statique varie suivant l'OS cible : un simple "join <liste des objets> TO malib.lib" suffit pour AmigaOS 68k et WarpOS, sinon vbcc propose sa propre commande "ar" à utiliser avec l'option "q" pour MorphOS. Attention, il est préférable de spécifier le chemin "vbcc:bin/ar" car sinon, la commande équivalente proposée par GCC pourrait être utilisée et elle ne connaît pas l'option "q". Normalement, vbcc accepte les bibliothèques des autres compilateurs mais ça peut ne pas être le cas (exemple de la SDL qui contient des références inconnues de vbcc).

Pour vbcc, la notion de NULL n'est pas considérée comme la valeur zéro mais comme le pointeur nul "((void *)0)", ce qui peut provoquer des erreurs de compilation, constatée parfois dans du code peu rigoureux où un NULL a été choisi abusivement. Par exemple, lors de l'appel de la fonction OpenDevice, l'argument terminal doit être "0L" (son type est ULONG) et non pas NULL comme c'est souvent le cas.

Enfin, pour donner un dernier conseil, travaillez toujours avec l'option d'optimisation -O1 maxi pour n'utiliser -O2 que, éventuellement, dans la phase finale. En effet, ce niveau d'optimisation peut générer du code bogué dans certains cas ; vous vous retrouvriez avec une application qui plante, ce qui est toujours dommage. D'autres ennuis, cette fois-ci liés au compilateur, peuvent être évités en augmentant la taille de la pile.

Les cibles

La compilation croisée est la capacité à compiler un programme pour un OS cible à partir d'un système différent. Ce qui se fait par exemple aisément, c'est la compilation 68k depuis MorphOS, avec le simple ajout (à la compilation mais aussi à l'édition de lien) de l'option +m68k. Cette fonctionnalité est appréciable, d'autant qu'il est possible de tester le programme grâce à l'émulation 68k de MorphOS.

Une partie importante touche au débogage. Avec GCC, la simple option "-g" permet d'obtenir dans l'exécutable des informations exploitables avec un débogueur. vbcc utilise plusieurs options toutes en nuances. :-)

L'option -g active la gestion du débogage mais par défaut les informations sont au format DWARF, géré par aucun débogueur 68k mais qui prendrait tout son sens avec MorphOS ou AmigaOS 4. Pour indiquer un format compatible avec le 68k, on doit utiliser l'option additionnelle -hunkdebug :

vc +m68kdb -c99 -g -hunkdebug -c programme .c

On remarque l'option "+m68kdb" alors qu'on avait évoqué "+m68k". Cette dernière fait référence au fichier de configuration "vbcc:config/m68k" qui retire tous les symboles (informations) de débogage : c'est la fameuse opération de "strip" que l'on ne veut bien sûr pas appliquer ici ! C'est pourquoi on fait appel au fichier "m68kdb", tout simplement.

Un programme contenant les symboles de débogage est ensuite exploité en cas de hit grâce à l'outil FindHunkOffset qui permet de localiser précisément l'emplacement du code fautif. Cet outil ne fonctionne qu'avec les binaires au format Hunk, c'est-à-dire qu'il est destiné au 68k et à WarpOS.

Avenir radieux

Celui-ci n'est assuré que si on le gère activement et si on sait saisir cette chance qui nous est présentée. Il est impensable de rejeter vbcc parce qu'il est différent de GCC ! Au contraire, l'utilisation des deux est d'ailleurs recommandée puisqu'ils lèvent des erreurs et "warnings" différents, ce qui permet de rendre le code plus portable et plus propre. Preuve de ses capacités, vbcc est officiellement gérés par AmigaOS 4.0 pour lequel il génère du code natif (même code en fait, seuls le startup et la vclib diffèrent).

Au niveau des évolutions prévues, on compte la gestion du module AltiVec du PowerPC G4 : les assembleurs (pasm et vasmppc) sont déjà conçus pour ça. L'idée d'un débogueur et d'un profileur a été soulevée mais cela implique des modifications pas si triviales. La priorité va à la correction d'un ou deux bogues localisés par l'auteur, à la suite de quoi on pourrait voir arriver une mise à jour complète, la dernière datant de quelques années. Des propositions seront faites pour que la documentation soit enrichie.

Si tout ce descriptif vous a convaincu, je vous invite à vous rendre sur la page dédiée à ce compilateur : devnull.owl.de/~frank/index_e.html. Et on n'oublie pas l'article d'Olivier Fabre sur l'installation et la configuration de vbcc : www.guru-meditation.net/main.php3?root=168.

Au final, quelle action y a-t-il à mener ? De l'avis même de Frank Wille : "Promouvoir le compilateur est la chose la plus importante que vous puissiez faire".

Nom : vbcc 0.8.
Auteur : Volker Barthelmann, Franck Wille.
Genre : Compilateur (programmation).
Date : 2001-2004.
Configuration minimale : Amiga OCS, 68020, AmigaOS 2.0.
Licence : freeware.

NOTE : 8/10.

Les points forts :

- Installation facile, par rapport à GCC 68k.
- Facilité de compilation croisée inégalée !
- Assistance technique réactive et enrichissante.
- Facilite la programmation réseau car GCC 68k pose des problèmes d'includes.

Les points faibles :

- Toujours quelques bogues, principalement d'optimisation.
- Pas de gestion du C++.
- Profiler non fonctionnel.


[Retour en haut] / [Retour aux articles]