Long int vs. int

junky94 · 19. Mai 2011, 18:58

Hallo ich hab da eine kleine Frage.

short int = 2 bytes
unsigned int = 4 bytes
int = 4 bytes
long int = 4 bytes
long long int = 8 bytes

Wieso braucht long int gleich viel Speicher wit int?

zerm · 19. Mai 2011, 19:16

Der Standard schreibt vor, dass ein int mindestes 16bit gross ist, und ein long mindestens 32bit. Da nur das Minimum vorgeschrieben ist, steht es jeder Implementierung frei, eine andere Größe zu wählen, was halt dazu geführt hat, dass in der Regel int genauso wie long 32bit gross sind. Entsprechend gibt es (auf "normalen" Desktop-Architekturen, heutzutage) keinen Unterschied zwischen long und int, Aber: es kann etwa auch sein, dass ein int 64 bit gross ist (oder, wie häufig im Embedded-Bereich, dann nur die minimalen 16 bit) - entsprechend darf man sich nicht blind darauf verlassen.
Wenn man sich auf korrekte Breiten verlassen will, gibt es stdint.h (bzw. cstdint in C++ tr1), wo dann int8_t bis int64_t als Typen definiert sind, und somit unabhängig von der Breite eines int oder long.

Thallius · 19. Mai 2011, 19:22

Man kann eigentlich sagen, das ein int in den meisten Fällen der Prozessorarchitektur angepasst wird. Ein 16 Bit Prozessor hat halt ein 16bit int und ein 64bit prozessor ein 64bit int. Das optimiert dann die Verarbeitungsgeschwindigkeit, weil der Prozessor natürlich mit seiner nativen Größe am schnellsten rechnen kann.

Wie Zerm aber bereits sagte. Das ist nichts worauf man sich verlassen kann und schon gar nichts worauf man sich verlassen sollte, da man oben gesagtes bei den modernen Prozessoren so einfach auch wieder nicht ableiten kann.

Gruß

Claus

gritsch · 19. Mai 2011, 19:34

Thallius schrieb:

Man kann eigentlich sagen, das ein int in den meisten Fällen der Prozessorarchitektur angepasst wird. Ein 16 Bit Prozessor hat halt ein 16bit int und ein 64bit prozessor ein 64bit int. Das optimiert dann die Verarbeitungsgeschwindigkeit, weil der Prozessor natürlich mit seiner nativen Größe am schnellsten rechnen kann.

Wie Zerm aber bereits sagte. Das ist nichts worauf man sich verlassen kann und schon gar nichts worauf man sich verlassen sollte, da man oben gesagtes bei den modernen Prozessoren so einfach auch wieder nicht ableiten kann.

Gruß

Claus

kann man nicht sagen - auf dem besten beispiel dagegen arbeiten wir

Amin Negm-Awad · 19. Mai 2011, 19:46

Na, ja, das kann man schon sagen, weil int die "native", "übliche" Wortgröße des Prozessors darstellen soll. Bei 64-Bit-Modellen fragt sich nur, was das ist. Insofern hat sich vielleicht Thallius ungenau ausgedrückt. Das hat auch einen Hintergrund, weil shorts in diese "natürliche" Wortgröße umgewandelt werden. (Was zu überraschenden Effekten führen kann.)

@OP
Am besten du merkst dir ILP32 ("32 Bit"), was dann "Integer, Long, Pointer haben 32 Bit" heißt oder LP64 ("64 Bit"). Das ist deutlich klarer als die üblichen Bezeichnungen und er Zustand auf einem Mac.

gritsch · 19. Mai 2011, 19:52

Amin Negm-Awad schrieb:

Na, ja, das kann man schon sagen, weil int die "native", "übliche" Wortgröße des Prozessors darstellen soll. Bei 64-Bit-Modellen fragt sich nur, was das ist. Insofern hat sich vielleicht Thallius ungenau ausgedrückt. Das hat auch einen Hintergrund, weil shorts in diese "natürliche" Wortgröße umgewandelt werden. (Was zu überraschenden Effekten führen kann.)

