Hallo, welche Bibliothek muss ich einbinden, um (U32), (U16), (U8) verstehen zu können? DANKE!
U32 schrieb: > Hallo, > > welche Bibliothek muss ich einbinden, um (U32), (U16), (U8) verstehen zu > können? > > DANKE! Gar keine. Das steht in der "inttypes.h" BITTE!
Huh schrieb: > Das steht in der "inttypes.h" Nein, da stehen Typnamen wie uint8_t, uint16_t, uint32_t. Die U8 etc. sind Erfindungen von wer auch immer die Software gezimmert hat, die das verwendet. Allerdings sollte man sie mit <inttypes.h> einfach emulieren können:
1 | #include <inttypes.h> |
2 | |
3 | #define U8 uint8_t
|
4 | #define U16 uint16_t
|
5 | #define U32 uint32_t
|
U32 schrieb: > (U32), (U16), (U8) Das war (und evtl. ist immer noch? - ich befürchte Schlimmes) lange Zeit eine Unart von Keil - vgl. u. a. http://www.keil.com/support/man/docs/rlarm/rlarm_lib_u8.htm
Jörg W. schrieb: > Nein, da stehen Typnamen wie uint8_t, uint16_t, uint32_t. Hast Recht, sorry. Asche auf mein graues Haupt! :-)
Jörg W. schrieb: > Allerdings sollte man sie mit <inttypes.h> einfach emulieren können: und du meinst, uint8_t ist lesbarer als U8 ? Abgesehen davon ist das auch bloß ein unsigned char und sonst nix. Ich halte das für ein vorgezogenes Freitagsthema und benutze ungeniert byte, word und dword. Paßt viel besser zu meinem sonstigen Umfeld. W.S.
Streng genommen stehen diese Datentypen auch nicht in <inttypes.h>, sondern in <stdint.h>. Und diese Unart mit "byte = 8 Bit", "word = 16 Bit" und "dword = 32 Bit" geht auf Microsoft und i86/i286 zurück.
Jörg W. schrieb: > #define U8 uint8_t > #define U16 uint16_t > #define U32 uint32_t wenn schon, dann doch bitte mit typedef:
1 | typedef uint8_t U8; |
2 | typedef uint16_t U16; |
3 | typedef uint32_t U32; |
Sonst bekommt man früher oder später Probleme... W.S. schrieb: > Ich halte das für ein vorgezogenes Freitagsthema und benutze ungeniert > byte, word und dword. Paßt viel besser zu meinem sonstigen Umfeld. Ich dachte dein Umfeld ist Lern-Betty und ARM. Da heißen die Dinger Byte, Half-Word (16bit), Word (32bit)... Da sind uint16_t und uint32_t doch etwas weniger missverständlich...
W.S. schrieb: > byte, word und dword. Paßt viel besser zu meinem sonstigen Umfeld. Diese Variante ist bei vielen 32-Bit Plattformen etwas irreführend, da diese meist 32 Bits als Breite eines Wortes definieren (Ausnahme Intel). In C hat dann ein Wort 16 Bits, in Assembler 32 Bits.
A. K. schrieb: > Diese Variante ist bei vielen 32-Bit Plattformen etwas irreführend Nö. Ich benutze eben diese Terminologie (byte, word, dword) durchgehend über alle Architekturen und alle Programmiersprachen. Hat sich glänzend bewährt. Da ist nix irreführend. Eher schon die alberne Unterscheidung word und halfword. Zuerst war mir das vor Jahren bei Fujitsu FR aufgefallen, aber ARM macht den gleichen Unsinn. Das muß man glücklicherweise aber nur bei Assembler-Quellen beachten (so ähnlich klingendes wie MOVB, MOVH, MOVW). Dr. Sommer schrieb: > Sonst bekommt man früher oder später Probleme... Ach wo. Probleme bekommen nur Leute, die ohnehin nicht wissen, was sie tun. Die benutzen dann eifrigst alles, was man ihnen vorsetzt - und sie glauben dann, daß sie ja eben deshalb garnix falsch gemacht haben könnten. Von wegen.. gestern U32 und heute uint32_t, morgen ne andere Sau durch's Dorf, immer feste was neues. Dabei wird alles schlußendlich auf den altbekannten Urschleim unsigned long int heruntergebrochen. Klasse! Schöne neue Welt. W.S.
W.S. schrieb: > und du meinst, uint8_t ist lesbarer als U8 ? Hat das irgendwer irgendwo behauptet? Es ist aber standardisiert. > Abgesehen davon ist das auch bloß ein unsigned char und sonst nix. Nur dann, wenn _CHAR_BIT_ == 8 ist. Wenn es ungleich 8 ist, dann gibt es nämlich schlicht und ergreifend gar kein uint8_t. Wenn sich jemand U8 selbst als "unsigned char" definiert und dann versucht wird, den Code auf eine Plattform zu portieren, die keine 8-Bit-Einheiten kennt (zugegeben, die sind selten, aber es gibt sie), dann macht das Zeug irgendwas, während es bei Benutzung von uint8_t einen Compilerfehler gibt. > Ich halte das für ein vorgezogenes Freitagsthema und benutze ungeniert > byte, word und dword. Für mich wäre "word" ein 32-bit-Typ, "dword" 64 bit, "hword" 16 bit. So können sich die Ansichten bei solcherart gut standardisierten Begriffen unterscheiden. ;-)
W.S. schrieb: > das vor Jahren bei Fujitsu FR aufgefallen, aber ARM macht den gleichen > Unsinn. Auch wenn es für viele heute so scheinen mag - die Computertechnik fing nicht erst bei Intel an. Der Begriff "Wort" stand von Anfang an für die native Breite zumindest der ursprünglichen Architektur einer Architekturfamilie. Das war auch bei Intel 8086 so. Nur fing 8086 bei 16 Bits an, mit word=16b. Andere, wie ARM oder Power(PC), fingen mit 32 Bits an, mit word=32b. Oder hatten (Ganz)Worte mit 48, Halbworte mit 24 und Drittelworte mit 16 Bits. Und bei 36-Bit Maschinen hatte man eher 9-Bit als 8-Bit Bytes (oder 6-Bit Zeichen). Dass die 68000 mit 16-Bit Worten operierte lag daran, dass man sich bei dieser Architektur nicht recht entscheiden konnte, ob das eine 16-Bit Architektur mit umfangreichen 32-Bit Möglichkeiten war, oder nicht doch schon eine 32-Bit Architektur. Begriffe wie "Byte" und "Wort" stehen also historisch belegt nicht für bestimmte Bitbreiten, sondern beziehen sich auf die jeweilige Architektur. Die wohl erste Universalarchitektur war IBMs 360, die 8-Bit Bytes adressierte und mit 32-Bit Worten und 16-Bit Halbworten arbeitete.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.