Revision history for CPrimitiveDatentypen


Revision [31347]

Last edited on 2020-06-23 15:37:06 by ToBo

No Differences

Revision [31346]

Edited on 2020-06-23 15:37:06 by ToBo
Additions:
[[CPrimitiveDatentypenWeitere|Weitere Architekturen]]
Deletions:
[[CPrimitiveDatentypenWeitere Weitere Architekturen]]


Revision [18726]

Edited on 2014-03-18 18:48:35 by ToBo
Additions:
|=|int|| 16 / 8+ || 16 || 32?|| 16? || 32? || 64 || 32 || 64 ||
|=|long|| 32 / 16+|| 32 || 32 || 64 || 64 || 64 || 32 || 64 ||
|=|long long|| 64 / 32+ || 64 || 64 || 64 || 64 || 64 || 64 || 64||
|=|double|| 32 || 64* || 64*|| 64* || 64 || 64 || 64 || 64 ||
|=|Pointer|| 8 / 16 || 16 || 32 || 32 || 64 || 64 || 64 || 64 ||
+ Mit der Compileroption -mint8 wird der GNU-C-Compiler für AVR-Mikrocontroller angewiesen den Datentyp 'int' als 8-Bit-Integer zu behandeln. "A char will be 1 byte, an int will be 1 byte, an long will be 2 bytes and long long will be 4 bytes. Please note that this option does not comply to the C standards, but it will provide you with smaller code size. "
Deletions:
|=|int|| 16 || 16 || 32?|| 16? || 32? || 64 || 32 || 64 ||
|=|long|| 32 || 32 || 32 || 64 || 64 || 64 || 32 || 64 ||
|=|long long|| 64 || 64 || 64 || 64 || 64 || 64 || 64 || 64||
|=|double|| 64* || 64* || 64*|| 64* || 64 || 64 || 64 || 64 ||
|=|Pointer|| 8/16 || 16 || 32 || 32 || 64 || 64 || 64 || 64 ||


Revision [13614]

Edited on 2012-04-29 13:35:06 by ToBo
Additions:
Bei der Frage nach dem Speicherbedarf ist es nicht nur relevant, ob es sich um Prozessorarchitekturen mit 8 Bit, 16 Bit, 32 Bit oder 64 Bit handelt, sondern genauer um welches Datenmodell des Prozessors es geht (... , IP16, ILP32, LP32, LP64, ILP64, LLP64, SILP64, ...).
Deletions:
Bei der Frage nach dem Speicherbedarf ist es nicht nur relevant, ob es sich um Architekturen mit 8 Bit, 16 Bit, 32 Bit oder 64 Bit handelt, sondern genauer um welches Datenmodell es geht (... , IP16, ILP32, LP32, LP64, ILP64, LLP64, SILP64, ...).


Revision [10090]

Edited on 2009-09-07 23:53:13 by ToBo
Additions:
Bei der Frage nach dem Speicherbedarf ist es nicht nur relevant, ob es sich um Architekturen mit 8 Bit, 16 Bit, 32 Bit oder 64 Bit handelt, sondern genauer um welches Datenmodell es geht (... , IP16, ILP32, LP32, LP64, ILP64, LLP64, SILP64, ...).
Sie werden bestimmt sehr gut mit der ILP32 vertraut sein, wenn Sie unter Linux oder Windows auf einem 32-Bit-System programmiert haben. Das Datenmodell hat sich hier durchgesetzt.
LP32 war bei den ersten Versionen von DOS.
Die Pointer sind keine primitiven Datentypen, aber es ist vielleicht interessant sie hier in dieser Tabelle der Vollständigkeit halber aufzuführen, den auch für Pointer gibt es Rechenregeln und einen Speicherbedarf, der von der Architektur abhängig ist.
Deletions:
Das Datenmodell hängt u.a. von der Rechnerarchitektur ab (8 Bit, 16 Bit, 32 Bit, 64 Bit)
Sie werden bestimmt mit dem ILP32 vertraut sein, wenn Sie unter Linux oder Windows auf einem 32-Bit-System programmiert haben. Das Datemodell hat sich hier durchgesetzt.
LP32 die ersten Versionen von DOS
Die Pointer sind keine primitiven Datentypen, aber es ist vielleicht interessant sie hier in dieser Tabelle der Vollständigkeit halber aufzuführen.


