Loop Unrolling Beispiel - Misteriöses lea-Statement

Nobuo T schrieb:

Reverser schrieb:

versteht ihr folgendes ASM Snippet einer teilweise aufgerollten Schleife?

Vom Prinzip her: Ja. Fuer weitere Einzelheiten reicht dieser Ausschnitt nicht.

Mehr stand dort nicht, das ist ein Auszug aus einem Buch (und zwar vollständig, also mehr steht dort auch nicht).

Nobuo T schrieb:

Reverser schrieb:

Also der Code ist sicher von einem Compiler, ein Mensch würde wohl kaum sinnlos ein pop ebx[...]

Ein Compiler (sofern er korrekte Programme erzeugt) auch nicht.

Ich meinte damit eher, dass ein Mensch in einem Beispiel das nicht sinnlos reinschreiben würde.

Nobuo T schrieb:

Reverser schrieb:

und das dritte Statement des Loop-Unrollings nach dem Erhöhen des Schleifenzählers platzieren.

Dann waere besagter Mensch kein guter Assembler-Programmierer.

Warum?

Nobuo T schrieb:

Reverser schrieb:

Aber was soll das lea Statement am Anfang, wo ecx doch direkt davor genullt wird?

Es bewirkt gar nichts (nop).

Reverser schrieb:

Ich vermute, dass es ein Tippfehler ist und eigentlich "xor eax,eax" sein soll, wie seht ihr das?

Wenn du das aus einem fertig compilierten Programm hast ist ein Tippfehler doch recht unwahrscheinlich.
Es koennte auch dazu dienen, den Code der Schleife zur schnelleren Ausfuehrung im RAM auszurichten (zB. an dword-Grenzen).

Ich habe es ja wie gesagt aus einem Buch und könnte mir schon vorstellen, dass der Autor das noch ein wenig angepasst hat, wie zum Beispiel das goto-Label.

Nobuo T

Reverser schrieb:

Nobuo T schrieb:

Reverser schrieb:

versteht ihr folgendes ASM Snippet einer teilweise aufgerollten Schleife?

Vom Prinzip her: Ja. Fuer weitere Einzelheiten reicht dieser Ausschnitt nicht.

Mehr stand dort nicht, das ist ein Auszug aus einem Buch (und zwar vollständig, also mehr steht dort auch nicht).

Kein weiterer Kommentar? Gar nichts?

Reverser schrieb:

Nobuo T schrieb:

Reverser schrieb:

Also der Code ist sicher von einem Compiler, ein Mensch würde wohl kaum sinnlos ein pop ebx[...]

Ein Compiler (sofern er korrekte Programme erzeugt) auch nicht.

Ich meinte damit eher, dass ein Mensch in einem Beispiel das nicht sinnlos reinschreiben würde.

Meinst du also, ein "Compiler" hat diesen Schnipsel ausgesucht und abgetippt, oder wie?
Wie du es auch drehst und wendest, dieses verwaiste "pop" sagt hoechstens aus, dass dieses Stueck Code ziemlich willkuerlich aus seinem Kontext gerissen wurde.

Reverser schrieb:

Nobuo T schrieb:

Reverser schrieb:

und das dritte Statement des Loop-Unrollings nach dem Erhöhen des Schleifenzählers platzieren.

Dann waere besagter Mensch kein guter Assembler-Programmierer.

Warum?

Ich bin mir nicht so sicher, wie das Pipelining bei aktuellen x86-CPU genau laeuft, und ob

xor ecx,ecx
pop ebx
lea ecx,[ecx]
LoopStart:
mov edx,dword ptr [esp+ecx*4+8]
add edx,dword ptr [esp+ecx*4+4]
add edx,dword ptr [esp+ecx*4+0Ch]
add ecx,3
add eax,edx
cmp ecx,3E7h
jl  LoopStart

nicht vielleicht doch effizienter waere, aber wenn du dir wirklich Gedanken um die Optimierung machst, solltest du solche Basteleien nicht von vornherein ausschliessen. Wer gar nicht erst auf solche Gedanken kommt, kann einfach kein guter Asm-Programmierer sein.

Reverser schrieb:

Nobuo T schrieb:

Reverser schrieb:

Ich vermute, dass es ein Tippfehler ist und eigentlich "xor eax,eax" sein soll, wie seht ihr das?

Wenn du das aus einem fertig compilierten Programm hast ist ein Tippfehler doch recht unwahrscheinlich.
Es koennte auch dazu dienen, den Code der Schleife zur schnelleren Ausfuehrung im RAM auszurichten (zB. an dword-Grenzen).

Ich habe es ja wie gesagt aus einem Buch und könnte mir schon vorstellen, dass der Autor das noch ein wenig angepasst hat, wie zum Beispiel das goto-Label.

Koennte sein. Genau so gut koennte aber auch meine Vermutung zutreffen. Das laesst sich allein mit diesem Schnipsel eben nicht mit Gewissheit sagen.

abc.w

@Reverser: Aus welchem Buch hast Du es denn? Wir sind alle scharf drauf zu erfahren, was wollte der Autor genau optimieren...
Wegen

...
mov edx,dword ptr [esp+ecx*4+8]
add edx,dword ptr [esp+ecx*4+4]
add ecx,3
add edx,dword ptr [esp+ecx*4-0Ch]
...

Damit wird ein Array durchlaufen: array[2], array[1], array[0], array[5], array[4], array[3]. Interessant ist das Muster 2, 1, 0 usw. Widerspricht ein wenig dem gesunden Menschenverstand... Die ganze Schleife scheint nur da zu sein, um die Array-Elemente aufzusummieren. Das Ergebnis steht dann in eax...

