J'aimerais savoir comment utiliser mes paramètres (recevoir et
retourner)
dans mon sous-programmme. Pour le moment, j'ai une erreur de
segmentation fault. Le sous-programme(EtablirASCII) en Assembleur
reçoit 3 paramètres (int iTranscode, char cRepere, int iP) et retourne
un int. Puisque je n'arrive pas à recevoir correctement les
paramètres, EtablirASCII ne fait pas de traitement.
Pourriez-vous m'indiquer comment retourner, par exemple, mon paramètre
iTranscode? Merci.
/*Extrait du programme en C++*/
extern "C" int EtablirASCII(int iTranscode, char cRepere, int iP);
void main()
{
char cRepere;
int iDernierBit=0;
int iPosition = iNB_BITS;
int iP;
int iLigne;
int iTranscode=0;
int x;
//Appel de la fonction de lecture pour lire la première ligne
iLigne = LireLigne();
//Extraire le repère et le p
cRepere = DecodeRepere(iLigne);//Décoder le repère
iP = ~iLigne & 7;//Décoder le P
EtablirASCII:
save %sp,-TAILLE,%sp ! sauvegarde...
st %i0,[%fp-4] ! recuperation des parametres
st %i1,[%fp-8] ! et sauvegarde dans le bloc du
sous-programme
st %i2,[%fp-12]
mov -12,%l0
ld [%fp+%l0],%l3
/*Fin du sous-programme*/
ASCIIEnd:
ld [%fp+ADR], %l0 ! Adresse de la structure de retour
st %l3,[%l0] ! retour de la somme */
jmp %i7 ! retour à l'appelant
restore ! ramène l'environnement
sont mis ds la pile en premier l'adresse de retour de l'appel le dernier argument d'appel ... le 1er argument puis il initialise le 'pointeur de base' ( registre BP) sur le début de la structure d'appel ( notre call frame)
C'est curieux. Ça ressemble à ce qu'on faisait il y a quinze ans, sur 8086. Je m'attendrais à ce qu'un compilateur moderne fasse mieux (certains paramètres dans des régistres).
Haha tu rigoles ?! Honnêtement je me pose la même question depuis des années et ça fait vraiment plaisir de voir que je suis pas le seul. Même aujourd'hui en 2004, quand il m'arrive de désassembler du code généré par un compilateur moderne, je suis horrifié de voir qu'il y a encore beaucoup d'optimisations de base (de celles qu'on apprend après 2 jours d'assembleur) qui ne sont pas effectuées.
La politique actuelle consiste à se dire "le compilo sait ce qu'il fait, y'a ouatmille caches, les tables de cycles c'est fini maintenant c'est tout contextuel, etc...", bon admettons, mais faut quand-même pas se moquer du codeur assembleur, il y a des limites. Maintenant, on a plein d'options d'optimisation -Wtrucmuche et c'est à se demander parfois si c'est pas plutôt pour faire joli. Personnellement, j'en suis resté au "un jour, les compilos sauront ce qu'ils feront". Mouais, mais quand ? :)
-- Tek
kanze@gabi-soft.fr wrote:
sont mis ds la pile en premier l'adresse de retour de l'appel
le dernier argument d'appel
...
le 1er argument
puis il initialise le 'pointeur de base' ( registre BP) sur le début
de la structure d'appel ( notre call frame)
C'est curieux. Ça ressemble à ce qu'on faisait il y a quinze ans, sur
8086. Je m'attendrais à ce qu'un compilateur moderne fasse mieux
(certains paramètres dans des régistres).
Haha tu rigoles ?! Honnêtement je me pose la même question depuis des
années et ça fait vraiment plaisir de voir que je suis pas le seul. Même
aujourd'hui en 2004, quand il m'arrive de désassembler du code généré
par un compilateur moderne, je suis horrifié de voir qu'il y a encore
beaucoup d'optimisations de base (de celles qu'on apprend après 2 jours
d'assembleur) qui ne sont pas effectuées.
La politique actuelle consiste à se dire "le compilo sait ce qu'il fait,
y'a ouatmille caches, les tables de cycles c'est fini maintenant c'est
tout contextuel, etc...", bon admettons, mais faut quand-même pas se
moquer du codeur assembleur, il y a des limites. Maintenant, on a plein
d'options d'optimisation -Wtrucmuche et c'est à se demander parfois si
c'est pas plutôt pour faire joli. Personnellement, j'en suis resté au
"un jour, les compilos sauront ce qu'ils feront". Mouais, mais quand ? :)
sont mis ds la pile en premier l'adresse de retour de l'appel le dernier argument d'appel ... le 1er argument puis il initialise le 'pointeur de base' ( registre BP) sur le début de la structure d'appel ( notre call frame)
C'est curieux. Ça ressemble à ce qu'on faisait il y a quinze ans, sur 8086. Je m'attendrais à ce qu'un compilateur moderne fasse mieux (certains paramètres dans des régistres).
Haha tu rigoles ?! Honnêtement je me pose la même question depuis des années et ça fait vraiment plaisir de voir que je suis pas le seul. Même aujourd'hui en 2004, quand il m'arrive de désassembler du code généré par un compilateur moderne, je suis horrifié de voir qu'il y a encore beaucoup d'optimisations de base (de celles qu'on apprend après 2 jours d'assembleur) qui ne sont pas effectuées.
La politique actuelle consiste à se dire "le compilo sait ce qu'il fait, y'a ouatmille caches, les tables de cycles c'est fini maintenant c'est tout contextuel, etc...", bon admettons, mais faut quand-même pas se moquer du codeur assembleur, il y a des limites. Maintenant, on a plein d'options d'optimisation -Wtrucmuche et c'est à se demander parfois si c'est pas plutôt pour faire joli. Personnellement, j'en suis resté au "un jour, les compilos sauront ce qu'ils feront". Mouais, mais quand ? :)
-- Tek
kanze
Alexandre Bacquart wrote in message news:<41110d46$0$29376$...
wrote:
sont mis ds la pile en premier l'adresse de retour de l'appel le dernier argument d'appel ... le 1er argument puis il initialise le 'pointeur de base' ( registre BP) sur le début de la structure d'appel ( notre call frame)
C'est curieux. Ça ressemble à ce qu'on faisait il y a quinze ans, sur 8086. Je m'attendrais à ce qu'un compilateur moderne fasse mieux (certains paramètres dans des régistres).
Haha tu rigoles ?!
Pas du tout. Ça fait un moment que je ne travaille pas sur des PCs ; actuellement, je travaille sur des Sparc, et que ce soit le compilateur Sun ou le compilateur g++, j'aurais du mal à faire mieux à la main. (En général. Il y a toujours de temps en temps un truc qu'ils ratent. Mais c'est l'exception.)
Honnêtement je me pose la même question depuis des années et ça fait vraiment plaisir de voir que je suis pas le seul. Même aujourd'hui en 2004, quand il m'arrive de désassembler du code généré par un compilateur moderne, je suis horrifié de voir qu'il y a encore beaucoup d'optimisations de base (de celles qu'on apprend après 2 jours d'assembleur) qui ne sont pas effectuées.
Je me pose la question... J'ai entendu dire que les derniers compilateurs de Microsoft font une analyse entre-modules, lors de l'édition des liens, en se servant des informations du profiler. Alors, si la fonction est dans un chemin critique, le compilateur le met carrément en ligne (et donc, les conventions d'appel n'entrent pas en ligne de jeu), et sinon, c'est qu'elle n'est pas appelée assez souvent pour que les conventions d'appel jouent une rôle sur le temps total d'exécution.
Mais ce de la spéculation de ma part. Je ne travaille pas assez sur PC pour dire au juste ce que font ou ne font pas les compilateurs. C'est juste pour mettre la question des conventions d'appel en perspective.
-- James Kanze GABI Software http://www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Alexandre Bacquart <tek512@hotmail.com> wrote in message
news:<41110d46$0$29376$626a14ce@news.free.fr>...
kanze@gabi-soft.fr wrote:
sont mis ds la pile en premier l'adresse de retour de l'appel
le dernier argument d'appel
...
le 1er argument
puis il initialise le 'pointeur de base' ( registre BP) sur le début
de la structure d'appel ( notre call frame)
C'est curieux. Ça ressemble à ce qu'on faisait il y a quinze ans,
sur 8086. Je m'attendrais à ce qu'un compilateur moderne fasse mieux
(certains paramètres dans des régistres).
Haha tu rigoles ?!
Pas du tout. Ça fait un moment que je ne travaille pas sur des PCs ;
actuellement, je travaille sur des Sparc, et que ce soit le compilateur
Sun ou le compilateur g++, j'aurais du mal à faire mieux à la main. (En
général. Il y a toujours de temps en temps un truc qu'ils ratent. Mais
c'est l'exception.)
Honnêtement je me pose la même question depuis des années et ça fait
vraiment plaisir de voir que je suis pas le seul. Même aujourd'hui en
2004, quand il m'arrive de désassembler du code généré par un
compilateur moderne, je suis horrifié de voir qu'il y a encore
beaucoup d'optimisations de base (de celles qu'on apprend après 2
jours d'assembleur) qui ne sont pas effectuées.
Je me pose la question... J'ai entendu dire que les derniers
compilateurs de Microsoft font une analyse entre-modules, lors de
l'édition des liens, en se servant des informations du profiler. Alors,
si la fonction est dans un chemin critique, le compilateur le met
carrément en ligne (et donc, les conventions d'appel n'entrent pas en
ligne de jeu), et sinon, c'est qu'elle n'est pas appelée assez souvent
pour que les conventions d'appel jouent une rôle sur le temps total
d'exécution.
Mais ce de la spéculation de ma part. Je ne travaille pas assez sur PC
pour dire au juste ce que font ou ne font pas les compilateurs. C'est
juste pour mettre la question des conventions d'appel en perspective.
--
James Kanze GABI Software http://www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Alexandre Bacquart wrote in message news:<41110d46$0$29376$...
wrote:
sont mis ds la pile en premier l'adresse de retour de l'appel le dernier argument d'appel ... le 1er argument puis il initialise le 'pointeur de base' ( registre BP) sur le début de la structure d'appel ( notre call frame)
C'est curieux. Ça ressemble à ce qu'on faisait il y a quinze ans, sur 8086. Je m'attendrais à ce qu'un compilateur moderne fasse mieux (certains paramètres dans des régistres).
Haha tu rigoles ?!
Pas du tout. Ça fait un moment que je ne travaille pas sur des PCs ; actuellement, je travaille sur des Sparc, et que ce soit le compilateur Sun ou le compilateur g++, j'aurais du mal à faire mieux à la main. (En général. Il y a toujours de temps en temps un truc qu'ils ratent. Mais c'est l'exception.)
Honnêtement je me pose la même question depuis des années et ça fait vraiment plaisir de voir que je suis pas le seul. Même aujourd'hui en 2004, quand il m'arrive de désassembler du code généré par un compilateur moderne, je suis horrifié de voir qu'il y a encore beaucoup d'optimisations de base (de celles qu'on apprend après 2 jours d'assembleur) qui ne sont pas effectuées.
Je me pose la question... J'ai entendu dire que les derniers compilateurs de Microsoft font une analyse entre-modules, lors de l'édition des liens, en se servant des informations du profiler. Alors, si la fonction est dans un chemin critique, le compilateur le met carrément en ligne (et donc, les conventions d'appel n'entrent pas en ligne de jeu), et sinon, c'est qu'elle n'est pas appelée assez souvent pour que les conventions d'appel jouent une rôle sur le temps total d'exécution.
Mais ce de la spéculation de ma part. Je ne travaille pas assez sur PC pour dire au juste ce que font ou ne font pas les compilateurs. C'est juste pour mettre la question des conventions d'appel en perspective.
-- James Kanze GABI Software http://www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Jean-Marc Bourguet
Alexandre Bacquart writes:
Haha tu rigoles ?! Honnêtement je me pose la même question depuis des années et ça fait vraiment plaisir de voir que je suis pas le seul. Même aujourd'hui en 2004, quand il m'arrive de désassembler du code généré par un compilateur moderne, je suis horrifié de voir qu'il y a encore beaucoup d'optimisations de base (de celles qu'on apprend après 2 jours d'assembleur) qui ne sont pas effectuées.
Sur le x86 il y a une bonne partie des optimisations basiques qu'on apprend apres 2 jours qui ne sont pas valables sur les pentiums et au dela. J'ai vu trop de gens reflechir avec des reflexes valables sur un 486 et oublier les impacts des unites d'executions multiples, de l'execution dans le desordre, du renommage des registres et des caches pour ne pas avoir plutot confiance au compilateur.
Cela fait longtemps que je ne joue plus a ce jeu meme pour m'amuser que quand je peux profiter du fait que je peux casser l'ABI sans trop de danger ou profiter de proprietes que le compilateur ignore et la derniere fois que je l'ai fait, j'ai utilise le compilateur pour regler la majorite des problemes ci-dessus (je garde en fait le cache pour moi, c'est une des choses que je fait encore? mieux que lui -- mais je doute que quelqu'un apprend les optimisations de cache apres 2 jours...). Dans les autres cas le compilateur gagnait trop souvent. (Et je suis trop de toute facon sur des projets a cibles multiples -- 9 cibles pour le moment -- pour que ce soit reellement rentable de jouer ce genre de jeu).
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Alexandre Bacquart <tek512@hotmail.com> writes:
Haha tu rigoles ?! Honnêtement je me pose la même question depuis
des années et ça fait vraiment plaisir de voir que je suis pas le
seul. Même aujourd'hui en 2004, quand il m'arrive de désassembler du
code généré par un compilateur moderne, je suis horrifié de voir
qu'il y a encore beaucoup d'optimisations de base (de celles qu'on
apprend après 2 jours d'assembleur) qui ne sont pas effectuées.
Sur le x86 il y a une bonne partie des optimisations basiques qu'on
apprend apres 2 jours qui ne sont pas valables sur les pentiums et au
dela. J'ai vu trop de gens reflechir avec des reflexes valables sur
un 486 et oublier les impacts des unites d'executions multiples, de
l'execution dans le desordre, du renommage des registres et des caches
pour ne pas avoir plutot confiance au compilateur.
Cela fait longtemps que je ne joue plus a ce jeu meme pour m'amuser
que quand je peux profiter du fait que je peux casser l'ABI sans trop
de danger ou profiter de proprietes que le compilateur ignore et la
derniere fois que je l'ai fait, j'ai utilise le compilateur pour
regler la majorite des problemes ci-dessus (je garde en fait le cache
pour moi, c'est une des choses que je fait encore? mieux que lui --
mais je doute que quelqu'un apprend les optimisations de cache apres 2
jours...). Dans les autres cas le compilateur gagnait trop souvent.
(Et je suis trop de toute facon sur des projets a cibles multiples --
9 cibles pour le moment -- pour que ce soit reellement rentable de
jouer ce genre de jeu).
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Haha tu rigoles ?! Honnêtement je me pose la même question depuis des années et ça fait vraiment plaisir de voir que je suis pas le seul. Même aujourd'hui en 2004, quand il m'arrive de désassembler du code généré par un compilateur moderne, je suis horrifié de voir qu'il y a encore beaucoup d'optimisations de base (de celles qu'on apprend après 2 jours d'assembleur) qui ne sont pas effectuées.
Sur le x86 il y a une bonne partie des optimisations basiques qu'on apprend apres 2 jours qui ne sont pas valables sur les pentiums et au dela. J'ai vu trop de gens reflechir avec des reflexes valables sur un 486 et oublier les impacts des unites d'executions multiples, de l'execution dans le desordre, du renommage des registres et des caches pour ne pas avoir plutot confiance au compilateur.
Cela fait longtemps que je ne joue plus a ce jeu meme pour m'amuser que quand je peux profiter du fait que je peux casser l'ABI sans trop de danger ou profiter de proprietes que le compilateur ignore et la derniere fois que je l'ai fait, j'ai utilise le compilateur pour regler la majorite des problemes ci-dessus (je garde en fait le cache pour moi, c'est une des choses que je fait encore? mieux que lui -- mais je doute que quelqu'un apprend les optimisations de cache apres 2 jours...). Dans les autres cas le compilateur gagnait trop souvent. (Et je suis trop de toute facon sur des projets a cibles multiples -- 9 cibles pour le moment -- pour que ce soit reellement rentable de jouer ce genre de jeu).
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org