Bonsoir, j'ai GCC sur mon ATARI. ( m68k pour ceux qui aurait oublie ).
Je recherche desesperement les regles de passages des parametres par la
pile.
En gros j'ai une fonction que j'appelle dans mon source C.
Cette fonction est ecrite en assembleur.
J'ai deux parametres a faire passer. ( une donnee, et une adresse pour
recuperer le resultat ).
Je sais qu'il faut faire passer ses parametres par la pile.
Mais je ne sais pas comment recuperer proprement les parametres dans mon
source assembleur.
Il parait qu'il y a une convention C.
J'ai entendu parler des instructions link et unlink vaguement, qui doivent
servir aussi.
Meme en generant le code assembleur du source C je ne comprend pas.
Ou puis je trouver ces informations sur le net ?
J'ai encore un probleme ( decidement... ). En mettant -mshort en parametre de compilation, c'est maintenant les autres fonctions ( printf par exemple ) qui empilent mal les parametres puisqu'elles ont ete ecrites pour que les parametres passent en 32 bits. Donc il faut simplement que l'option -mshort s'applique a cette ligne: (...) rc = scsicall->InquireSCSI(cInqFirst,&Info); (...)
Je suppose que je dois utiliser __attribute__((mshort)) . Mais ou dois-je le placer ?
DOCs
"DOCs" a écrit dans le message news: 3f68c8e8$0$25996$
Je viens de trouver l'option -mshort specifique au m68k. Les entiers ( int ) sont alors consideres comme des 'short int' sur 16 bits
donc. Je viens de verifier: mon parametre donnee est empile sur 16 bits au lieu de
32, cool ! Beau cadeau d'anniversaire pour mes 22 ans ! Ma routine assembleur semble marcher presque parfaitement, puisqu'elle affiche ENFIN mes peripheriques SCSI !
De +, j'avais oublie de dire qu'avant de lancer la routine assembleur, mon programme passe en mode superviseur ( on peut ecrire de partout dans la memoire ). Des lors la pile a7 (sp), n'est plus la meme et la pile est ssp, donc en fait je me focalisais sur a7 alors que ce n'etait pas la bonne pile. Donc je suppose, que c'est + comprehensible en raisonnant sur l'empilage et
le depilage des mes parametres avec la bonne pile. Pourtant mon debuggueur m'affiche les instructions en referencant la pile a7, c'est pour ca que je me focalisais dessus. Mais je suppose, que les instructions d'empilage sont les meme que ce soit avec a7 (sp) ou avec (ssp), il n'y a que le mode superviseur qui est active
ou pas ( registre SR il me semble ).
DOCs
"DOCs" a écrit dans le message news: 3f68bf0a$0$27041$
J'ai trouve je pense mon probleme principal pour passer les parametres. En fait j'empile bien mes parametres avec GCC. Mon programme assembleur appele a ete concu de telle sorte que les parametres passent par la pile. Donc tout devrait aller bien, mais....
Mes parametres empiles doivent etre une adresse ( 32 bits ) et une donnee
statique ( 16 bits ). La routine assembleur a ete ecrite pour ca. Le probleme c'est que GCC empile l'adresse sur 32 bits et la donnee statique
sur 32 bits. J'ai remarque que tout les parametres de mon source C etaient reellement empiles en 32 bits. Je suppose que c'est une option a activer pour que l'empilage soit base sur
le type reel des parametres. J'ai beau caster mon parametre donnee, ca ne change rien.
DOCs
"Manu" a écrit dans le message news: bkaddm$3v4$
Emmanuel Delahaye wrote:
In 'fr.comp.lang.c', Manu wrote:
DOCs wrote:
Merci mais ca je le sait deja, mais a quoi sert le link et le unlink
( A6
tres souvent )? Et mon adresse resultat a la fin de ma routine assembleur, je la met
ou
avant de repasser au C ?
Sur x86 et avec GCC dans eax.
Ca va vachement intéresser le gars avec son 68k...
Je suis aller un peu vite sur le coup. Ca change pas trop ce que j'ai dis sur certain trucs. Et il peut également aller voir du coté de la section "Extended Asm" dans le info de GCC. Sinon le moyen bourrin, c'est de de faire un coup de objdump -d sur un programme simple et de voir comment tout ça a été généré...
-=( manu )=-
J'ai encore un probleme ( decidement... ).
En mettant -mshort en parametre de compilation, c'est maintenant les autres
fonctions ( printf par exemple ) qui empilent mal les parametres
puisqu'elles ont ete ecrites pour que les parametres passent en 32 bits.
Donc il faut simplement que l'option -mshort s'applique a cette ligne:
(...)
rc = scsicall->InquireSCSI(cInqFirst,&Info);
(...)
Je suppose que je dois utiliser __attribute__((mshort)) .
Mais ou dois-je le placer ?
DOCs
"DOCs" <docs@ifrance.com> a écrit dans le message news:
3f68c8e8$0$25996$626a54ce@news.free.fr...
Je viens de trouver l'option -mshort specifique au m68k.
Les entiers ( int ) sont alors consideres comme des 'short int' sur 16
bits
donc.
Je viens de verifier: mon parametre donnee est empile sur 16 bits au lieu
de
32, cool !
Beau cadeau d'anniversaire pour mes 22 ans !
Ma routine assembleur semble marcher presque parfaitement, puisqu'elle
affiche ENFIN mes peripheriques SCSI !
De +, j'avais oublie de dire qu'avant de lancer la routine assembleur, mon
programme passe en mode superviseur ( on peut ecrire de partout dans la
memoire ).
Des lors la pile a7 (sp), n'est plus la meme et la pile est ssp, donc en
fait je me focalisais sur a7 alors que ce n'etait pas la bonne pile.
Donc je suppose, que c'est + comprehensible en raisonnant sur l'empilage
et
le depilage des mes parametres avec la bonne pile.
Pourtant mon debuggueur m'affiche les instructions en referencant la pile
a7, c'est pour ca que je me focalisais dessus.
Mais je suppose, que les instructions d'empilage sont les meme que ce soit
avec a7 (sp) ou avec (ssp), il n'y a que le mode superviseur qui est
active
ou pas ( registre SR il me semble ).
DOCs
"DOCs" <docs@ifrance.com> a écrit dans le message news:
3f68bf0a$0$27041$626a54ce@news.free.fr...
J'ai trouve je pense mon probleme principal pour passer les parametres.
En fait j'empile bien mes parametres avec GCC.
Mon programme assembleur appele a ete concu de telle sorte que les
parametres passent par la pile.
Donc tout devrait aller bien, mais....
Mes parametres empiles doivent etre une adresse ( 32 bits ) et une
donnee
statique ( 16 bits ).
La routine assembleur a ete ecrite pour ca.
Le probleme c'est que GCC empile l'adresse sur 32 bits et la donnee
statique
sur 32 bits.
J'ai remarque que tout les parametres de mon source C etaient reellement
empiles en 32 bits.
Je suppose que c'est une option a activer pour que l'empilage soit base
sur
le type reel des parametres.
J'ai beau caster mon parametre donnee, ca ne change rien.
DOCs
"Manu" <nobody@guzu.net.invalid> a écrit dans le message news:
bkaddm$3v4$1@news-reader5.wanadoo.fr...
Emmanuel Delahaye wrote:
In 'fr.comp.lang.c', Manu <nobody@guzu.net.invalid> wrote:
DOCs wrote:
Merci mais ca je le sait deja, mais a quoi sert le link et le
unlink
( A6
tres souvent )?
Et mon adresse resultat a la fin de ma routine assembleur, je la
met
ou
avant de repasser au C ?
Sur x86 et avec GCC dans eax.
Ca va vachement intéresser le gars avec son 68k...
Je suis aller un peu vite sur le coup.
Ca change pas trop ce que j'ai dis sur certain trucs.
Et il peut également aller voir du coté de la section
"Extended Asm" dans le info de GCC.
Sinon le moyen bourrin, c'est de de faire un coup de objdump -d
sur un programme simple et de voir comment tout ça a été généré...
J'ai encore un probleme ( decidement... ). En mettant -mshort en parametre de compilation, c'est maintenant les autres fonctions ( printf par exemple ) qui empilent mal les parametres puisqu'elles ont ete ecrites pour que les parametres passent en 32 bits. Donc il faut simplement que l'option -mshort s'applique a cette ligne: (...) rc = scsicall->InquireSCSI(cInqFirst,&Info); (...)
Je suppose que je dois utiliser __attribute__((mshort)) . Mais ou dois-je le placer ?
DOCs
"DOCs" a écrit dans le message news: 3f68c8e8$0$25996$
Je viens de trouver l'option -mshort specifique au m68k. Les entiers ( int ) sont alors consideres comme des 'short int' sur 16 bits
donc. Je viens de verifier: mon parametre donnee est empile sur 16 bits au lieu de
32, cool ! Beau cadeau d'anniversaire pour mes 22 ans ! Ma routine assembleur semble marcher presque parfaitement, puisqu'elle affiche ENFIN mes peripheriques SCSI !
De +, j'avais oublie de dire qu'avant de lancer la routine assembleur, mon programme passe en mode superviseur ( on peut ecrire de partout dans la memoire ). Des lors la pile a7 (sp), n'est plus la meme et la pile est ssp, donc en fait je me focalisais sur a7 alors que ce n'etait pas la bonne pile. Donc je suppose, que c'est + comprehensible en raisonnant sur l'empilage et
le depilage des mes parametres avec la bonne pile. Pourtant mon debuggueur m'affiche les instructions en referencant la pile a7, c'est pour ca que je me focalisais dessus. Mais je suppose, que les instructions d'empilage sont les meme que ce soit avec a7 (sp) ou avec (ssp), il n'y a que le mode superviseur qui est active
ou pas ( registre SR il me semble ).
DOCs
"DOCs" a écrit dans le message news: 3f68bf0a$0$27041$
J'ai trouve je pense mon probleme principal pour passer les parametres. En fait j'empile bien mes parametres avec GCC. Mon programme assembleur appele a ete concu de telle sorte que les parametres passent par la pile. Donc tout devrait aller bien, mais....
Mes parametres empiles doivent etre une adresse ( 32 bits ) et une donnee
statique ( 16 bits ). La routine assembleur a ete ecrite pour ca. Le probleme c'est que GCC empile l'adresse sur 32 bits et la donnee statique
sur 32 bits. J'ai remarque que tout les parametres de mon source C etaient reellement empiles en 32 bits. Je suppose que c'est une option a activer pour que l'empilage soit base sur
le type reel des parametres. J'ai beau caster mon parametre donnee, ca ne change rien.
DOCs
"Manu" a écrit dans le message news: bkaddm$3v4$
Emmanuel Delahaye wrote:
In 'fr.comp.lang.c', Manu wrote:
DOCs wrote:
Merci mais ca je le sait deja, mais a quoi sert le link et le unlink
( A6
tres souvent )? Et mon adresse resultat a la fin de ma routine assembleur, je la met
ou
avant de repasser au C ?
Sur x86 et avec GCC dans eax.
Ca va vachement intéresser le gars avec son 68k...
Je suis aller un peu vite sur le coup. Ca change pas trop ce que j'ai dis sur certain trucs. Et il peut également aller voir du coté de la section "Extended Asm" dans le info de GCC. Sinon le moyen bourrin, c'est de de faire un coup de objdump -d sur un programme simple et de voir comment tout ça a été généré...
