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
|
|
|
|
En Pratique : Recompilation de vieux logiciels pour AmigaOS 4
(Entrevue réalisée par Peter Hutchison et extrait d'Intuition Base - juin 2004, mis à jour en février 2005)
|
|
Si vous avez un vieux programme C datant de plusieurs années, il est possible de le réécrire pour
AmigaOS 4/AmigaOne. Une bonne partie de mon expérience se base sur SAS 6.5x et StormC (qui est basé sur GCC).
Suivez certains des conseils ci-dessous pour convertir votre logiciel :
Fichiers d'en-tête
Fichiers clibs, pragmas, proto
Ces fichiers d'en-tête contiennent principalement des en-têtes pour les bibliothèques partagées d'AmigaOS,
etc. Dans certains codes sources, vous pouvez avoir des en-têtes clib et pragma.
Exemple :
#include <clib/exec_protos.h>
#include <pragmas/exec_pragmas.h>
|
GadToolsBox écrit parfois les en-têtes dans ce format. Cela ne fonctionnera pas complètement avec GCC
sur AmigaOS 4. Vous devriez remplacer ce qui précède, avec les en-têtes proto :
Cela inclura tous les en-têtes clib et pragma appropriés pour vous.
En-têtes Inline
GCC utilise les en-têtes Inline (inclus par les en-têtes proto) pour accéder aux bibliothèques partagées
d'AmigaOS. SAS C ne les utilise pas.
Fonctions C
Format des fonctions
Au début, lorsque l'on écrivait une fonction en C, certaines hypothèses étaient faites et le format
était différent, les arguments étaient définis sur des lignes séparées. Exemple :
myFunction(num1, num2, string1)
int num1, num2;
char *string1;
{
}
|
Ceci n'est pas conforme au format ANSI moderne. "myFunction" suppose qu'elle renvoie soit un "int",
soit un "void" et que les définitions sont séparées :
int myFunction(int num1, int num2, char *string1)
{
}
|
Prototypes
Il est d'usage de prototyper toutes les fonctions soit au début du fichier de programme C, soit dans un
fichier d'en-tête. Si vous avez plusieurs fichiers de programme C, ajoutez les prototypes à un fichier
d'en-tête et utilisez ce fichier "#include" dans tous vos fichiers C pour assurer la cohérence de l'ensemble
du projet. Utilisez le format standard ANSI C (voir note précédente) :
/* Prototypes */
int myFunction(int num1, int num2, char *string1);
|
Void
S'il n'y a pas de paramètres passés ou renvoyés, utilisez "void" dans la mesure du possible :
void otherFunction(void)
{
}
|
Paramètres et arguments
Lorsque vous passez des données vers/depuis des arguments, assurez-vous d'utiliser le bon type de données.
Par exemple, ne passez pas un "long" lorsque la fonction attend un "int" et ainsi de suite, car cela peut
générer de nombreux messages d'avertissement. Définissez le bon type de données au début de la fonction
ou utilisez les "casts" dans tous les autres cas.
void otherFunction(void)
{
long numa, numb;
char name[30];
myFunction(numa, numb, name); /* ceci générera des avertissements car numa,numb sont des longs et non des ints */
}
|
...devrait devenir :
void otherFunction(void){
int numa, numb;
char name[30];
myFunction(numa, numb, name); /* ceci est maintenant correct */
}
|
La fonction "main()" doit toujours retourner un "int", vous pouvez utiliser un "return 0" à la fin pour
indiquer que le programme s'est terminé avec succès. Vous pouvez également utiliser les arguments "argc",
"argv" si vous en avez besoin, sinon utilisez "void".
Compilation
Si le programme a été compilé en SAS/C, exécutez SCOPTS et changez les options de message en ANSI,
STRICT. Activez également toutes les avertissements (s'ils ont été désactivés). Recompilez ensuite.
Votre programme peut utiliser d'anciennes fonctions provenant de bibliothèques SAS/C uniquement, celles-ci
ne seront pas transférables aux compilateurs StormC ou GCC. Dans le manuel SAS/C, dans le guide de
l'utilisateur, cherchez dans la référence de la bibliothèque C les appels qui ne peuvent pas être
utilisés dans GCC. Tout ce qui est marqué AmigaOS, Old, Unix ou SAS/C devra être changé pour l'équivalent
ANSI ou réécrit.
Une fois que le programme a été recompilé, copiez le code source dans un autre dossier, et recompilez
pour GCC/StormC. Cela devrait permettre de repérer toute autre erreur ou avertissement nécessitant une
attention particulière.
Si vous utilisez un assembleur, le code 68k peut être recompilé à l'aide de Phxass qui est compatible avec
le code assembleur SAS/C. Assurez-vous d'inclure le dossier asm-include dans le projet pour récupérer les
fichiers d'en-tête de l'assembleur. Si possible, le code assembleur doit être réécrit en C pour la portabilité
vers le code PowerPC.
Lors de la compilation, essayez de modifier le code pour supprimer autant d'avertissements et d'erreurs
que possible. Cela facilitera les mises à jour ultérieures et éliminera tous les bogues potentiels du code.
Les tests sont également importants, ayez un bon plan de test pour corriger toute erreur logique, le compilateur
ne peut pas toutes les trouver.
Makefiles
Les fichiers makefiles ne sont pas facilement portables entre compilateurs. En SAS/C, vous pouvez créer
des fichiers makefiles à l'aide de l'utilitaire smake et des Scopts qui fournissent des options pour le
type de processeur, l'optimisation, etc. Pour StormC, le fichier de projet contient les informations make
(lisibles dans un éditeur de texte), pour GCC, vous devez écrire votre propre fichier ou utiliser les utilitaires
à votre disposition.
Mises à jour d'essai
Si vous voulez faire un essai, pourquoi ne pas télécharger quelques vieux programmes amiga sur
Aminet qui incluent les sources et les essayer. Vérifiez
les fichiers "readme" et la documentation, avant de distribuer un travail modifié. L'auteur peut
ne pas aimer que son travail soit mis à jour ou redistribué sans son consentement. En cas de doute,
ne le faites pas.
Mise à jour vers des API d'interface graphique plus récentes
L'Amiga a l'avantage de disposer d'un choix d'interfaces graphiques à utiliser : Intuition, GadTools,
MUI, ClassAct, ReAction et bien d'autres. Si vous avez les compétences nécessaires, pourquoi ne pas mettre
à jour le programme pour utiliser les dernières interfaces graphiques telles que ReAction ou MUI.
Pour ReAction, vous pouvez utiliser le programme Reactor fourni sur l'Amiga Developer CD 2.1 dans la
section "NDK 3.5". Il existe le programme MUIBuilder pour les interfaces MUI.
Attention, l'optimisation de GCC peut générer des opérations en virgule flottante à partir de code en
virgule non flottante. Utilisez l'option "-msoft-float" pour désactiver la génération de code en virgule
flottante pour chaque fichier.
Exemple : si vous codez des interruptions, vérifiez avec l'option gcc "-S" si la sortie assembleur de
votre code d'interruption ne contient pas de registres en virgule flottante comme "lfd" ou "lfs".
Comme les registres à virgule flottante ne sont pas sauvegardés dans une interruption, cela pourrait
entraîner des plantages dans d'autres tâches qui utilisent également la virgule flottante.
|
