Quelques questions Ce titre existe déjà ? - Page 1

Hep
Tout d'abord bonjour hein
J'ai quelques petits problèmes et questions que j'ai pas pu résoudre seul malgré les paquets de tutoriaux cours etc que je me suis enfilé
J'ai le tutorial de Kevin Kofler (le meilleur tuto si vous voulez mon avis) je crois que c'est un mec de l'équipe tigcc enfin bref c'est super mais le passage sur les librairies statiques je sais pas si vous voyez de quoi je parle, ben je pige pas comment on en fait une
J'ai essayé en faisant
xdef MaFonction

MaFonction:
...


Ca compile bien en .a
Sauf que quand je veux l'utiliser dans un source C j'ai undefined reference to MaFonction.
Je suis sûr de pas faire de fautes de frappes et d'avoir bien mis le fichier dans le projet
Donc sur ce point déjà, éclairez moi.
Si vous avez la flemme d'expliquez, aiguillez moi sur un source de librairie statique, réel ou vide que je vois la structure que ça doit avoir

Ensuite pour les arguments, dans MaFonction je fais move.w (a7)+, dn pour récupérer les arguments. Ca me paraît logique mais en fait je me demande si on a le droit de le faire ?

Pour retourner une valeur ensuite, comment faut procéder ? J'ai regarder le .s issu d'un projet C pour voir comment retourner une valeur mais déjà que la syntaxe intel je maîtrise pas bien, alors la syntaxe at&t ...

Bon ça fait plein de questions déjà, j'espère que ça vous embêtera pas de prendre une ou deux minutes pour répondre
Mci
Pis mci d'avoir lu même si z'êtes pas capable de répondre ou si z'aves la flemme ce que je comprends, je me lève pas avant 14h alors c'est pas moi qui vais vous vanter les mérites d'être studieux itou itou

Bref ciao
J'ai probablement oublié une ou deux questions, je reviendrai éditer si elles me reviennent
En passant si vous avez des trucs à me conseiller, je suis preneur. (par truc j'entends des machins qu'il est bon d'avoir sous la main)

++

Si tu programmes en C, pourquoi tu ne crées pas ta librairie en C ?
Sinon, pour retourner une valeur, utilise d0 (pour un entier ou une structure de 4 octets ou moins) ou a0 (pour un pointeur)

Je préfère la faire en assembleur pour économiser du poid.
En fait je parlais de retourner une valeur à la TI, comme quand on fait push_longint en C.

tu peux poster des exemples de ta lib et de ton code ?

à partir de la librairie ? tu peux pas... C'est le programme qui doît retourner la valeur (et contente toi de coder en C de laisser TIGCC faire ça car il utilise un hack si je ne me trompe pas), la lib ne devraît pas toucher à la valeur retournée par le programme (c'est possible, mais on peut parfaitement s'en passer => aucun intérêt)
Et puis, franchement, le problème de taille, c bidon De toute façon si tu ne connaîs pas bien l'asm 68k le compilateur optimisera probablement mieux que toi alors laisse le faire.

Pour le coup de retourner une valeur me suis mal exprimé c'est pas dans le cadre de la lib c'est un truc à part

Je peux pas poster d'exemple j'ai pas internet chez moi je tâcherai d'en mettre sur disquette (c'est juste pour tester hein la lib)

Champignon :
Ca compile bien en .a
Sauf que quand je veux l'utiliser dans un source C j'ai undefined reference to MaFonction.
Je suis sûr de pas faire de fautes de frappes et d'avoir bien mis le fichier dans le projet Donc sur ce point déjà, éclairez moi.

Ce n'est pas vraiment normal... Ce que tu peux faire pour essayer de voir où est le pb : ne crée pas de .a, compile juste ton .asm normalement (pour en faire un .o), et regarde si ça marche comme tu veux. Si ça ne marche pas, le pb est dans a68k ou dans ton source, sinon le pb est dans le linker ou dans ton projet.

Ensuite pour les arguments, dans MaFonction je fais move.w (a7)+, dn pour récupérer les arguments. Ca me paraît logique mais en fait je me demande si on a le droit de le faire ?

Tu peux si tu fais attention (notamment à l'adresse de retour, aux registres que tu sauvegardes, et la valeur de a7 après l'appel), mais je te déconseille : sur TI, la convention est de laisser le pointeur de pile à la valeur où il était avant l'appel (contrairement à certaines conventions sur PC), donc si tu veux faire un truc dans le genre, utilise plutôt "lea 4(a7),a0" (pour zapper l'adresse de retour de la fonction) et dépile ensuite les arguments avec "move.w (a0)+,dn".

