ASM - Compiler erstellt überflüssigen Code?

[dizzy]

Spät-Mahlzeit!

Es ist zwar nur eine klitze Kleinigkeit, aber ich habe mich gerade beim Durchsteppen im CPU-Fenster etwas gewundert. Die im Bild (im Anhang) rot umrandete Zeile dürfte ja eigentlich nie erreicht werden, da direkt zuvor ein ret steht (der auch zum sofortigen Sprung führt, klar). Die Zeile wird tatsächlich nie erreicht - die Unit ist recht klein, und ein komplettes Durchsteppen landete nicht ein mal dort.
Warum aber existiert diese Zeile dann? Sie gehört auch nicht zur Folgeprozedur. Sie wird folglich nicht benötigt, und belegt nur Plattenplatz + RAM.
Das ist für eine einzige Anweisung zwar Lachhaft, ich weiss, aber ich frage mich wie viel es wohl in größeren Projekten ausmachen könnte. Ist da etwa noch offensichtliches Optimierungspotential im Compiler? Oder ist das ganz besonders schlau von Delphi, weil damit evtl. günstigeres Alignment erreicht wird? Kein Plan. Aber Interesse dran!

Ich weiss dass das ziemlich kleinlich klingt, aber irgendwie stört es mich grad :D.

[retnyg]

es handelt sich wahrscheinlich um eine variable, die der compiler an den prozedur code anhängt.
dass da LEA EAX... steht ist reiner zufall da der wert halt dieser anweisung entspricht

btw.. seit wann hast du das matrix-zeuch in deinem logo ?

[jbg]

Zitat:

Zitat von dizzy

weil damit evtl. günstigeres Alignment erreicht wird?

Warum fragst du, wenn du es dir selbst doch erklären kannst.

[jbg]

Zitat:

Zitat von retnyg

es handelt sich wahrscheinlich um eine variable

Mit 3 Bytes? Die nächste Funktion beginnt bei einer durch 8 bzw. 4 teilbaren Adresse.

[retnyg]

Zitat:

Zitat von jbg

Zitat:

Zitat von retnyg

es handelt sich wahrscheinlich um eine variable

Mit 3 Bytes? Die nächste Funktion beginnt bei einer durch 8 bzw. 4 teilbaren Adresse.

vielleicht verwendet er in seinem source 3 variablen vom typ byte ?
edit: oder ein Word und das 00 noch angehängt um auf die schöne durch 4 teilbare addy zu kommen...

[Dax]

Das ist schon eine nahezu perfekte Optimierung. Die umrahmten Bytes sind einfach da, das ist Absicht. Die nächste Anweisung ist so an einer DWORD-Adresse, was Sprünge oder Calls einen Speedvorteil bringen kann. Mach mal einen Test: Nimm dir die Funktion

Delphi-Quellcode:

procedure Test;
asm
  nop
  inc eax
  ret
end;

Und teste sie durch, indem du einmal CALL Test aufrufst und im anderen Fall eben so:

Delphi-Quellcode:

asm
  lea edx, Test
  inc edx
end;
// Weiterer Testcode
asm
  call edx
end;

Beides führt den selben Code aus, aber nur CALL Test wird direkt eine DWORD-Adresse aufrufen. Dürfte also schneller sein ;-)

PS: Ich hab's nicht getestet. Noch nicht ;-)

@retnyg: Wenn es Variablen wären (die drei umrahmten Bytes), müsste das Programm schreibrechte auf die Daten um EIP haben. Ist aber nicht der Fall, also können es keine Variablen sein.

[dizzy]

@jbg: Das war nur eine völlig geratene Vermutung. Ob das überhaupt von Belang wäre weiss ich ja nichtmal :)

@retnyg: Hmmm, das könnte an sich sein. Jedoch würde ich eher Konstanten in dieser Form erwarten, und solche kommen in beiden Prozeduren nicht vor (zumindest keine die diesem Wert entsprächen). Zudem sind es alles lokale Variablen (die ja auf dem Stack rumlungern dürften :)), womit ein Pointer auf einen Wert auch nicht allzu plausibel erscheint. Aber an sich klingt das nach einer wahrscheinlichen Sache...

Die beiden zugerörigen Prozeduren mal in DL:

Delphi-Quellcode:

function FillZero(const s: String; const count: Integer): String;
var
  oldL: Integer;
  i   : Integer;
begin
  oldL := Length(s);
  SetLength(result, count);
  for i := 1 to count-oldL do
    result[i] := '0';
  for i := count-oldL+1 to count do
    result[i] := s[i-count+oldL];
end;

// <-----------

procedure TfrmVorlage.FillVerfuegbar;
var
  s: array[0..7] of String;
begin
  lbVerfuegbar.Items.Clear;
  QryVerfuegbar.First;
  while not QryVerfuegbar.Eof do
  begin
    s[0] := QryVerfuegbar.FieldValues['N00'];
    s[1] := QryVerfuegbar.FieldValues['N01'];
    s[2] := QryVerfuegbar.FieldValues['N02'];
    s[3] := QryVerfuegbar.FieldValues['N03'];
    s[4] := QryVerfuegbar.FieldValues['EArt'];
    s[5] := QryVerfuegbar.FieldValues['Def'];
    s[6] := QryVerfuegbar.FieldValues['N04'];
    s[7] := QryVerfuegbar.FieldValues['Text'];

    lbVerfuegbar.Items.Add(FillZero(s[0], 2) + '-' +
                           FillZero(s[1], 2) + '-' +
                           FillZero(s[2], 2) + '-' +
                           FillZero(s[3], 2) + '-' +
                           s[4] + '-' +
                           s[5] +
                           FillZero(s[6], 4) + ' ' +
                           s[7]);
    QryVerfuegbar.Next;
  end;
