Kann mein PC nicht mehr Rechnen?

SeppJ

Dann bekommt man einen int mit dem Wert 5.

Die rechte Seite weiß in C++ nichts von der linken Seite und das ist auch gut so. Man stelle sich nur mal vor:

string foo = to_string(5 + 6)  // "56", weil Stringaddition?

Und das ist noch ein super-simpler Fall.

nachtfeuer schrieb:

Man würde ja erwarten, dass, wenn man eine Variable als "float" definiert,
tatsächlich auch gleich die FPU angeworfen wird zum Zwischenspeichern, Rechen und natürlich auch Ausgeben.

also wir haben gelernt, dass das eben nicht so ist, bzw. dass die fpu nur dann verwendet wird, wenn auch eine gleitkommazahl an der rechenoperation teilnimmt und das ist ja bei 19/5 nicht der fall.

dachschaden

nachtfeuer schrieb:

Man würde ja erwarten, dass, wenn man eine Variable als "float" definiert,
tatsächlich auch gleich die FPU angeworfen wird zum Zwischenspeichern, Rechen und natürlich auch Ausgeben.

Nein. Compiler kennen viele Tricks, und Integer-Operationen sind in der Regel weniger teuer als Gleitkommaberechnungen. Selbst, wenn diese Integer-Operationen auf den ersten Blick sehr komplex erscheinen.

Das wussten auch die Entwickler von Doom. Anstatt dass sie Gleitkommazahlen verwenden, haben sie mit Bitshifting eine Lösung gefunden, die nahe genug am Ergebnis war.

nachtfeuer schrieb:

Was passiert eigentlich, wenn man bei c++ int a = 5.5; schreibt?

Darauf hat dir SeppJ schon eine Antwort gegeben, aber ich habe da noch was in C nachgeprüft:

#include <stdio.h>

int main(void)
{
        printf("%f\n",5.5f);
        return 0;
}

Aus der Übergabe von 5.5f macht der Compiler:

movabs rax,0x4016000000000000

5.5f siehst du gar nicht mehr, nur noch 0x4016000000000000.

SeppJ

dachschaden schrieb:

5.5f siehst du gar nicht mehr, nur noch 0x4016000000000000.

Du meinst, der Compiler versteht Literale und printf? Ich verstehe nicht, was das mit dem Thema zu tun hat.

Erklärung für andere Leser: 0x4016000000000000 ist 5.5 (also double).

gleitkommazahlenformat mit exponent und mantisse?

edit: eben

dachschaden

SeppJ schrieb:

Du meinst, der Compiler versteht Literale und printf? Ich verstehe nicht, was das mit dem Thema zu tun hat.

Es war eine Ergänzung zu der Erwartung, dass der Compiler bei Gleitkommaoperationen direkt spezielle FPU-Instruktionen generiert. Tut er in dem TE-Beispiel nicht, weil mit Integeroperanden gearbeitet wird. Aber selbst wenn mit Gleitkommaoperanden gearbeitet wird, müssen keine FPU-Instruktionen generiert werden, wenn der Compiler erkennt, dass das Ergebnis auch mit simpleren Operationen berechnet werden kann.

HansKlaus schrieb:

gleitkommazahlenformat mit exponent und mantisse?

Nach IEEE754.

SeppJ

Hier wird ja gar nicht gerechnet, erst später von dem printf, dass man hier gar nicht sieht. Wundert mich sogar ein bisschen, dass das nicht zu puts("5.5") optimiert wurde.

nachtfeuer

printf würde sich vermutlich über 19/5 und %f (für Gleitkommaausgabe)(und keine weiteren Hilfen) beschweren.

In den 70er Jahren waren Fließkommaprozessoren noch nicht so verbreitet. Beim Intel konnte man einen als Zusatz kaufen oder eine (langsame) Softwaresimulation nutzen.

Intel (und Kompatible) haben mittlerweile sehr viele Hardware-Datentypen parat. Ein wenig Automagie wäre nicht so verkehrt? Wo anfangen?

Man könnte noch fragen: Was hat der Compiler (oder die Programmiersprache)(wenn schon Int) mit dem Rest von 19/5 gemacht?

(Hardwaresimulation in Haskell:
(ghci)

Prelude> let divmod a b = (div a b, mod a b)
Prelude> divmod 19 5
(3,4)

ich würde eher sagen, dass da ein cast durchgeführt wird.

SeppJ

HansKlaus schrieb:

ich würde eher sagen, dass da ein cast durchgeführt wird.

Da wird gar nichts durchgeführt.