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.