Achtung. Optimierung beim Compiler

[JasonDX]

Zitat von s.h.a.r.k:

Soweit ich das noch weiß, optimiert der Compiler das dahingehend, da die CPU scheinbar leichter und schneller um 1 dekrementieren als inkrementieren kann.

Nein, der Compiler optimiert die Schleife so, dass sie nicht von n..m, sondern von (n-m-1)..0 läuft. Da bei Operationen wie Inc- und Dekrementieren bereits das Zero-Flag gesetzt wird, wenn der Wert 0 wird, erspart man sich einen Vergleich pro Schleifendurchlauf.

Zitat von s.h.a.r.k:

Aber einen Unterscheid sollte in deinem Programm nicht auftreten. Beim Debuggen findet du lediglich die "falschen" Werte, intern wird aber alles richtig ausgeführt.

Ja, der Zugriff auf InUse[i] erfolgt in der richtigen Reihenfolge. Der Compiler speichert sich den Zeiger auf InUse[0], und inkrementiert diesen bei jedem Schleifendurchlauf, während der Index dekrementiert wird. Läuft insgesamt schneller, und das Array wird in der korrekten Reihenfolge abgearbeitet.

greetz
Mike

[hoika]

Hallo,

was mich eh interessiert.
Wieso hast du beim Debuggen die Optimierung angeschaltet ?


Heiko

[Luckie]

Wahrscheinlich, weil sie bei den Projektoptionen standardmäßig an ist.

[himitsu]

Über einige standardmäßige Sachen hatte ich mich ja schonmal beschwert.
- wenn standardmäßig auch noch Bereichsprüfungen, Überlaufprüfungen und Dergleichen aktiviert wären, dann gäbe es diesbezüglich wohl auch weniger Probleme bezüglich 0- und 1-Index, sowie Length()-1 usw.


Fakt ist einfach, daß man dem Debugger vergessen hat mitzuteilen, daß z.B. die Reihenfolge umzudrehen ist, bzw. daß der interne Wert anders interpretiert werden muß.

Bei Verwendung dieses Index wird er aber "richtig" angewand.
Sei es durch:

Delphi-Quellcode:

// dieses
for i := 0 to 10 do
  x := a[i];

// als
i := 10;
repeat
  x := a[10-i];
  Dec(i);
until {i = 0} ZeroFlag;

// oder 

i := 10;
p := @a[0]
repeat
  x := p^;
  Inc(p);
  Dec(i);
until {i = 0} ZeroFlag;

// oder (es gibt noch unzählige Möglichkeiten