@OP
Am besten du merkst dir ILP32 ("32 Bit"), was dann "Integer, Long, Pointer haben 32 Bit" heißt oder LP64 ("64 Bit"). Das ist deutlich klarer als die üblichen Bezeichnungen und er Zustand auf einem Mac.

äm, du weist schon was er geschrieben hat?

Ein 16 Bit Prozessor hat halt ein 16bit int und ein 64bit prozessor ein 64bit int.

und das kann man eben nicht generell so sagen. vor allem nicht in einem OSX Entwicklerfourm

Amin Negm-Awad · 19. Mai 2011, 20:01

Du vergisst dabei: "da man oben gesagtes bei den modernen Prozessoren so einfach auch wieder nicht ableiten kann."

Man kann von eine Prozessor schon seit einiger Zeit nur schwer sagen, welche Wortgröße sie haben. Schon der 68k konnte doch auch 32-Bit-Operationen, arbeitete aber üblicherweise mit 16 Bit. Das ist einfach nicht mehr so einfach. Und dann kann man eben auch nicht den int daraus ableiten. Ich glaube jedenfalls, dass er das sagen wollte.

Das verlangt auch der Standard:
A ‘‘plain’’ int object has the natural size suggested by the architecture of the execution environment […].
open-std.org/JTC1/SC22/WG14/www/docs/n1256.pdf

Bloß: Was ist schon die "natürliche" Größe? AFAIK hat etwa 64-Bit-Windows ILP64.

gritsch · 19. Mai 2011, 20:06

Amin Negm-Awad schrieb:

Du vergisst dabei: "da man oben gesagtes bei den modernen Prozessoren so einfach auch wieder nicht ableiten kann."

Man kann von eine Prozessor schon seit einiger Zeit nur schwer sagen, welche Wortgröße sie haben. Schon der 68k konnte doch auch 32-Bit-Operationen, arbeitete aber üblicherweise mit 16 Bit. Das ist einfach nicht mehr so einfach. Und dann kann man eben auch nicht den int daraus ableiten. Ich glaube jedenfalls, dass er das sagen wollte.

Das verlangt auch der Standard:
A ‘‘plain’’ int object has the natural size suggested by the architecture of the execution environment […].
open-std.org/JTC1/SC22/WG14/www/docs/n1256.pdf

Bloß: Was ist schon die "natürliche" Größe? AFAIK hat etwa 64-Bit-Windows ILP64.

jetzt reite nicht auf irgendwelchen spitzfindigkeiten rum sondern bleib bei dem was gemeint war: er schrieb 64-bit prozessor und quasi jeder neuere mac hat einen solchen drin. wird von apple so beworben, x86_64 ist der name der architektur und fertig. wenn jetzt jemand sagt dass mein int für gewöhnlich jetzt 64 bit groß ist dann ist das nunmal falsch. es geht hier nicht darum wie du eine aussage liest (als anwalt) sondern 99,9% der anderen leser.

Thallius · 19. Mai 2011, 22:36

Nein ich schrieb genau das was Amin gesagt hat. Das es mal die Idee war das int die native Größe des Prozessors sein sein soll, aber da heutige Prozessoren derart komplex aufgebaut sind (viel komplexer als man sich damals hätte vorstellen können als diese Idee aufkam) es nicht mehr so einfach ist zu sagen, was denn nun eigentlich seine native Größe ist. Und deshalb habe ich diesen Satz ja auch geschrieben. Sonst hätte ich den ja auch weglassen können. Aber ich sehe mal drüber hinweg, da es als Tiroler ja nicht so einfach ist die deutsche Sprache zu verstehen und schon gar nicht wenn es um so komplex Themen geht

Gruß

Claus

zerm · 19. Mai 2011, 22:41

