EIntOverflow bei LongWord, nicht aber bei Word

[himitsu]

Das wird eh immer langser, von Version zu Version ... das bissl fällt dann auch nicht mehr auf, wenn es noch rein käme.


Es hab auch mehrere Versionen lang einen Bug, wo UInt64/LargeWord vei einigen Berechnungen als Int64 behandelt wurde.
Bissl was wird doch irgendwann repariert.


In 32 Bit ist Int64 und UInt64 emuliert und wird "langsam" über zwei Integer/Cardinal manuell berechnet.
Darum sträubt sich Delphi auch, Integer dahin automatisch etwas zu erweitern.

[Der schöne Günther]

Zitat:

Zitat von Stevie (Beitrag 1403308)

Genau, wir alle wollen ja schließlich schnelle Buildzeiten, die dann potenziell fehlerhaften und langsame(re)n Code erzeugen... :roll:

Richtig, denn ich steche Mitbewerber mit der geringeren Time-to-Market aus 8-)


Ernsthaft: Was lernen wir nun aus der Geschichte?

Muss ich es jetzt für alle Datentypen die es grade gibt durchprobieren und mir dann einen Zettel an den Monitor kleben "Vorsicht, bei Rechnen mit folgenden Typen..."


Es ist doch sicher irgendwo dokumentiert "Word mit Word verrechnen ergibt DWord", "DWord mit DWord verrechnen ergibt DWord", ...

[KodeZwerg]

Zitat:

Zitat von Der schöne Günther (Beitrag 1403312)

"DWord mit DWord verrechnen ergibt DWord", ...

Nicht ganz, DWORD mit DWORD kommt ein QWORD / DINT raus. (-9223372036854775808 bis 9223372036854775807)
Manche nennen es auch QUADWORD.

Bestimmt wird es in naher Zukunft auf OWORD/OCTOWORD o.ä. erweitert (128bit)

[Der schöne Günther]

Wenn dem so wäre gäbe es dieses Thema nicht denn dann hätte ich keinen Overflow gehabt.

[himitsu]

dword + word -> dword
Eventuell ist es auch manchmal bissl intelligenter und als Ergebnis wird dann das Größere der Beiden genommen.

Schlimm wird es, wenn man Int64 mit UInt64 verrechnen will, denn da gibt es aktuell nichts Größeres, in der CPU. (Fließkomme in FPU ausgenommen)



Mit MMX oder Dergleichen gibt es auch jetzt schon nativ 128 Bit.
[EDIT] Nee, MMX war 8*8, 4*16, 2*32 oder 1*64 Bit ... aber SIMD (SSE) kann 128 und teilweise sogar 256 Bit (AVX)

[Stevie]

Zitat:

Zitat von himitsu (Beitrag 1403326)

Schlimm wird es, wenn man Int64 mit UInt64 verrechnen will, denn da gibt es aktuell nichts Größeres, in der CPU.

Dafür gibts seit 10.2 zum Glück W1073

[Zacherl]

Ich glaube Günther geht es darum, dass seine

Delphi-Quellcode:

Word + Word

Expression nicht vor der Addition erweitert wurde (da ja schon erkennbar ist, dass der temporäre Wert direkt einem

Delphi-Quellcode:

Double

zugewiesen werden soll). Unter C printed folgender Code:

Code:

Word a = 1000;
Word b = 10000;
printf("%f", (double)(a - b))

übrigens "-9000.000000".

[Stevie]

Zitat:

Zitat von Zacherl (Beitrag 1403336)

Ich glaube Günther geht es darum, dass seine

Delphi-Quellcode:

Word + Word

Expression nicht vor der Addition erweitert wurde

Nope, es geht darum, dass je nach Größe des Ordinaltypes trotz

Delphi-Quellcode:

{$OVERFLOWCHECKS ON}

on keiner kommt.

Zitat:

Zitat von Zacherl (Beitrag 1403336)

Unter C printed folgender Code:

Code:

Word a = 1000;
Word b = 10000;
printf("%f", (double)(a - b))

übrigens "-9000.000000".

C schert sich auch nicht um Overflows.

[Zacherl]

Zitat:

Zitat von Stevie (Beitrag 1403343)

Zitat:

Zitat von Zacherl (Beitrag 1403336)

Ich glaube Günther geht es darum, dass seine

Delphi-Quellcode:

Word + Word

Expression nicht vor der Addition erweitert wurde

Nope, es geht darum, dass je nach Größe des Ordinaltypes trotz

Delphi-Quellcode:

{$OVERFLOWCHECKS ON}

on keiner kommt.

Sorry, das "nicht" war mir reingerutscht. Genau, das ist klar. Ohne eine Erweiterung auf 32-Bit würde es aber ja funktionieren. Oder halt wie oben irgendwo angemerkt über das Carry-Flag statt des Overflow-Flags.

Zitat:

Zitat von Stevie (Beitrag 1403343)

Zitat:

Zitat von Zacherl (Beitrag 1403336)

Unter C printed folgender Code:

Code:

Word a = 1000;
Word b = 10000;
printf("%f", (double)(a - b))

übrigens "-9000.000000".

C schert sich auch nicht um Overflows.

Macht Delphi im Grunde ja auch nicht. Der C-Code schiebt die Werte auch erst in ein 32-Bit Register, verrechnet sie und verwendet dann SSE/AVX für die Konvertierung nach Double. Caste ich statt nach Double in Word, wird einfach Truncated, was dann einem Überlauf gleichkommt. Wollte hiermit nur andeuten, dass die eigentliche Berechnung in Delphi schon soweit konform zu sein scheint. Lediglich der eigentliche Overflow-Check ist halt an der Stelle verbuggt.

[Der schöne Günther]

Eine ganz peinliche Frage, ich mache ja noch nicht lange Delphi :oops:

Ich sehe in Delphi keine Äquivalent zu C's

Delphi-Quellcode:

(double)(a - b)

außer vielleicht

Delphi-Quellcode:

a*1.0 - b

. Gibt es etwas besseres außer vielleicht einer zusätzlichen Variable der man dann

Delphi-Quellcode:

a

zuweist?