Revision [10089]

Edited on 2009-09-07 23:45:52 by ToBo
Additions:
Die nachfolgende Tabelle zeigt den Speicherbedarf von [[PrimitiveDatentypen primitiven Datentypen]] und Pointern in der [[C Programmiersprache C]] in Abhängigkeit des Datenmodells (ILP32, LP64, ILP64,...) in Byte.
* je nach Compiler-Typ wird hier dem Entwickler die Wahl überlassen oder es wird einfach **float** verwendet. Gerade bei Compilern für auf 8- oder 16-Bit-Mikrocontroller werden oft nur floats verwendet, auch wenn **double** deklariert wird.
Die Schlüsselwörter **signed** und **unsigned** haben keinen Einfluss auf die Werte in der Tabelle von oben.
~-Wenn man portablen Code schreiben möchte, ist von der Verwendung von **int** - zumindest int alleine - zunächst abzuraten. Stattdessen ist **long** und **short** bzw. voll ausgeschrieben **long int** und **short int** besser, da dann klar ist, wie groß der Wertebereich nach dem Compilieren ist.
~-Bei der Verwendung von **double** unbedingt das Compiler-Handbuch lesen.
~-Für Flags oder für Zustandsvariablen ist die Verwendung von **char** bei 16-Bit und 32-Bit-Prozessoren ggf. abzuraten, da die Verarbeitungsgeschwindigkeit darunter leiden kann. Der Rechner wird den 8-Bit-Wert in ein 16-Bit bzw. ein 32-Bit-Register schieben und nach der Bearbeitung muss das Programm sicherstellen, dass der Wert nicht größer als 8-Bit ist. Hier kann **int** hinsichtlich der Verarbeitungsgeschwindigkeit besser sein, allerdings dann nicht mehr als 8-Bit verwenden.
Deletions:
Die nachfolgende Tabell zeigt die Größe von primitive Datentypen und Pointern in C in Abhängigkeit in Abhängigkeit des Datenmodells (ILP32, LP64, ILP64,...) in Byte.
* je nach Compiler-Typ wird hier dem Entwickler die Wahl überlassen oder es wird einfach float verwendet. Gerade bei Compilern für auf 8- oder 16-Bit-Mikrocontroller werden oft nur floats verwendet, auch wenn double deklariert wird.
Die Schlüsselwörter signed und unsigned haben keinen Einfluss auf die Werte in der Tabelle von oben.
~-Wenn man portablen Code schreiben möchte, ist von der Verwendung von int - zumindest int alleine - zunächst abzuraten. Stattdessen ist long und short bzw. long int und short int besser, da dann klar ist, wie groß der Wertebereich nach dem Compilieren ist.
~-Bei der Verwendung von double unbedingt das Compiler-Handbuch lesen.
~-Für Flags oder für Zustandsvariablen ist die Verwendung von char bei 16-Bit und 32-Bit-Prozessoren ggf. abzuraten, da die Verarbeitungsgeschwindigkeit darunter leiden kann. Der Rechner wird den 8-Bit-Wert in ein 16-Bit bzw. ein 32-Bit-Register schieben und nach der Bearbeitung muss das Programm sicherstellen, dass der Wert nicht größer als 8-Bit ist. Hier kann int hinsichtlich der Verarbeitungsgeschwindigkeit besser sein, allerdings dann nicht mehr als 8-Bit verwenden.


Revision [3294]

The oldest known version of this page was created on 2008-05-30 00:30:39 by ToBo
Valid XHTML :: Valid CSS: :: Powered by WikkaWiki