Ich würde mal behaupten, dass ein Prozessor nicht mit seiner "nativen" Breite am effizientesten rechnet, sondern einfach nur mit breiteren Eingaben als seine native Breite deutlich ineffizienter.
Ein x86_64 juckt sich nicht an 16bit operationen. Dafür hat er sogar eigene Assembler-Befehle, Register(!) und wahrscheinlich sogar optimierte Pipelines. Der ist nicht effizienter mit 32bit und auch nicht mit 64bit (wenn das zugrunde liegende Programm nicht von der Breite profitiert).
Hingegen hat ein 16bit Prozessor ganz schön zu kämpfen mit 32bit Worten, da er immer stückeln muss etc.

gritsch · 20. Mai 2011, 07:34

Thallius schrieb:

Nein ich schrieb genau das was Amin gesagt hat. Das es mal die Idee war das int die native Größe des Prozessors sein sein soll, aber da heutige Prozessoren derart komplex aufgebaut sind (viel komplexer als man sich damals hätte vorstellen können als diese Idee aufkam) es nicht mehr so einfach ist zu sagen, was denn nun eigentlich seine native Größe ist. Und deshalb habe ich diesen Satz ja auch geschrieben. Sonst hätte ich den ja auch weglassen können. Aber ich sehe mal drüber hinweg, da es als Tiroler ja nicht so einfach ist die deutsche Sprache zu verstehen und schon gar nicht wenn es um so komplex Themen geht

Gruß

Claus

dann hast du dich eben so ausgedrückt dass es der fragende sicher falsch verstanden hat weil er seinen x86_64 sicher als von dir genannten 64-bit prozessor verstanden hat und damit davon ausgehen müsste dass ein int 64 bit groß ist.

macmoonshine · 20. Mai 2011, 07:38

junky94 schrieb:

short int = 2 bytes
unsigned int = 4 bytes
int = 4 bytes
long int = 4 bytes
long long int = 8 bytes

Wieso braucht long int gleich viel Speicher wit int?

Das hängt übrigens auch davon ab, wie Du Dein Programm übersetzt. Das kommt unter MacOS X bei der Übersetzung als 32-Bit-Programm raus. Wenn Du es als 64-Bit Programm übersetzt, hat long auch 8 Bytes und int 4.

mattik · 20. Mai 2011, 10:41

X86-64-Prozessoren sind 64-Bit-Prozessoren mit mehreren Operating Modes. Im 64 Bit Mode ist die typische General-Purpose-Registerbreite 64 Bit, aber die typische Operandengröße 32 Bit. Im Compatibility Mode sind beide 32 Bit (siehe Wikipedia). Also entspricht unter OSX unter beiden verwendeten Modi int immer der typischen Operandenbreite, long immer der Breite eines typischen GPR. Das ist doch logisch und konsistent, oder?

Prozessoren mit unterschiedlichen Breiten sind keine Neuheit - schon zu 68K-Zeiten gab's das. Der M68000 hatte 32-Bit-GPRs, aber nur einen externen 16-Bit Datenbus. Der M68008 sogar nur 8 Bit. Deshalb war er mit seiner nativen Registerbreite erheblich langsamer als mit kürzeren Werten, schon damals gab's keine "richtige" Länge für int. Die Architektur wurde als 8/16/32-Bit-Architektur bezeichnet. Und es gibt etliche weitere Beispiele.

Ich bin ziemlich verwundert, wie herzhaft hier schon in etlichen Threads über die Größe von bestimmten Typen diskutiert wurde. Et is wie et is. Es gibt die eingebauten Typen mit den gegebenen Eigenschaften und weitere Typendefinitionen für alles, was das Herz begehrt. Und wenn man Spaß dran hat, darf man sich darüber hinaus seine eigenen Typen selbst definieren, wie man lustig ist. Klar, man sollte wissen, was man tut, aber das ist beim Programmieren eigentlich immer so.

FRing · 20. Mai 2011, 10:46

mattik schrieb:

X86-64-Prozessoren sind 64-Bit-Prozessoren mit mehreren Operating Modes. Im 64 Bit Mode ist die typische General-Purpose-Registerbreite 64 Bit, aber die typische Operandengröße 32 Bit. Im Compatibility Mode sind beide 32 Bit (siehe Wikipedia). Also entspricht unter OSX unter beiden verwendeten Modi int immer der typischen Operandenbreite, long immer der Breite eines typischen GPR. Das ist doch logisch und konsistent, oder?

