Salut,
 
Je me suis amusé à déassembler le code d'une dll que j'avais codé en C++ et voilà ce que j'obtiens :

 
On comprends pourquoi le code est de plus en plus lent  

 
c'est une blague

Et non  

c'est quoi comme compilo ?
 
il est en mode debug pas convaincu ?

Microsoft Visual C++ 6.0 et pas en mode DEBUG or whatever  

 
ils le font plusieurs fois pour etre sur que l'instruction s'execute bien

serieux, tu es dans une zone de données, c'est pour ca que ca fait n'importe quoi

C'est à dire ?  

c'est ce que je me disais, mais le .text c'est le segment de code non ? (et non de données initialisés)
 
ou je suis super fatigué et il faut que j'ailles me coucher ?

AthlonSoldier >> c'est partout pareil ? (si tu désassemnble depuis un point d'entrée de fonction)
ou c'est uniquement à cet endroit ?

C'est que a cet endroit  

ben si le desassembleur ne retrouve pas ses petits, il referencera l'adresse par rapport a la derniere zone connue
et rien ne t'empeche de mettre des datas en plein milieu de ton code (si tu ne le declare pas en .data)

Ah tu veux dire que j'ai deasm les data et interprete les "opcodes" en tant que code assembleur ?    
Non ca je peux te l'assurer, c'est bien un extrait du code généré par le compilo  

moi je sais que quand je desassemble un prog, je regarde d'abord le fichier binaire avec un editeur hexa, ca me permet de situer les zones code et les zones data
dans les zones codes, y a n'importe quoi, alors que les zones data, on a soit des zero, soit des ensembles repetitifs

C'est l'extrait d'une fonction qui prends en entrée 1 char + 1 pointeur sur une string, et en sortie qui renvoit 1 char  

c'est vrai que le désassembleur peut se paumer en chemin, et se décaler au niveau des octets. (d'autant plus que les points d'entrée de fonctions sont ptet alignées sur des para, et qu'il fout des conneries entre).
 
ché pas compile la DLL en générant le listing ASM pour voir à quel code C++ le truc fait du n'imp.

 
si c'est vrai tu dois avoir une sequence de pop suivie d'un "ret"

   
Si ca peut te rassurer j'utilise tous les jours des désassembleurs, je sais où je me trouve t'inquiete  
EDIT : C'est juste que ca m'a bien fait marrer le code trop optimisé  

tu as le bout en "c" correspondant??

Pour des raisons personnelles, je ne peux pas le diffuser  

meme le tout petit bout correspondant ?

Non, désolé.    
Peu importe le code C++ (et c'est pas un fake avec un __asm__{ })...
Le truc qu'il faut retenir c'est qu'un compilateur il compile, on est pas encore arriver a des compilateurs intelligent qui relise le code et font "putain c'est con de faire ca, je change"  

 
dommage, ceci dit ca me rappel qq chose, une simple operation sur des integer qui partait en couille comme ca, alors qu'en flottant c'etait impec
 
remarque quand on voit
 

 
on touche au sommet de la prog optimisée
ca doit correspondre a une boucle "for i++"

 
tu l'as servce packé ton VS 6.0 ?

Ou des trucs de ce genre (deja vu aussi) :

 
Or eax etait forcement deja à 0, pas besoin de le remettre a 0    
Simplement le compilateur est con et fonctionne par "bloc" a traduire sans tenir compte des autres precedants (et des etat des registres)  

C'est pas un probleme de VS patché ou pas, c'est commun a tous les compilateurs, c'est du code vraiment de compilateur quoi  

tu as essayé d'autres options d'optimisation??
là t'es ptet en priorité a la vitesse??

Peu importe    
Le but n'etait pas d'optimiser mon code  

ah ben là t'as reussi

 
pour VS 6.0 si clairement.
 
ensuite, les compilos font généralement bien leur boulot.
là c'est encore VS 6.0 was here.
 
le watcom de 1996 faisait mieux que ça, donc ton VS il a un problème quand même fo pas déconner non plus.

Ok si tu le dis  

sérieusement, ton VS 6.0 il est à quel service pack ?
 
parce que, que l'on trouve des défauts de génération de code, ouais, mais 3 fois le même masquage de bits, fo le vouloir

à ce jour c'est SP5 et PP5

 
ca a pour moi une superbe tronche de code debug, ou la variable 'destination' d'une expression est obligatoirement spillé a la fin de ladite expression  .Generalement le compilo fout quand meme le compteur dans ecx

attention les instructions bidons avant une boucle c'est pour aligner sur 16 octets. et plutôt que de faire 16 nop, il écrivent des instructions longues.
Celà dit j'ai souvent désassemblé du code compilé pour voir si une optim ASM valait le coup et j'ai souvent été impressionné par la quantité d'instructions inutiles insérées. Il y a par exemple beaucoup de pop et push pour récupérer des registres alors que l'algo se satisafait de 2 registres sans pb.

Aligner sur 16 octets ?    
Pourquoi ?

 
fo faire gaffe au convention de preservation de reg lors de l'appel d'une fonction

putain c'est vrai que faut en vouloir pour faire une capture comme ça en jpg. avant de vouloir optimiser le code de ton voisin, commence  la poutre qui est dans ton oeil

 
ché pas, avoir le début de la boucle qui tombe facilement sur le début d'une ligne de cache par exemple (je veux dire peut être).

le code dans des boucles c'est comme les données : c'est mieux quand c'est aligné. Et sur les proc récents, le top c'est aligné sur 16 octets. Un pentium se contente de 4 octets mais 16 ça satisfait tt le monde.
Quand à la présevation ça se fait entre l'appel et le retour. Là je parle de pop et push dans le corps d'une fonction. En pushant esi, edi, ebp et ebx au début on peut bosser sur 7 registres tranquilement. Faut juste les poper avant le ret. En assembleur MASM c'est automatisable (directive USES). Les compilo ont tendance à faire des pop et des push plusieurs fois sur le même registre.
La baisse de perfs est masquée par le goulot d'étranglement mémoire. Perso qd je bench je le fait sur un vieux proc où le bus mémoire sature le bus procésseur : un pmmx avec de la PC100 en 2-2-2. Là on voit la diff entre c compilé et assembleur manuel !