Seltsames Phänomen: Unterschied zwischen Integer und Int64

[hschmid67]

@himitsu: Ja, hier kommt tatsächlich 111 raus.

@ghubi01: Hab ich noch nicht probiert, aber das wird wohl funktionieren. [EDIT]Ja, es funktioniert.[/EDIT] Die Frage ist nur: Warum funktioniert es unter 32Bit nicht?

Und vor allem: Warum funktioniert es mit "Integer"?

Vielen Dank Euch für's Mitdenken!

[Uwe Raabe]

Vor geraumer Zeit hatten wir schon mal so was in der Art: In Delphi, are parameters evaluated in order when passed into a method?

[hschmid67]

Hallo Herr Raabe,

vielen Dank für den Hinweis. Dann wäre ja mein korrektes Ergebnis mit "Integer" nur Zufall? Puh, nicht schön! Meine Idee war - und hier wäre das sinnvolle Beispiel dazu - ein Dataset-Objekt so zu konstruieren, dass folgendes Konstrukt möglich wäre:

Delphi-Quellcode:

CreateSpecialDataset('SELECT nr, titel FROM table')
  .RecordCount(lCount)
  .Append
  .SetInteger('nr', lCount + 1)
  .Post;

Viele Grüße

[Uwe Raabe]

Obwohl ich persönlich kein Freund des Fluent-Interfaces bin, würde ich schon meinen, dass der Code so korrekt ist. Schaut man sich aber den erzeugten Assembler-Code an, wird schnell klar warum das nicht so ist. Da werden erst alle Parameter auf den Stack gelegt und dann die einzelnen Aufrufe ausgeführt. Weil der Rückgabewert ja eh schon auf dem Stack liegt, ist das eigentlich gar nicht so dumm gelöst. Faktisch wird die Fluent-Aufruf-Kette aber dann so behandelt wie ein einzelner Aufruf mit zwei Parametern - wie in dem Link beschrieben mit den entsprechenden Nebeneffekten.

Code:

Project765.dpr.44: lTest.SetTo2(lCount).SetI(lCount + 1).WriteInt;
0041D30F 8B45F8           mov eax,[ebp-$08]
0041D312 8B55FC           mov edx,[ebp-$04]
0041D315 83C001           add eax,$01
0041D318 83D200           adc edx,$00
0041D31B 52               push edx
0041D31C 50               push eax
0041D31D 8D55F8           lea edx,[ebp-$08]
0041D320 8B45F4           mov eax,[ebp-$0c]
0041D323 E800FFFFFF       call TTest.SetTo2
0041D328 E827FFFFFF       call TTest.SetI
0041D32D E84AFFFFFF       call TTest.WriteInt
0041D332 33C0             xor eax,eax
0041D334 5A               pop edx
0041D335 59               pop ecx
0041D336 59               pop ecx
0041D337 648910           mov fs:[eax],edx
0041D33A 684FD34100       push $0041d34f
Project765.dpr.46: lTest.Free;

[himitsu]

Zitat von hschmid67:

Die Frage ist nur: Warum funktioniert es unter 32Bit nicht?

Es ist ein komplett anderer Compiler.
Im Win32 wird Int64 auch noch "emuliert", denn die CPU hat ja nur 32 Bit, also das +1 berechnet nicht die CPU mit "einem" Assemblerbefehl, sondern es erledigt Delphi, über zwei Int32. Teilweise über monströse Funktionen in der System.pas.

Delphi-Quellcode:

// Win32
Unit1.pas.29: X := X + 1;
0060E3A9 8B45F0           mov eax,[ebp-$10]
0060E3AC 8B55F4           mov edx,[ebp-$0c]
0060E3AF 83C001           add eax,$01
0060E3B2 83D200           adc edx,$00
0060E3B5 8945F0           mov [ebp-$10],eax
0060E3B8 8955F4           mov [ebp-$0c],edx

// Win64
Unit1.pas.29: X := X + 1;
000000000070ADA8 4883450801       add qword ptr [rbp+$08],$01

Delphi-Quellcode:

{ 64-bit Integer helper routines }
{$IF defined(CPU386) and defined(ASSEMBLER)}
procedure __llmul;
procedure __lldiv;
procedure __lludiv;
procedure __llmod;
procedure __llmulo;
procedure __llumulo;
procedure __lldivo;
procedure __llmodo;
procedure __llumod;
procedure __llshl;
procedure __llushr;
{$ENDIF}

In Win32 sieht der Aufruf also quasi so aus
lTest.SetTo2(lCount).SetI(__lladd(lCount, 1)).WriteInt; // __lladd ist aber eine Inline-Funktion vom Compiler
und hier wird das __lladd wohl zu früh ausgeführt, vor SetTo2.