4. Seltsame Compileroptimierung verstehen

Seltsame Compileroptimierung verstehen

  • I

    Hi.

    Ich bin gerade wieder fleißig am Windowsprogramme reversen, nur verwirrt mich gerade etwas. Nämlich das hier:

    .text:005936FE                 mov     esi, [ecx+8]
.text:00593701                 mov     eax, [esi+8]
.text:00593704                 mov     edx, eax
.text:00593706                 shr     edx, 3
.text:00593709                 test    dl, 1
.text:0059370C                 jz      short loc_59371E

    Oder etwas in Pseudocode:

    objType = *(_DWORD *)(objDescriptorTable + 8);
if ( (objType >> 3) & 1 )

    Was hat es mit dem shiften (und ANDen) auf sich, was wurde hier optimiert?
    Aus dem Kontext weiß ich dass es um eine 4bit-Integervariable geht.

    Wäre super wenn mir jemand helfen könnte 😉
    Grüße,
    Flo

    0
  • N

    test ist kein and, bzw. es veraendert den 1. Operanden nicht. Wird idR. benutzt, um zu testen, ob bestimmte bits gesetzt sind.
    Aus diesem kurzen Code-Schnippsel kann ich leider weder erkennen, wozu hier getestet wird, ob bit3 des darueber geladenen dwords gesetzt ist, noch, warum das auf diese ungelenke Weise geschieht. Dazu muesste man IMHO mindestens einen wesentlich groesseren Teil des Codes, sowie dessen Kontext (Einsatzgebiet, Anforderungen) betrachten.
    Fuer sich genommen optimiert dieser Code jedenfalls AFAIK weder in Groesse noch in Geschwindigkeit.

    0
  • I

    Na dann, hier mal die ganze Funktion:

    Pseudo-C Code mit Hilfe von Hexrays, zumindest das wo ich schon durchbin ist einigermassen lesbar 😉
    http://pastebin.com/m282b618a

    Und hier der Assembler-Code unverblümt:
    http://pastebin.com/f54e780a0

    Grüße,
    Flo

    0
  • H

    Es ist nicht unueblich eine Reihe von Flags an unterschiedlichen Bitpositionen eines Integers abzulegen.
    Dass das zu pruefende Bit zunaechst an die unterste Stelle verschoben wird ruehrt eventuell daher, dass im urspruenglichen Source syntaktisch ein boolescher Wert (0/1) existierte und die damit verbundene Typumwandlung den Compiler abgehalten hat "zu Ende" zu optimieren.

    0
Anmelden zum Antworten