EIntOverflow bei LongWord, nicht aber bei Word

[Der schöne Günther]

Zitat von freimatz:

Kam keine Warnung?

Nö.

Zitat von himitsu:

Größer als SizeOf(Pointer) werden aber keine automatischen Castes vorgenommen.

Aber es ist doch SizeOf(Pointer) = SizeOf(LongWord) ?


PS: Verhalten bei Win32 und Win64 identisch.

[himitsu]

Ja, aber er würde danach größer sein.
Ich weiß jetzt nicht wie es im 64 Bit ist,
aber in 32 Bit wird maximal bis auf Größe der CPU-Register vergrößert.

[Der schöne Günther]

Verstehe ich nicht.

Das -9000 nicht im Bereich eines LongWord (0..4 Mrd.) liegt ist mir klar, aber was wird denn hier vergrößert? Bei Word (0..65535) scheint er ja keine Probleme zu haben. Weshalb sollte er hier überhaupt auf einen signed Typen vergrößern?


Und wo wäre so etwas überhaupt dokumentiert?

Und wie komme ich jetzt überhaupt aus der Sache raus? Statt acceptDouble(x-y) ein acceptDouble( (x*1.0) - (y*1.0)) wird ja wohl kaum die richtige Lösung sein...

[himitsu]

Bei dem Word wird der Compiler das einfach schon vorher casten, weil er 32 Bit halt am Liebsten hat.

Delphi-Quellcode:

   acceptDouble(Double(Integer(a) - Integer(b)));

   acceptDouble(Double(x - y));

[Stevie]

Weil overflow checking nicht richtig bei Datentypen funktioniert, die kleiner als 32bit sind, da die Rechenoperationen auf den 32bit Registern ausgeführt werden.

Versuch doch mal das:

Delphi-Quellcode:

a := High(Word);
a := a + 1;

Disassembly für die 2. Zeile:

Delphi-Quellcode:

0041A834 0FB745FE         movzx eax,[ebp-$02]
0041A838 83C001           add eax,$01
0041A83B 7105             jno $0041a842
0041A83D E836ACFEFF       call @IntOver
0041A842 668945FE         mov [ebp-$02],ax

jno ist "Jump if not overflow" - und hier gabs nunmal keinen Overflow, denn eax ist 32bit breit. Wenn er in Variable zurückschreibt, spricht er es allerdings nur als 16-bit an (ax).

Schreibst du allerdings statt a := a + 1; Inc(a); , dann gibts nen overflow.
Denn das wird zu

Delphi-Quellcode:

0041A85C 668345FE01       add word ptr [ebp-$02],$01
0041A861 7305             jnb $0041a868
0041A863 E810ACFEFF       call @IntOver

[Der schöne Günther]

Ich kann mit Assembler nichts anfangen, glaube das jetzt aber (Weißkittel-Syndrom).

Ist das irgendwo dokumentiert? Wie verhält sich das auf Win64? Wie verhält sich das, sollte ich (Gott bewahre!) etwas auf iOS oder Android kompilieren wollen? Ist das immer noch alles 32 Bit?

[Stevie]

Zitat von Der schöne Günther:

Ich kann mit Assembler nichts anfangen, glaube das jetzt aber (Weißkittel-Syndrom).

Ist das irgendwo dokumentiert? Wie verhält sich das auf Win64? Wie verhält sich das, sollte ich (Gott bewahre!) etwas auf iOS oder Android kompilieren wollen? Ist das immer noch alles 32 Bit?

Es verhält sich irgendwie, bis es jemand als Bug reported und dann ist dieses Verhalten as designed

Aber mal ehrlich - keine Ahnung.

[gammatester]

Für 16-Bit wird der 'falsche' Opcode benutzt (eigentlich der richtige aber wg. der 32-Bit Arithmetik wird in beiden Fällen das Overflow-Bit nicht gesetzt, also netto falscher Code)

Code:

Unit2.pas.38: a := 1000;
005CE68A 66C745FEE803     mov word ptr [ebp-$02],$03e8
Unit2.pas.39: b := 10000;
005CE690 66C745FC1027     mov word ptr [ebp-$04],$2710
Unit2.pas.40: acceptDouble(a-b);
005CE696 0FB745FE         movzx eax,[ebp-$02]
005CE69A 0FB755FC         movzx edx,[ebp-$04]
005CE69E 2BC2             sub eax,edx
005CE6A0 7105             jno $005ce6a7
005CE6A2 E80595E3FF       call @IntOver

Da OF nicht gesetzt ist, gibt's keinen Int-Overflow. Bei 32-Bitwird nicht OF getestet sondern CF, und das ist in beiden Fällen gesetzt.

Code:

Unit2.pas.44: acceptDouble(x-y); // << EIntOverflow
005CE6CA 8B45F8           mov eax,[ebp-$08]
005CE6CD 2B45F4           sub eax,[ebp-$0c]
005CE6D0 7305             jnb $005ce6d7
005CE6D2 E8D594E3FF        call @IntOver

[Zacherl]

Zitat von Der schöne Günther:

Wie verhält sich das auf Win64?

Ohne es jetzt verifiziert zu haben, wird dort vermutlich weiterhin mit den 32-Bit Registern gerechnet, solange man keine größeren Datentypen verwendet. X86-64 kann in den meisten Fällen ja beides bzw. benötigt sogar explizit ein 64-Bit promotion prefix (REX.W), um die Instructions von der standardmäßig 32-Bit Breite auf 64-Bit umzustellen.

Zitat von Der schöne Günther:

Wie verhält sich das, sollte ich (Gott bewahre!) etwas auf iOS oder Android kompilieren wollen? Ist das immer noch alles 32 Bit?

iOS ist definitiv tatsächlich immer 64-Bit seit einiger Zeit. Bei Android kann ich es dir nicht sagen .. wird vermutlich nicht einheitlich sein.

[Der schöne Günther]

Und sich wahrscheinlich alle paar Versionen ändern. Ab sofort traue ich keiner Addition und Subtraktion mehr und nehme für alles die größten Datentypen die ich finden kann.

Nicht wirklich, aber so in etwa.