Obligement - L'Amiga au maximum

Jeudi 28 mars 2024 - 11:43  

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 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 existe aussi sur Windows, Mac, Linux, etc., ce qui permet de générer un exécutable Amiga 68k depuis un PC ou un Mac.

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 (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 le système d'exploitation 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.

Exemple de commande de compilation

vc +aos68k -cpu=68020 -lamiga -lauto -lmsoft -lvc -o test test.c

Les cibles

La compilation croisée est la capacité à compiler un programme pour un système d'exploitation 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 les pages dédiées à ce compilateur : sun.hasenbraten.de/vbcc/ (vbcc version 68k) et www.compilers.de/vbcc.html (vbcc officiel). 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 : 2004.
Configuration minimale : Amiga OCS, 68020, 1 Mo de mémoire, AmigaOS 2.0.
Licence : gratuiciel.

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]