Der Snippet-Programmierer wollte vielleicht ein unseeliges

LoopStart:
(...)
cmp ecx,3E7h
jne LoopStart   :open_mouth:

vermeiden. Das Problem ist nur was die "3E7h" zu bedeuten hat. (Etwa Anzahl Array-Elemente ?)

asm.hack schrieb:

Der Snippet-Programmierer wollte vielleicht ein unseeliges
LoopStart:
(...)
cmp ecx,3E7h
jne LoopStart   :open_mouth:
vermeiden. Das Problem ist nur was die "3E7h" zu bedeuten hat. (Etwa Anzahl Array-Elemente ?)

Das ist in Dezimal die 999.

Ok, etwas mehr Kontext: das Buch heißt Reversing - Secres of Reverse Engineering und das Beispiel oben ist einfach nur ein Beispiel in dem Abschnitt Loop Unrolling, welches in dem Anhang über Compilergenerierten Assembler-Code steht, d.h. das Snippet stammt schon aus einem Programm (das wollte ich eben mit dem "sinnlosen" pop ebx sagen, da ein von Hand geschriebenes Beispiel wohl kaum sowas überflüssiges enthalten würde).
Nein, der Autor sagt an der Stelle nichts über das Programm, oder warum das Inkrementieren des Schleifenzählers vor dem letzten Array-Zugriff steht. Er erklärt hier nur das partial loop-unrolling (hört sich englisch einfach schöner an) und dass statt 999 Überprüfungen des Schleifenkopfes nur 333 notwendig sind.

abc.w

Reverser schrieb:

Ok, etwas mehr Kontext: das Buch heißt Reversing - Secres of Reverse Engineering...

Ach so. Langweilig.

Reverser schrieb:

...dass statt 999 Überprüfungen des Schleifenkopfes nur 333 notwendig sind.

Schmeiss dieses Buch weg und beschäftige Dich mit anderen Sachen, wie z.B. C-Programmierung, C++ Programmierung, Assembler-Programmierung usw.

abc.w schrieb:

Reverser schrieb:

...dass statt 999 Überprüfungen des Schleifenkopfes nur 333 notwendig sind.

Beschäftige dich mal mit Optimierungsmöglichkeiten- und verfahren von Compilern, dann verstehst du den Sinn dahinter schon.

abc.w

Reverser schrieb:

abc.w schrieb:

Reverser schrieb:

...dass statt 999 Überprüfungen des Schleifenkopfes nur 333 notwendig sind.

Beschäftige dich mal mit Optimierungsmöglichkeiten- und verfahren von Compilern, dann verstehst du den Sinn dahinter schon.

Ich meine was anderes. Es ist natürlich schon eine wichtige Information (statt 999, 333 Schleifendurchläufe), aber meiner Meinung nach verschweigt der Autor einige wichtigere Sachen diesbezüglich. Muss auch zugeben, kenne dieses Buch nicht und habe vermutlich voreilig Schlüsse wegen Wegschmeissen gezogen.
Zusätzlich ist auch noch mein Vorurteil bezüglich "Reversing" und "Reverse Engineering" dran schuld. Ich meine, wie soll ich sagen, es gibt ja z.B. Astrologie, weisse und schwarze Magie usw. und es gibt Leute, die sich echt mit dem Zeug beschäftigen, und das auch ohne echte Physik, Chemie, Astronomie, Medizin usw.
So ähnlich scheint es mir auch mit diesem "Reversing" abzulaufen. Hat sich jemand mal damit beschäftigt? Kann er jetzt sagen, z.B., jo, das war gut, besser als das Studium eines Compiler-Manuals, Disassemblers, CPU-Manuals, OS-Programmierung u.ä.?

Nobuo T

Ack (glaube ich).
Entweder du kennst dich schon mit den Grundlagen (Asm, Debugging und Eigenheiten von Compilern) halbwegs aus, dann brauchst du so ein Buch nicht, oder du hast im Grossen und Ganzen keine Ahnung, dann bergen solche Buecher IMHO ein grosses Risiko der Vermittlung gefaehrlichen Halbwissens.
Aehnlich wie duenne Buecher, die einem versprechen, in wenigen Tagen etwas Japanisch zu vermitteln.

Nobuo T schrieb:

Ack (glaube ich).
Entweder du kennst dich schon mit den Grundlagen (Asm, Debugging und Eigenheiten von Compilern) halbwegs aus, dann brauchst du so ein Buch nicht, oder du hast im Grossen und Ganzen keine Ahnung, dann bergen solche Buecher IMHO ein grosses Risiko der Vermittlung gefaehrlichen Halbwissens.
Aehnlich wie duenne Buecher, die einem versprechen, in wenigen Tagen etwas Japanisch zu vermitteln.

In dem Buch geht es doch nicht um diese Grundlagen. Meine Frage war zu einem Unterkapitel eines Anhangs bezogen, dass dieser eine eigenständige Lektüre zu diesem Thema nicht ersetzten kann ist ja wohl klar. Außerdem schlägt der Autor auch explizit zusätzliche (empfehlenswerte) Literatur vor. Zumindest über Betriebssysteme, Compilerbau, Compileroptimierung und Assembler.

Das Buch selbst behandelt vereinfacht gesagt einfach nur ein paar Reversing-Sessions an denen der Autor ein paar Techniken die man Anwenden kann vermitteln möchte. Nicht mehr und nicht weniger