Pour retourner une valeur ensuite, comment faut procéder ? J'ai regarder le .s issu d'un projet C pour voir comment retourner une valeur mais déjà que la syntaxe intel je maîtrise pas bien, alors la syntaxe at&t ...

Comme ça a déjà été dit, évite de renvoyer une valeur directement sur l'estack (= la méthode pour renvoyer comme une fonction TI-Basic), en tout cas s'il s'agit d'un truc facilement manipulable directement en C comme un entier. Si tu veux vraiment l'empiler à chaque fois, tu peux faire :

extern int calculate_stuff(char *); // la fonction définie dans le .asm
#define calculate_stuff_to_estack(my_string) push_short(calculate_stuff(my_string))

Ca rend ton code ASM plus lisible, c le genre de truc chiant à faire en ASM pur, ça n'est pas critique au niveau vitesse, et si tu veux réutiliser le résultat en C ce sera plus simple si tu accès à la version qui renvoie un entier...

Merci ! Ca me fait déjà quelques problèmes en moins, vais pouvoir retrouver mon lit.

Champignon :
J'ai essayé en faisant
xdef MaFonction

MaFonction:
...


Ca compile bien en .a Sauf que quand je veux l'utiliser dans un source C j'ai undefined reference to MaFonction.

Hmmm, c'est bizarre... Tu utilises quelle version de TIGCC?

;======================================================================
section ".data" ;In TIGCC, code and data are all together in the .data section.
xdef MaFonction
even
MaFonction:
; Code...
;======================================================================
Voilà 2 ans que j'utilise cette syntaxe que Kevin m'avait alors donné, et cela fonctionne parfaitement.

Après tu ajoutes à ton projet le fichier .a

Bien sur si tu utilises MaFonction dans un programme en C,
il faut la définir dans le fichier C:

//=====================================================================
void MaFonction(void) ; // Ajuste les arguments selon tes besoins.
//=====================================================================

Dans un programme en Assembleur, inclure le fichier .a est suffisant.

Pour ce qui est des arguments, tu peux également demander à TI-GCC de les donner dans des registres,
avec la commande -mregparm dans les options de ton programme (GCC Switches).
Et tu peux même le forcer à te donner les arguments dans des registres précis, exemple:

//=====================================================================
unsigned char MaFonction(register signed short x0 asm("d0"),register signed short y0 asm("d1"), register void* screen asm("a0"), register void* other_screen asm("a1"), register void* spr8xX asm("a3"), register void* string asm("a4")) ;
//=====================================================================

Note que tu peux également faire une librairie statique mêlant fonctions en assembleur et fonctions en C.
TiGCC-lib est un très bon exemple.

[Edit]: suppression du mot-clé 'extern'

Sauf que maintenant, le code est dans la section .text.

Sinon, pour info, à quoi sert le mot-clé extern (dans ton exemple) ?

heu, le extern dit que le code est définit ailleurs...
mais il me semblait que les prototypes de fonctions étaient toujours considérés par le compilateur comme extern, même si le mot-clé en question n'est pas présent ?

De toute évidence un rapide essai confirme que mettre 'extern' n'est pas nécessaire.
Tu as raison squale92.

et static ça veut dire quoi exactement ?

static veut dire que le symbole n'est pas exporté, donc pas utilisable depuis un autre .o ; enfin ça c'est pour les variables (ou fonctions) globales, pour les variables locales ça veut dire que la variable conserve sa valeur entre deux exécutions de la fonction.
Sinon extern n'implique pas vraiment que le code est défini ailleurs (ça peut très bien être défini dans le même fichier), ça veut juste dire que c'est une déclaration qui ne fait rien d'autre que déclarer (int i; crée une variable globale i alors que extern int i; se contente de dire qu'il doit exister une variable i accessible, cette variable peut venir d'un autre fichier .o mais ce n'est pas obligatoire).

En gros: que la variable ne sera pas réallouée ni initialisée à chaque entrée dans la fonction, mais une seule fois au lancement du prog. En pratique, la variable ne peut être mise en globale ou vue d'ailleurs, et garde sa valeur entre les différents appels à la fonction. Un peu comme quand tu fais un dc.x ??? en asm quoi.

edit: cross

En gros toutes les déclarations qui sont dans un .h sont censées être extern, si on veut respecter le fait qu'un .h ne génère aucun code en lui-même.

Merci Sally. Je ne m'étais pas vraiment documenté sur 'extern' jusques là.