IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

C++ Discussion :

[C++ <-> ASM] Interaction


Sujet :

C++

  1. #1
    Membre confirmé Avatar de lXT95l
    Profil pro
    Inscrit en
    Novembre 2006
    Messages
    106
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2006
    Messages : 106
    Par défaut [C++ <-> ASM] Interaction
    Bonjour,
    j'ai trouvé ce code sur internet (pour VC++):
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
     
    __forceinline float sin(float v)
    {
    	volatile float res;
    	__asm
    	{
    		fld v
    		fsin
    		fstp res
    	}
    	return res;
    }
    J'ai essayé de l'adapter pour mon programme qui est compilé avec g++:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
     
    float sin(float x)
    {
    	volatile float res;
    	asm("fld x");
    	asm("fsin");
    	asm("fstp res");
    	return res;
     
    }
    Et voici l'erreur que j'obtient :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    tool.cpp:6: undefined reference to `res'
    (Je précise que je n'ai jamais touché a de l'asm, mais j'ai absolument besoin de ce code )

    Merci de votre aide.

  2. #2
    Expert confirmé

    Inscrit en
    Août 2006
    Messages
    3 967
    Détails du profil
    Informations forums :
    Inscription : Août 2006
    Messages : 3 967
    Par défaut
    Kai,

    C'est parce que tu ne respectes pas l'intégralité de la syntaxe AT&T:

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    float mysin(float v)
    {
        float res ;
     
        __asm__ (
            "fld %1\n"
            "fsin\n"
            "fstp %0\n"
            : "=m" (res)
            : "m" (v)
            :
        );
        return res;
    }
     
    int main()
    {
        float pis180 = 3.141592/180.0;
     
        float ang = 45 * pis180;
        float si = mysin(ang);
     
        printf("si = %f\n",si);
     
        return EXIT_SUCCESS;
    }
    Résultat :
    ce qui est la valeur attendue.

  3. #3
    Membre confirmé Avatar de lXT95l
    Profil pro
    Inscrit en
    Novembre 2006
    Messages
    106
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2006
    Messages : 106
    Par défaut
    Merci beaucoup, oui j'avais vu qu'il y avait différente syntaxe pour l'asm, je crois que je vais me renseigner un peu plus a ce sujet, en tout cas probleme résolu merci beacoup =)

  4. #4
    Expert éminent
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    Octobre 2004
    Messages
    11 644
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : Octobre 2004
    Messages : 11 644
    Par défaut
    Salut,

    Ceci dit, il n'est nullement indispensable de passer par de l'assembleur pour obtenir un sinus, et c'est meme, pour tout dire, plutot déconseillé...

    L'assembleur a, en effet, l'énorme inconvéniant d'être fortement dépendant de la plateforme et du processeur utilisé, alors que l'ensemble des fonctions, dont entre autres, les fonctions trigonométriques, sont déclarées et définies dans le fichier <cmath>.

    Ainsi, il sera bien plus portable d'écrire un code "pur C++" du genre de
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
     
    /* sin() et cos() utilisent plusieurs prototypes:
     * double sin(double)            double cos(double)
     * float sin( float)             float cos(float)
     * long double sin(long double)  long double cos (long double)
     */
    #include <cmath> /* pour les fonctions mathématiques */
    #include <iostream> /* pour l'affichage */
    int main()
    {
        /* Il est toujours préférable d'éviter les nombres magiques  ;) */
        const float PI=3.1415926;
        /* n'oublions pas que les fonctions trigonométriques nécessitent des
         * valeurs d'angles en radian
         */
        double angle=30.0;
        double res=sin(angle*PI/180);
        double res2=cos(angle*PI/180);
        std::cout<<"sin("<<angle<<")="<<res<<"    cos("<<angle<<")="<<res2;
        return 0;
    }
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  5. #5
    Expert confirmé

    Inscrit en
    Août 2006
    Messages
    3 967
    Détails du profil
    Informations forums :
    Inscription : Août 2006
    Messages : 3 967
    Par défaut
    Pia,
    Citation Envoyé par koala01
    Ceci dit, il n'est nullement indispensable de passer par de l'assembleur pour obtenir un sinus, et c'est meme, pour tout dire, plutot déconseillé...
    On est bien d'accord, mais la demande était une procédure en assembleur.

    Le côté portable est vrai également, mais sincèrement, tu connais beaucoup de programmeurs qui ont réellement besoin d'avoir du code portable sur n'importe quelle plateforme et/ou technologie ?

    J'en connais, mais ils sont tout de même rares par rapport à l'ensemble de la communauté des programmeurs.

    Mais il reste qu'il est mieux de faire comme si.

  6. #6
    Expert éminent
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    Octobre 2004
    Messages
    11 644
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : Octobre 2004
    Messages : 11 644
    Par défaut
    Citation Envoyé par droggo
    Pia,

    On est bien d'accord, mais la demande était une procédure en assembleur.
    La remarque s'adressait en priorité à lXT95l, des fois qu'il fut persuadé qu'il n'existait pas d'équivalent
    Le côté portable est vrai également, mais sincèrement, tu connais beaucoup de programmeurs qui ont réellement besoin d'avoir du code portable sur n'importe quelle plateforme et/ou technologie ?
    Peux tu jurer que, quoi que tu fasse, rien n'est destiné à, un jour peut etre, devoir tourner sur une plateforme ou technologie que tu n'a pas prévu à la base

    La probabilité, qui dit minue (minue!!! minue!!!) dans une politique "propriétaire" est malgré tout tres forte si tu travaille dans une optique de code source plus ouverte
    J'en connais, mais ils sont tout de même rares par rapport à l'ensemble de la communauté des programmeurs.

    Mais il reste qu'il est mieux de faire comme si.
    De prime abord, j'aurais presque tendance à citer tous ceux qui s'investissent, d'une manière ou d'une autre dans l'open-source

    Et, de fait, quitte à ne pas pouvoir jurer du contraire, l'idéal reste toujours de faire comme s'il était question de permettre le passage vers une autre plateforme ou architecture pour hier
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  7. #7
    Expert éminent
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    Octobre 2004
    Messages
    11 644
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : Octobre 2004
    Messages : 11 644
    Par défaut
    Ceci dit, je ne peux te reprocher de ne pas penser à une compatibilité maximale...

    Mais la dernière grosse boite à ne pas avoir pris cette compatibilité en compte a quand meme du reporter de trois ans la sortie de son système d'exploitation... et fournir un pale herztaz de son "vieux" systeme lors de la sortie des processeur 64 bits...

    Meme si ce ne sera surement pas moi qui m'en plaindrai
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  8. #8
    Membre confirmé Avatar de lXT95l
    Profil pro
    Inscrit en
    Novembre 2006
    Messages
    106
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2006
    Messages : 106
    Par défaut
    Oui je connaissais cmath, mais je suis entrain de faire une intro 4k et je peux pas rentrer la lib standard dedans

  9. #9
    Expert confirmé

    Inscrit en
    Août 2006
    Messages
    3 967
    Détails du profil
    Informations forums :
    Inscription : Août 2006
    Messages : 3 967
    Par défaut
    Jai,
    Citation Envoyé par koala01
    Ceci dit, je ne peux te reprocher de ne pas penser à une compatibilité maximale...

    Mais la dernière grosse boite à ne pas avoir pris cette compatibilité en compte a quand meme du reporter de trois ans la sortie de son système d'exploitation... et fournir un pale herztaz de son "vieux" systeme lors de la sortie des processeur 64 bits...

    Meme si ce ne sera surement pas moi qui m'en plaindrai
    Je ne suis pas "une grosse boite", et il est parfaitement clair que mes programmes n'auront pas à tourner sur autre chose que de l'architecture PC, Intel ou AMD.

    Si plus tard quelqu'un a besoin d'utiliser mes sources, ce dont je doute, à lui de se débrouiller. Tout est commenté, bien expliqué, etc.

    Et nombreux, très nombreux sont les programmeurs dans mon cas.

    La stricte portabilité, c'est bien, et important, mais ça ne concerne pas forcément tout le monde, et il faut arrêter un peu avec cet air, qui commence à... (termine toi-même ).

    Si dans 50 ans ils ont encore besoin de mon code, c'est qu'ils auront des problèmes autrement plus graves que la portabilité du code.

  10. #10
    Rédacteur/Modérateur
    Avatar de JolyLoic
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2004
    Messages
    5 463
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 50
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Août 2004
    Messages : 5 463
    Par défaut
    J'ai déjà été dans le cas où je pensais qu'un bout de code n'avait pas destination à être portable, et où il a fallu le porter...

    Ensuite, portable veut dire portable en terme de processeur (et là, en plus de prendre en compte l'architecture PC, il y a quand même d'autres choses courantes, comme sparc, (je ne sais plus pour mac ce qu'il en est), tout ce qui est appareil portable,... et même simplement PC, la portabilité 32 bits/64 bits se pose), mais aussi portable en terme d'OS (par exemple, les boîtes faisant du soft uniquement windows commencent à perdre toute l'administration française en terme de client potentiel, et toute l'administration française, ça fait un sacré budget) ou portable en terme de compilateur.

    Alors, bien sur, la portabilité à 100% sans compromis, faut pas exagérer, mais un minimum de portabilité me semble une bonne chose (surtout quand les source de non-portabilité sont en fait une exploitation de comportement indéfini). En l'occurrence, la solution portable est aussi plus simple et plus rapide à écrire, alors pourquoi s'en priver... Et l'utilisateur a besoin de portabilité, puisqu'il son problème à la base est justement un problème de portabilité VC++ / g++.
    Ma session aux Microsoft TechDays 2013 : Développer en natif avec C++11.
    Celle des Microsoft TechDays 2014 : Bonnes pratiques pour apprivoiser le C++11 avec Visual C++
    Et celle des Microsoft TechDays 2015 : Visual C++ 2015 : voyage à la découverte d'un nouveau monde
    Je donne des formations au C++ en entreprise, n'hésitez pas à me contacter.

  11. #11
    Expert confirmé

    Inscrit en
    Août 2006
    Messages
    3 967
    Détails du profil
    Informations forums :
    Inscription : Août 2006
    Messages : 3 967
    Par défaut
    Lai,
    Citation Envoyé par JolyLoic
    J'ai déjà été dans le cas où je pensais qu'un bout de code n'avait pas destination à être portable, et où il a fallu le porter...

    Ensuite, portable veut dire portable en terme de processeur (et là, en plus de prendre en compte l'architecture PC, il y a quand même d'autres choses courantes, comme sparc, (je ne sais plus pour mac ce qu'il en est), tout ce qui est appareil portable,... et même simplement PC, la portabilité 32 bits/64 bits se pose), mais aussi portable en terme d'OS (par exemple, les boîtes faisant du soft uniquement windows commencent à perdre toute l'administration française en terme de client potentiel, et toute l'administration française, ça fait un sacré budget) ou portable en terme de compilateur.

    Alors, bien sur, la portabilité à 100% sans compromis, faut pas exagérer, mais un minimum de portabilité me semble une bonne chose (surtout quand les source de non-portabilité sont en fait une exploitation de comportement indéfini). En l'occurrence, la solution portable est aussi plus simple et plus rapide à écrire, alors pourquoi s'en priver... Et l'utilisateur a besoin de portabilité, puisqu'il son problème à la base est justement un problème de portabilité VC++ / g++.
    Bien sûr, et c'est ce que je fais.

    Mais le côté "absolument, totalement portable" commence à me gaver sérieusement.

    Et je parlais d'architecture, car j'utilise fréquemment l'assembleur, pour des raisons d'optimisations de temps de calcul.

    J'en vois déjà qui vont sauter au plafond et me dire "Les compilateurs modernes savent mieux optimiser que l'humain".
    Ils ont partiellement raison, pour la partie que les compilateurs savent faire, et encore, même là, ce n'est pas toujours le cas.

    Mais a-t-on déjà vu un compilateur utiliser spontanément les mmx, sse, etc. quand leur emploi optimise les performances ?

    Personnellement, je n'en connais pas (ce qui ne signifie pas que ça n'existe pas, et encore moins que ça ne peut pas exister).

  12. #12
    Expert confirmé
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Décembre 2003
    Messages
    3 549
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Décembre 2003
    Messages : 3 549
    Par défaut
    Mais a-t-on déjà vu un compilateur utiliser spontanément les mmx, sse, etc. quand leur emploi optimise les performances ?
    Bien entendu. Ça s'appelle de l'auto-vectorisation.
    La plupart des compilateurs le font.

  13. #13
    Expert confirmé

    Inscrit en
    Août 2006
    Messages
    3 967
    Détails du profil
    Informations forums :
    Inscription : Août 2006
    Messages : 3 967
    Par défaut
    Kai,
    Citation Envoyé par loufoque
    Bien entendu. Ça s'appelle de l'auto-vectorisation.
    La plupart des compilateurs le font.
    Lesquels, quand, où, comment ?

    Si "la plupart" exclu les plus utilisés, ça ne signifie pas grand chose.

    Je n'ai jamais vu ça, en tout cas avec les compilateurs que j'ai l'occasion d'utiliser (VC++, gcc, g++, Intel C++, le tout depuis de nombreuses versions).

    Et ce n'est pas faute de vérifier : je contrôle assez régulièrement le code généré, j'ai parfois vu du MMX, uniquement pour certaines copies de mémoire, jamais de SSE.
    J'aimerais que ça le fasse effectivement, ça m'éviterait d'avoir à maintenir mes librairies assembleur.

  14. #14
    Expert confirmé
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Décembre 2003
    Messages
    3 549
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Décembre 2003
    Messages : 3 549
    Par défaut
    Lesquels, quand, où, comment ?
    C'est un système automatique, donc bien évidemment ça marche plus ou moins bien.
    Ça vectorise principalement les boucles.
    Quelques infos pour GCC :
    http://gcc.gnu.org/projects/tree-ssa/vectorization.html

    Je n'ai jamais vu ça, en tout cas avec les compilateurs que j'ai l'occasion d'utiliser (VC++, gcc, g++, Intel C++, le tout depuis de nombreuses versions).
    Je ne sais pas pour VC++, mais GCC et Intel C++ le font.

    J'aimerais que ça le fasse effectivement, ça m'éviterait d'avoir à maintenir mes librairies assembleur.
    Je ne sais pas pour VC++, mais les autres disposent de built-ins pour exprimer la vectorisation de manière plus ou moins indépendante de l'architecture. Il n'y a donc pas besoin d'utiliser de l'assembleur, c'est portable, et en plus c'est plus agréable à manipuler.
    http://gcc.gnu.org/onlinedocs/gcc-4....tor-Extensions

  15. #15
    Expert confirmé

    Inscrit en
    Août 2006
    Messages
    3 967
    Détails du profil
    Informations forums :
    Inscription : Août 2006
    Messages : 3 967
    Par défaut
    Kia,
    Citation Envoyé par loufoque
    C'est un système automatique, donc bien évidemment ça marche plus ou moins bien.
    Ça vectorise principalement les boucles.
    Quelques infos pour GCC :
    http://gcc.gnu.org/projects/tree-ssa/vectorization.html


    Je ne sais pas pour VC++, mais GCC et Intel C++ le font.


    Je ne sais pas pour VC++, mais les autres disposent de built-ins pour exprimer la vectorisation de manière plus ou moins indépendante de l'architecture. Il n'y a donc pas besoin d'utiliser de l'assembleur, c'est portable, et en plus c'est plus agréable à manipuler.
    http://gcc.gnu.org/onlinedocs/gcc-4....tor-Extensions
    Comment ai-je pu passer à travers ça ?

    Merci pour les liens, je vais voir ce que ça donne.

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. [mode svga][Voir asm et devc++]
    Par Gonath dans le forum Autres éditeurs
    Réponses: 16
    Dernier message: 16/06/2003, 08h58
  2. Coloration syntaxique ASM dans un RichEdit
    Par Crick dans le forum Composants VCL
    Réponses: 5
    Dernier message: 20/12/2002, 01h53
  3. Allocation dynamique de mémoire en asm
    Par narmataru dans le forum Assembleur
    Réponses: 7
    Dernier message: 17/12/2002, 22h31
  4. Reboot en asm ou C++
    Par Juke dans le forum x86 16-bits
    Réponses: 6
    Dernier message: 17/10/2002, 09h11
  5. [TP]code asm dans une procedure
    Par M.Dlb dans le forum Turbo Pascal
    Réponses: 3
    Dernier message: 17/08/2002, 20h43

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo