EIntOverflow bei LongWord, nicht aber bei Word

[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.

[himitsu]

Nja, per se kann eine x86-CPU mit 16 und 8 Bit-Werten rechnen, aber wie bereits erkannt, castet Delphi oftmals schon vorher und die Überlaufprüfung spricht nicht an, wenn für die mathematischen Operationen dann die 32-Bit-Befehle verwendet werden.



Es gibt von Android noch 32 Bit OS, aber so wie es aussieht wird seit einiger Zeit von den meisten "größeren" Herstellerung scheinbar nur noch 64 Bit verwendet.
Der Vorteil eines OS mit nur noch einem Layer wäre ja eine kleinere Codebasis und dass Programme von der Bittigkeit dann überall laufen

Also 64 Bit-Apps welche in reinen 32 OS bekanntlich nicht laufen. Bzw. Es ist dann nicht nötig, dass dann unnötig viele Varianten eines Programms in einer APK liegen, wenn man überall die beste Performance haben will.

32 Bit ARM
64 Bit ARM
32 Bit Intel (x86)
64 Bit Intel (x86)

vv

64 Bit ARM
64 Bit Intel (x86)

In neueren Intel-Androids werden ja nun auch ARM-only-Apps (armeabi) ausgeführt.
Gut, das ist nicht sonderlich schnell, aber für kleine Apps, ohne große CPU-Auslastung, spart das nochmal Speicherplatz.



Uns interessiert es ja noch nicht, da Delphi aktuell eh nur 32 Bit für Android anbietet.
Und Intel von Delphi noch garnicht unterstützt wird. Da ist nur ein blöder ARM-Dummy drin, welcher eine Fehlermeldung anzeigt, mit dem Ergebnis, dass Delphi-Apps standardmäßig überall starten, aber selbst wenn das Android/Intel ARM emulieren kann, dort dennoch nichts läuft, weil der Emulator nicht anspringt, so lange der Dummy in der API rumgammelt. Und Dank des ARM-Dummy listet der PlayStore diese Apps für Intel-Geräte auf, obwohl sie dann doch nicht ausgeführt werden können.

[KodeZwerg]

@himitsu, ist das oft vorkommende "x68" ein Tippfehler für "x86" oder habe ich das falsch verstanden und kenne es einfach noch nicht?

[himitsu]

jupp

[Stevie]

Übrigens: LongWord ist nicht auf allen Plattformen 32bit - siehe http://docwiki.embarcadero.com/Libra...ystem.LongWord

Zitat von Der schöne Günther:

Das ist doch bestimmt seit 20 Jahren so. Den Bug behebt sicher keiner mehr.

Eine Warnung wäre bei so etwas vielleicht auch angebracht, aber wir wissen ja:

Zitat von MEissing:

Wenn Delphi (der Delphi-Compiler) alles testen würde, was eventuell schief gehen könnte, dann wären die Übersetzungszeiten länger.

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

[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 von Stevie:

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

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


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 von Der schöne Günther:

"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)