Discussion :

[lXT95l]

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.

[droggo]

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 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

si = 0.707107

ce qui est la valeur attendue.

[lXT95l]

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 =)

[koala01]

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;
}

[droggo]

Pia,

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.

[koala01]

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

[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

[lXT95l]

Oui je connaissais cmath, mais je suis entrain de faire une intro 4k et je peux pas rentrer la lib standard dedans

[droggo]

Jai,

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.

[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++.

[droggo]

Lai,

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).

[loufoque]

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.

[droggo]

Kai,

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.

[loufoque]

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

[droggo]

Kia,

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.