Comparaison entre trois listing, comment bien analyser ?
Publié : mer. 13/juil./2011 17:22
Bonjour,
Bien que je n'y connaisse -à peu de choses prés- rien, l'ASM m'a toujours beaucoup fasciné.
Pour me changer les idées -et m'éclaircir les idées- j'ai voulu aujourd'hui comparer des listings. ( Décompilés via OllyDbg [ et je ne suis pas certain que cette démarche soit la meilleure ] )
J'ai donc voulu commencer par vérifier si une multiplication du type ( A*-1 ) était directement traduite par le compilateur comme une inversion.
Je compile donc un code du type :
Résultat dans Ollydbg :
J'en conclus qu'il serait plus judicieux -bien que trivial- d'utiliser l'opérateur NOT, afin de réaliser cette opération ( je l'utilise fréquemment dans un programme qui m’intéresse ).
J'écris donc :
Et obtiens :
Théoriquement ( si j'ai bien compris ), ce listing nécessitera moins de cycles. Mais à cette étape là, l'histoire des MOV m'interpelle.
J'ignore quelle est l'incidence d'un tel "transfert", ainsi que j'avoue ne pas avoir -beaucoup- cherché.. Mais j'imagine qu'il est dût à ce ( A=~A ), où je demanderai donc l'allocation d'une "variable" temporaire (EBX).
J'ai donc cherché à savoir si il était possible de s'épargner cette instruction, en utilisant l'assembleur en ligne.
J'écris donc :
Et obtiens :
J'en suis maintenant à me poser cette question :
Vaudrait-il le coups d'utiliser l'instruction !NOT dword[v_A] dans un macro du type inverse(a) ? ( Même si ce gain est dérisoire, c'est vraiment pour comprendre )
Question corollaire : cette histoire de MOV "" "" "",EBX est elle, à force, dans un programme, une perte inutile de cycle ?
En vous remerciant,
S.
Bien que je n'y connaisse -à peu de choses prés- rien, l'ASM m'a toujours beaucoup fasciné.
Pour me changer les idées -et m'éclaircir les idées- j'ai voulu aujourd'hui comparer des listings. ( Décompilés via OllyDbg [ et je ne suis pas certain que cette démarche soit la meilleure ] )
J'ai donc voulu commencer par vérifier si une multiplication du type ( A*-1 ) était directement traduite par le compilateur comme une inversion.
Je compile donc un code du type :
Code : Tout sélectionner
A=489
A*-1
Code : Tout sélectionner
MOV DWORD PTR DS:[4030E4],1E9
MOV EBX,DWORD PTR DS:[4030E4]
IMUL EBX,EBX,-1
MOV DWORD PTR DS:[4030E4],EBX
J'écris donc :
Code : Tout sélectionner
A=489
A=~A
Code : Tout sélectionner
MOV DWORD PTR DS:[4030E4],1E9
MOV EBX,DWORD PTR DS:[4030E4]
NOT EBX
MOV DWORD PTR DS:[4030E4],EBX
J'ignore quelle est l'incidence d'un tel "transfert", ainsi que j'avoue ne pas avoir -beaucoup- cherché.. Mais j'imagine qu'il est dût à ce ( A=~A ), où je demanderai donc l'allocation d'une "variable" temporaire (EBX).
J'ai donc cherché à savoir si il était possible de s'épargner cette instruction, en utilisant l'assembleur en ligne.
J'écris donc :
Code : Tout sélectionner
A = 489
!NOT dword[v_A]
Code : Tout sélectionner
MOV DWORD PTR DS:[4030E4],1E9
NOT DWORD PTR DS:[4030E4]
J'en suis maintenant à me poser cette question :
Vaudrait-il le coups d'utiliser l'instruction !NOT dword[v_A] dans un macro du type inverse(a) ? ( Même si ce gain est dérisoire, c'est vraiment pour comprendre )
Question corollaire : cette histoire de MOV "" "" "",EBX est elle, à force, dans un programme, une perte inutile de cycle ?
En vous remerciant,
S.