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 ?
Si mes souvenirs sont bons les parametres sont les premiers que tu trouves en remontant dans la pile.
Si A7 est le pointeur de pile: de A7 à A7-2 tu trouves une donne sur 2 octets et de A7-2 à A7-4 tu trouves la 2ieme donnée sur 2 octets. Un truc comme ça. Evidement il faut adapter si les données ne sont pas sur 2 octets; Voila essaye ça. M.
"DOCs" a écrit dans le message news: 3f6773c1$0$27028$
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 ?
Ou si quelqu'un veut bien m'expliquer...
Merci de tout coeur.
DOCs
Si mes souvenirs sont bons les parametres sont les premiers que tu trouves
en remontant dans la pile.
Si A7 est le pointeur de pile: de A7 à A7-2 tu trouves une donne sur 2
octets et de A7-2 à A7-4 tu trouves la 2ieme donnée sur 2 octets.
Un truc comme ça. Evidement il faut adapter si les données ne sont pas sur 2
octets;
Voila essaye ça.
M.
"DOCs" <docs@ifrance.com> a écrit dans le message news:
3f6773c1$0$27028$626a54ce@news.free.fr...
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 ?
Si mes souvenirs sont bons les parametres sont les premiers que tu trouves en remontant dans la pile.
Si A7 est le pointeur de pile: de A7 à A7-2 tu trouves une donne sur 2 octets et de A7-2 à A7-4 tu trouves la 2ieme donnée sur 2 octets. Un truc comme ça. Evidement il faut adapter si les données ne sont pas sur 2 octets; Voila essaye ça. M.
"DOCs" a écrit dans le message news: 3f6773c1$0$27028$
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 ?
Ou si quelqu'un veut bien m'expliquer...
Merci de tout coeur.
DOCs
DOCs
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 ?
DOCs
"maaxx" a écrit dans le message news: bk7v2l$a3a$
Si mes souvenirs sont bons les parametres sont les premiers que tu trouves en remontant dans la pile.
Si A7 est le pointeur de pile: de A7 à A7-2 tu trouves une donne sur 2 octets et de A7-2 à A7-4 tu trouves la 2ieme donnée sur 2 octets. Un truc comme ça. Evidement il faut adapter si les données ne sont pas sur 2
octets; Voila essaye ça. M.
"DOCs" a écrit dans le message news: 3f6773c1$0$27028$
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 ?
Ou si quelqu'un veut bien m'expliquer...
Merci de tout coeur.
DOCs
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 ?
DOCs
"maaxx" <maaxx@tiscali.fr> a écrit dans le message news:
bk7v2l$a3a$1@news.tiscali.fr...
Si mes souvenirs sont bons les parametres sont les premiers que tu trouves
en remontant dans la pile.
Si A7 est le pointeur de pile: de A7 à A7-2 tu trouves une donne sur 2
octets et de A7-2 à A7-4 tu trouves la 2ieme donnée sur 2 octets.
Un truc comme ça. Evidement il faut adapter si les données ne sont pas sur
2
octets;
Voila essaye ça.
M.
"DOCs" <docs@ifrance.com> a écrit dans le message news:
3f6773c1$0$27028$626a54ce@news.free.fr...
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 ?
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 ?
DOCs
"maaxx" a écrit dans le message news: bk7v2l$a3a$
Si mes souvenirs sont bons les parametres sont les premiers que tu trouves en remontant dans la pile.
Si A7 est le pointeur de pile: de A7 à A7-2 tu trouves une donne sur 2 octets et de A7-2 à A7-4 tu trouves la 2ieme donnée sur 2 octets. Un truc comme ça. Evidement il faut adapter si les données ne sont pas sur 2
octets; Voila essaye ça. M.
"DOCs" a écrit dans le message news: 3f6773c1$0$27028$
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 ?
Ou si quelqu'un veut bien m'expliquer...
Merci de tout coeur.
DOCs
Manu
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. Pour les arguments la convention d'appel par défaut avec GCC est la convention C (la fonction appelante empile les arguments en partant dans la droite et c'est la fonction appelante qui dépile les paramètres). Tu peux forcer GCC à utiliser le passage des arguments par registres avec l'option -mrtg (seulement valable pour x86). Vois également -mregparm. Cela va appliquer la convention d'appel à toute tes fonctions. Si tu ne l'appliquer qu'à une fonction il faut ajouter dans le code un truc du genre __attribute__((regparm(NUMBER))):
`regparm (NUMBER)' On the Intel 386, the `regparm' attribute causes the compiler to pass up to NUMBER integer arguments in registers EAX, EDX, and ECX instead of on the stack. Functions that take a variable number of arguments will continue to be passed all of their arguments on the stack.
Enfin bref, utilise 'info gcc'...
-=( manu )=-
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.
Pour les arguments la convention d'appel par défaut avec GCC est la
convention C (la fonction appelante empile les arguments en partant dans
la droite et c'est la fonction appelante qui dépile les paramètres). Tu
peux forcer GCC à utiliser le passage des arguments par registres avec
l'option -mrtg (seulement valable pour x86). Vois également -mregparm.
Cela va appliquer la convention d'appel à toute tes fonctions. Si tu ne
l'appliquer qu'à une fonction il faut ajouter dans le code un truc du
genre __attribute__((regparm(NUMBER))):
`regparm (NUMBER)'
On the Intel 386, the `regparm' attribute causes the compiler to
pass up to NUMBER integer arguments in registers EAX, EDX, and ECX
instead of on the stack. Functions that take a variable number of
arguments will continue to be passed all of their arguments on the
stack.
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. Pour les arguments la convention d'appel par défaut avec GCC est la convention C (la fonction appelante empile les arguments en partant dans la droite et c'est la fonction appelante qui dépile les paramètres). Tu peux forcer GCC à utiliser le passage des arguments par registres avec l'option -mrtg (seulement valable pour x86). Vois également -mregparm. Cela va appliquer la convention d'appel à toute tes fonctions. Si tu ne l'appliquer qu'à une fonction il faut ajouter dans le code un truc du genre __attribute__((regparm(NUMBER))):
`regparm (NUMBER)' On the Intel 386, the `regparm' attribute causes the compiler to pass up to NUMBER integer arguments in registers EAX, EDX, and ECX instead of on the stack. Functions that take a variable number of arguments will continue to be passed all of their arguments on the stack.
Enfin bref, utilise 'info gcc'...
-=( manu )=-
Christophe de Vienne
DOCs wrote:
Bonsoir, j'ai GCC sur mon ATARI. ( m68k pour ceux qui aurait oublie ).
Bonjour,
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.
Au risque de dire une bêtise : pourquoi ne pas coder seulement le corps de la fonction en assembleur, et laisser la déclaration de la fonction et des variable en C ?
A+
Christophe
-- Christophe de Vienne Experience is something you don't get until just after you need it. Oliver's Law.
DOCs wrote:
Bonsoir, j'ai GCC sur mon ATARI. ( m68k pour ceux qui aurait oublie ).
Bonjour,
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.
Au risque de dire une bêtise : pourquoi ne pas coder seulement le corps de
la fonction en assembleur, et laisser la déclaration de la fonction et des
variable en C ?
A+
Christophe
--
Christophe de Vienne
Experience is something you don't get until just after you need it.
Oliver's Law.
Bonsoir, j'ai GCC sur mon ATARI. ( m68k pour ceux qui aurait oublie ).
Bonjour,
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.
Au risque de dire une bêtise : pourquoi ne pas coder seulement le corps de la fonction en assembleur, et laisser la déclaration de la fonction et des variable en C ?
A+
Christophe
-- Christophe de Vienne Experience is something you don't get until just after you need it. Oliver's Law.
DOCs
"Christophe de Vienne" a écrit dans le message news: newscache$s81dlh$p4i$
DOCs wrote:
Bonsoir, j'ai GCC sur mon ATARI. ( m68k pour ceux qui aurait oublie ).
Bonjour,
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.
Au risque de dire une bêtise : pourquoi ne pas coder seulement le corps de la fonction en assembleur, et laisser la déclaration de la fonction et des variable en C ?
En fait g des routines C et assembleur qui etaient destine a Pure C, mais je
veux les compiler avec GCC.
DOCs
"Christophe de Vienne" <cdevienne@alphacent.com> a écrit dans le message
news: newscache$s81dlh$p4i$1@guronzan.alphacent.com...
DOCs wrote:
Bonsoir, j'ai GCC sur mon ATARI. ( m68k pour ceux qui aurait oublie ).
Bonjour,
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.
Au risque de dire une bêtise : pourquoi ne pas coder seulement le corps de
la fonction en assembleur, et laisser la déclaration de la fonction et des
variable en C ?
En fait g des routines C et assembleur qui etaient destine a Pure C, mais je
"Christophe de Vienne" a écrit dans le message news: newscache$s81dlh$p4i$
DOCs wrote:
Bonsoir, j'ai GCC sur mon ATARI. ( m68k pour ceux qui aurait oublie ).
Bonjour,
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.
Au risque de dire une bêtise : pourquoi ne pas coder seulement le corps de la fonction en assembleur, et laisser la déclaration de la fonction et des variable en C ?
En fait g des routines C et assembleur qui etaient destine a Pure C, mais je
veux les compiler avec GCC.
DOCs
Emmanuel Delahaye
In 'fr.comp.lang.c', "DOCs" wrote:
Au risque de dire une bêtise : pourquoi ne pas coder seulement le corps de la fonction en assembleur, et laisser la déclaration de la fonction et des variable en C ?
En fait g des routines C et assembleur qui etaient destine a Pure C,
mais je veux les compiler avec GCC.
Ce qu'on essaye de te dire, c'est qu'il est préférable de tout faire en C, quitte à inliner de l'assembleur si besoin est... Comme ça, les interfaces sont claires.
-- -ed- [remove YOURBRA before answering me] The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html <blank line> FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
In 'fr.comp.lang.c', "DOCs" <docs@ifrance.com> wrote:
Au risque de dire une bêtise : pourquoi ne pas coder seulement le corps
de la fonction en assembleur, et laisser la déclaration de la fonction
et des variable en C ?
En fait g des routines C et assembleur qui etaient destine a Pure C,
mais je veux les compiler avec GCC.
Ce qu'on essaye de te dire, c'est qu'il est préférable de tout faire en C,
quitte à inliner de l'assembleur si besoin est... Comme ça, les interfaces
sont claires.
--
-ed- emdelYOURBRA@noos.fr [remove YOURBRA before answering me]
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
<blank line>
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
Au risque de dire une bêtise : pourquoi ne pas coder seulement le corps de la fonction en assembleur, et laisser la déclaration de la fonction et des variable en C ?
En fait g des routines C et assembleur qui etaient destine a Pure C,
mais je veux les compiler avec GCC.
Ce qu'on essaye de te dire, c'est qu'il est préférable de tout faire en C, quitte à inliner de l'assembleur si besoin est... Comme ça, les interfaces sont claires.
-- -ed- [remove YOURBRA before answering me] The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html <blank line> FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
Manu
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 )=-
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é...
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 )=-
DOCs
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 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 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 )=-
DOCs
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 )=-
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é...
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 )=-
Emmanuel Delahaye
In 'fr.comp.lang.c', "DOCs" wrote:
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 !
<snip délires 68000>
Oui, je pourrais aussi te parler longuement du PowerPC, de SNMP, ou de la la reproduction des hannetons sur l'Ile de Paques, mais vois-tu ici on parle du langage C...
-- -ed- [remove YOURBRA before answering me] The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html <blank line> FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
In 'fr.comp.lang.c', "DOCs" <docs@ifrance.com> wrote:
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 !
<snip délires 68000>
Oui, je pourrais aussi te parler longuement du PowerPC, de SNMP, ou de la la
reproduction des hannetons sur l'Ile de Paques, mais vois-tu ici on parle du
langage C...
--
-ed- emdelYOURBRA@noos.fr [remove YOURBRA before answering me]
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
<blank line>
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
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 !
<snip délires 68000>
Oui, je pourrais aussi te parler longuement du PowerPC, de SNMP, ou de la la reproduction des hannetons sur l'Ile de Paques, mais vois-tu ici on parle du langage C...
-- -ed- [remove YOURBRA before answering me] The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html <blank line> FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