Prozessoren mit unterschiedlichen Breiten sind keine Neuheit - schon zu 68K-Zeiten gab's das. Der M68000 hatte 32-Bit-GPRs, aber nur einen externen 16-Bit Datenbus. Der M68008 sogar nur 8 Bit. Deshalb war er mit seiner nativen Registerbreite erheblich langsamer als mit kürzeren Werten, schon damals gab's keine "richtige" Länge für int. Die Architektur wurde als 8/16/32-Bit-Architektur bezeichnet. Und es gibt etliche weitere Beispiele.

Ich bin ziemlich verwundert, wie herzhaft hier schon in etlichen Threads über die Größe von bestimmten Typen diskutiert wurde. Et is wie et is. Es gibt die eingebauten Typen mit den gegebenen Längen und weitere Typendefinitionen für alles, was das Herz begehrt. Und wenn man Spaß dran hat, darf man sich darüber hinaus seine eigenen Typen selbst definieren, wie man lustig ist. Klar, man sollte wissen, was man tut, aber das ist beim Programmieren eigentlich immer so.

Sehe ich auch so ! Wichtiger ist zu wissen, wie die verschiedenen Typen definiert sind und wie ich diese anwende ! Ich denke bei der CPU Leistung heute ist es egal, wie gut die Länge oder was auch immer zu meiner CPU passt. Vieles übernimmt heute der Compiler und die CPU selber. Wichtiger ist es die Auswirkungen der Typen auf meine Anforderung zu wissen.

Amin Negm-Awad · 20. Mai 2011, 12:28

In der Regel stimmt das, jedoch nicht immer. Zum einen muss man das natürlich wissen, um zu beurteilen, ob der Wert in meine Variable des Typs passt. Wie ich aber oben schon schrieb, kann es auch sonst lustige Fälle geben.

Nehmen wir einen short mit 16 Bit (OS X). Dann nehmen wir an, dass ein int 32 Bit hat (OS X). Jetzt führen wir eine short-Operation aus und weisen das an einen int zu:

int res;
short op;

op = 1;
res = op << ((short)16);

Nach den üblichen Regeln ist das << eine Operation, die auf einen short angewendet wird, weil beide Operanden short sind. Demnach müsste das aus den 16 Bit herausgeschoben werden und als Ergebnis 0 liefern. Diese (short)0 wird dann an ein int zugewiesen und wird damit nach den Casting-Regeln eine (int)0.

Tatsächlich kommt aber 65536, also 1^16 heraus. Das kann eigentlich niemals das Ergebnis einer short-Operation sein.

Das liegt daran, dass bei einem short die Rechnung in der natürlichen Wortbreite des Prozessors vorgenommen werden darf. Es erfolgt die Berechnung eben nicht in der kleineren Breite.

Die Wege des Herrn sind unergründlich. Die Wege von C sind aberwitzig …

Amin Negm-Awad · 20. Mai 2011, 12:36

zerm schrieb:

Ich würde mal behaupten, dass ein Prozessor nicht mit seiner "nativen" Breite am effizientesten rechnet, sondern einfach nur mit breiteren Eingaben als seine native Breite deutlich ineffizienter.
Ein x86_64 juckt sich nicht an 16bit operationen. Dafür hat er sogar eigene Assembler-Befehle, Register(!) und wahrscheinlich sogar optimierte Pipelines. Der ist nicht effizienter mit 32bit und auch nicht mit 64bit (wenn das zugrunde liegende Programm nicht von der Breite profitiert).
Hingegen hat ein 16bit Prozessor ganz schön zu kämpfen mit 32bit Worten, da er immer stückeln muss etc.

Tatschlich wird aber mit der natürlichen Breite gerechnet, siehe oben. Übrigens auch bei char, was die Sache schon sehr bemerkenswert macht. Alles was kleiner ist, existiert nicht verlässlich in C.

Tags