end;

Die betreffende ASM-Zeile steht quasi zwischen diesen beiden Prozeduren, beim Pfeil.

\\EDIT: @Dax :love: : Also tatsächlich wirklich Alignment... ist ja nen Dingen! Hat das wirklich merkbaren Einfluss auf die Geschwindigkeit? Ich hatte hier mal irgendwo soetwas gelesen, allerdings in Bezug auf Datenalignment und den Zugriff darauf. (Wobei ein Call ja eigentlich nix anderes ist. Sitmmt schon... :gruebel:)

[retnyg]

Zitat:

Zitat von Dax

@retnyg: Wenn es Variablen wären (die drei umrahmten Bytes), müsste das Programm schreibrechte auf die Daten um EIP haben. Ist aber nicht der Fall, also können es keine Variablen sein.

schreibrechte im EIP ? wie werden diese erteilt ? habe davon noch nie was gehört...wäre nett wenn du dazu mal etwas mehr sagen könntest ;)

[Dax]

Ich bastele schon ein paar Wochen an einer Möglichkeit, Schreibrechte auf's Codesegment zu bekommen, bis jetzt hatte ich keinen Erfolg ;-)

[jbg]

Zitat:

Zitat von retnyg

vielleicht verwendet er in seinem source 3 variablen vom typ byte ?

Vielleicht, aber Variablen liegen nicht im CodeSegment (Readable, not Writable, Executable), sondern im Datensegment (Readable, Writeable, not Executable). Denn was bringt einem eine nicht beschreibbare Variable? Das kann höchstens eine Konstante sein, und die liegt gewiss nicht an dieser Stelle, sondern vereint bei allen anderen Konstanten.

[jbg]

Zitat:

Zitat von Dax

Ich bastele schon ein paar Wochen an einer Möglichkeit, Schreibrechte auf's Codesegment zu bekommen, bis jetzt hatte ich keinen Erfolg ;-)

Das ist doch das die leichteste Übung: VirtualProtect + WriteProcessMemory.

[Dax]

Die Kombination hab' ich noch nicht ausprobiert, weil VirtualProtect bei mir aus irgendeinem Grund immer fehlschlug.. Hab' wohl falsche Parameter übergeben :gruebel:

// Edit

@dizzy: Ein CALL ist ein pushen des nächsten EIPs auf den Stack und ein JMP in die angegeben Adresse. Probier mal mit meiner Funktion von oben rum, da dürfte ein Vorteil bemerkbar sein.

[retnyg]

Zitat:

Zitat von jbg

Zitat:

Zitat von retnyg

vielleicht verwendet er in seinem source 3 variablen vom typ byte ?

Vielleicht, aber Variablen liegen nicht im CodeSegment (Readable, not Writable, Executable), sondern im Datensegment (Readable, Writeable, not Executable). Denn was bringt einem eine nicht beschreibbare Variable? Das kann höchstens eine Konstante sein, und die liegt gewiss nicht an dieser Stelle, sondern vereint bei allen anderen Konstanten.

hmm ich habe aber schon festgestellt dass delphi an den code einer prozedur pointer auf die variablen, welche in dieser vorkommen, anhängt

[Dax]

Das könnte ein Hint für den Debugger sein, damit er die Variablen für die Watches und den Evaluater/Modifier findet. Wenns das nicht ist, sind diese Bytes nur für Alignment zu gebrauchen.

[jbg]

Zitat:

Zitat von retnyg

hmm ich habe aber schon festgestellt dass delphi an den code einer prozedur pointer auf die variablen, welche in dieser vorkommen, anhängt

Wäre mir neu. Beispiel? (=Beweis)

[jbg]

Zitat:

Zitat von dizzy

Also tatsächlich wirklich Alignment... ist ja nen Dingen! Hat das wirklich merkbaren Einfluss auf die Geschwindigkeit?

Ja, denn es macht einen rießen Unterschied, ob man zwei Speicherzugriffe braucht, um den nächsten Befehl zu laden, oder nur einen. Wenn die nächste Anweisung auf Adresse $0001 liegt, denn muss zuerst das DWORD von $0000-$0003 gelesen werden und dann $0004-0007. Daraus muss dann noch von $0001-$0004 das DWORD ermittelt werden. Und das geschieht auch, wenn man nur einen 1 Byte Befehl hat, da der L1/2-Cache eben auf DWORD oder sogar auf QWORD ausgelegt ist.

[EDIT]
Ich hoffe ich erzähle hier jetzt keinen Stuss. Das ist jetzt auch schon eine Weile her, das ich das gelernt und ausprobiert habe.

[retnyg]

beweis: der wert den MOV an dieser Stelle in EDX schreibt ist die markierte position, welche dem string 'test' hardcoded entspricht.

[dizzy]

Also ließe sich (imho) folgernd feststellen:

Delphi ist so genial, dass es Code so ausrichtet, dass er möglichst performant ausgeführt wird. Die dafür nötigen Paddings nutzt er zudem für potentielle Debug-Infos, was die Sache ganz schön schlau erscheinen lässt :).

Kommt das hin?

[NicoDE]

Zitat:

Zitat von dizzy

[...] Die dafür nötigen Paddings nutzt er zudem für potentielle Debug-Infos, was die Sache ganz schön schlau erscheinen lässt :).

Das möchte ich bezweifeln (ohne Compiler-Quelltext habe ich keine Beweise) - ich vermute es handelt um Datenschrott aus dem Compile-Prozess. ('anderere' Compiler schreiben dort teilweise Breakpoints (int3), 0x00 oder 0x90 (nop) hin)