Compiler verdreht die Befehle, Sinn?
-
Aus folgendem C++ - Code erzeugt der MSVC++ den nachfolgenden Assemblercode:
colv->ScrollFlags^=1; Beep(440,100); Beep(440,100);
mov edi, dword ptr [0040A0B8] ;Adresse der Funktion in EDI schreiben xor al, 01 ;die EXOR-Verknüpfung push 00000064 ;den zweiten Parameter auf den Stack pushen push 000001B8 ; " ersten " " " mov byte ptr [esi+21], al ;das Ergebnis der EXOR-Verknüpfung speichern call edi ;die Funktion aufrufen push 00000064 ;wieder die Parameter push 000001B8 call edi ;nochmal die Funktion aufrufen
Meine Frage ist jetzt: Macht das Sinn, dass er die EXOR-Verknüpfung so zwischen dem ersten Aufruf der Funktion macht oder was (muss wohl tiefergehende Gründe haben)? Er könnte doch erst die EXOR-Vernüpfung machen, das Ergebnis speichern und als nächsten Schritt die Adresse der Funktion in EDI schreiben und sie zweimal Aufrufen, also so, wie es auch im C++ - Code steht.
-
Original erstellt von D@niel $chumann:
Meine Frage ist jetzt: Macht das Sinn, dass er die EXOR-Verknüpfung so zwischen dem ersten Aufruf der Funktion macht oder was (muss wohl tiefergehende Gründe haben)? Er könnte doch erst die EXOR-Vernüpfung machen, das Ergebnis speichern und als nächsten Schritt die Adresse der Funktion in EDI schreiben und sie zweimal Aufrufen, also so, wie es auch im C++ - Code steht.Jap, macht es
Die Sache ist die dass moderne Prozessoren mehrere Pipelines haben, sozusagen Fließbänder an denen Befehle abgearbeitet werden. Wenn du nun beide Pipelines effektiv nutzen möchstest, sollten imemr aufeinanderfolgende Befehle parallel abarbeitbar sein. Wenn nun der eine Befehl die xor-verknüpfung ist und der nächste das Speichern, so kann der Prozessor das nicht parallel machen und die Pipeline steht eventuell nen Moment. Das ist ineffektiv, deswegen paar der Compiler das xor lieber mit dem Speichern in edi, denn die beiden dinge stehen sich nicht im Weg. Wenn du dem Compiler jegliche Optimierung verbieten würdest, würde vermutlich das von dir erwartete Ergebnis kommen, aber im allgemeinen soll ein Kompilat ja effizient und nicht lesbar sein
-
Cool, dass der Compiler an sowas denkt ;).
Danke