bon, je suis en train de tester les capacité du calcul flottant de mon proco, mais el problème c´est que 8 registre de calcul c´est pas mal, mais pas suffisant pour mon calcul.

donc il faut que je stocke les valeur intermédiaires dans la mémoire.

le seul problème c´est que je ne peut pas les sotcker en utiliant les nom de variable de mon programme sinon les valeurs seront tronqué à 64 bits et ce que je fait n´a plus d´interet.

donc comment faire pour avori droit à des variables de 10 octets come il se doit : comment déclare-t-on des variables ( c´est a dire que je sais qu´on ne le fait pas vraiment, mais comment a-t-on des bon pointeurs).

tout ça c´est de l´asm inline avec vc++

Sinon j´ai découvert comment il réussissait à faire réellement des calcul uniquement en 64 bits en débuggant un programme que j´ai fait : il n´utilise qu´à peine les registre de du FPU, mais à chaque opération il charge les opérende depuis la mémoire, ( en 64 bits) donc c´estvraiment pas efficace surtout au sein d´une boucle.

En plus il n´y a même pas de gain de temps vu qu´a chaque fois les opérande sont d´abord convertit en 80 bits avant de faire les calcul.

vive l´ASM pour optimiser les programme.
Entout cas, je ne croirais plus jamais qqn qui dit que le compilo optimise mieux que moi, vu les horreur qu´il écrit, c´est impossible.

ben d´un côté, si tu l´as pris au debugger, c´est un peu normal que tu vois des horreurs dans l´ASM généré :/ Pour vraiment savoir ce qui se passe, il faudrait compiler en release et faire du reverse engineering dessus avec un décompilateur.
essaye avec un compilo dédié à ta plateforme ( P4 si j´ai bien retenu) : IC++ fait des miracles...

IC++ est un peu hors de prix.

non, j´ai compilé en release de toute façon ( optimisé pour la vitesse) et je le debug avec OllyDbg.

pour l´instant, j´ai réussi à réécrire mon code pour que les calcul tienne dans les 8 registre du FPU, mais j´ai quand même un problème : ya une opération, un simple FLD pour dupliquer le contenu du registre ST(0) qu´il ne veut pas faire, tout va bien jusqu´au moment, où il l´exécute et alors le registre ST(0) devient BAD, je ne sais pas pourquoi il le marque comme un NaN, mais c´est le cas et après plus aucun calcul ne marche vu que le NaN se propage.

http://wall.cours-info.net/?id=326
si qqn a la bonté de regarder ou si ça rappel un problème connu, je vous suis très reconnaissant

Pour avoir vu nombre de cochonneries que divers compilos avaient fait ( VC++ certes, mais aussi gcc avec mon OS), ça fait longtemps que je suis convaincu que les compilos optimisent comme des guignols. Tout au plus ils font des optimisations bébètes à la shl, le reste n´est pas fabuleux.

Un humain pwn le compilo pour l´optiz. J´ai toujours été convaincu de ça, et je le crois encore plus à force de voir du code-poubelle que sortent les compilos modernes. Et des fois ça frise l´absurde, Chris l´avait montré une bonne fois ( VC++7 qui faisait euh m´enfin voyez ça par vous même https://www.jeuxvideo.com/forums/1-47-5249-1-0-1-0-0.htm )

En fait moi je suis une vraie merde question FP, Chris est une bête en ça, il faudrait que je le contacte...

Kelios
---------

en fait, j´ai réussi à résoudre mon problème, j´avais inversé un ST(0) et un ST(1) et ça faisait tout foiré. le seul truc qui m´ennuie, c´est qu´au final, c´est terriblement lent d´une part et d´autre part ça ne marche pas...

comme quoi les compilo ont certain avantages...

Meuh non, c´est à cause que ton code est pas bon:
Si tu codais mal en C++, le compilo ferait du mauvais code aussi...

Donc ça n´a rien àvoir avec le compilo, si le code est bon ou mauvais, tout dépend de towé...

Maintenant, si tu es meilleur en C++ qu´en asm, il t´en tient qu´à toi de devenir un Asm Mastarz

Kelios
---------

oui, c´est ce que je dit, que je code en asm très mal, donc que le compilo est mieux.

le problème c´est que si je copie ce que fait le compilo c´est a dire utilisé très peu les registre du FPU et tout le temps charger les valeurs dans la RAM, c´est peut-être plus rapide, mais tant que les valeurs sont les tiennes sur 64 bits c´est mauvais.

pour m´aider à devenir un asm mastarz(!) tu connaitrait une endroit ou je trouve la liste des nombre de cycle requi par instruction ? parce que j´ai un fichier ou ça y est, mais il est vieux et il n´y a que très très peu d´instruction, et dans la doc intel, je ne l´ai pas trouvé ( c´est pas dans les 4 pdf des spécification du pentium 4, alors je ne sais pas trop ou ça pourrait être).

Dans le manuel d´optimization, t´as cherché? Tu sais, ce manuel que tous ont téléchargé mais que nul n´ont pensé regarder...
" ( c´est pas dans les 4 pdf des spécification du pentium 4, alors je ne sais pas trop ou ça pourrait être)." -> hmmm

De toute façon, ça ne servirait pas à grand chose. De nos jours, ça dépend de tant de choses! C´est pratiquement du cas par cas, à cause du cache, du pipelining, des clock cycles du proc mais aussi du bus, de leur synchronisation, de 1001 trucs pour t´emmerder.

Masm avait bien un truc, cherche opcode.hlp, un truc du genre, dans son dossier HELP, mais ça s´arrêtait au 486.

Kelios
---------

le opcode.hlp c´est celui que j´ai je croit.

merci pour le manuel d´optimisation, ej ´lavais pas celui là, mais je l´ai trouvé ( enfin je crois).

il est interessant, mais il dit qu´il ne faut pas se fier au nombre de cycle par instruction ( !) et de toute façon sur le sujet il n´est pas passez précis puice qu´il donne le temps pour FMUL par exemple sans préciser les opérande qu´il utilise ( mémoire ou registre).

bon, je vais essayer d´optimiser déjà au niveau mathématique.

Jcrois que j´aimerais bien apprendre l´asm moi