Hallo zusammen, vielleicht kann mir einer helfen. Ich habe bereits im Forum und bei Google danach gesucht, jedoch bin ich nicht weiter gekommen. Ich sehe so oft, das 8Bit-Variablen mit der Deklaration "uint_8" bezeichnet werden. Beim suchen habe ich nun noch weitere Varianten, wie uint8_t gesehen. Aber bei funktioniert keines davon. Für 8Bit-Variablen lege ich bisher nun halt ein 'unsigned char' an. Das funktioniert natürlich, auch zum Zählen von 0 bis 255. Aber eignetlich ist der char dafür ja nicht gedacht, oder ist das völlig egal...nur ein Stilbruch oder sonstiges? Fehlt mir ein #include für diese Variablendeklaration? Vielen Dank, Dennis
Verzichte darauf... Der MSP430 ist ein 16bit-Prozessor. 8Bit-Variable belegen dennoch einen 16Bit-Speicherplatz, das erzwungene Rechnen mit 8bit kostet nur mehr Code.
Also absoluter Schwachsinn? Alles als unsigned int deklarieren?
Nur mal aus Interesse: Wieso braucht das mehr Code? Dann bewirke ich damit ja genau das Gegenteil, als wie ich wollte. Ich hatte gedacht, ich spare damit Ressourcen...
H.joachim Seifert schrieb:
> 8Bit-Variable belegen dennoch einen 16Bit-Speicherplatz
Das glaub ich Dir nicht.
Dann dürfte ja keine UART, I2C, SPI usw. gehen, die 8Bit Daten
übertragen müssen.
Es muß sehr wohl möglich sein, auch 8Bit Variablen im SRAM anzulegen,
sonst kannste das Ding in die Tonne kloppen.
Peter
Ich seh grad, in der stdint.h sind die ja drin...jedoch sehe ich auch, dass das äquivalent zu uint_8 genau der unsigned char ist. Also egal! Ich wollte die nicht einbinden, weil eigentlich nicht unbedingt nötig - nimmt halt noch mehr Speicher weg. Und wenn es ohne #includes geht... Aber trozdem, warum verbraucht es mehr Code mit 8Bit-Variablen? Danke! Dennis
Peter Dannegger schrieb: > Es muß sehr wohl möglich sein, auch 8Bit Variablen anzulegen, sonst > kannste das Ding in die Tonne kloppen. Es gibt CPUs, die nur 32-bit-Einheiten kennen (einige DSPs), die trotzdem keiner in die Tonne gekloppt hat... Falls es auf einer CPU effektiver (im Sinne von schneller) ist, dass man eine mindestens 8 bit breite Zahl größer macht, dann sollte man stattdessen halt uint_fast8_t nehmen, wenn man nicht zwingend exakt 8 bit braucht.
Mein Ziel war ja eigentlich nur, dass ich RAM spare, wenn ich eine Variable habe, die von 1-10 zählen muss - da brauch ich ja keinen ganzen integer zu.
Dennis E. schrieb: > Ich wollte die nicht einbinden, weil eigentlich nicht unbedingt nötig - > nimmt halt noch mehr Speicher weg. So'n Quark. Du solltest erst einmal anfangen zu verstehen, wie eine Headerdatei funktioniert, bevor du wild mit Datentypen herum jonglierst.
Dennis E. schrieb: > Mein Ziel war ja eigentlich nur, dass ich RAM spare, wenn ich eine > Variable habe, die von 1-10 zählen muss - da brauch ich ja keinen ganzen > integer zu. Wenn du von 1 bis 10 zählen willst, dann verwette ich meine nicht mehr vorhandene Haarpracht, dass der Compiler das in einem Register macht und du kein müdes Bit RAM sparst. Damit wäre uint_fast8_t angebracht. Wenn du den gleichen Code dann bspw. auf einen AVR portierst, weiß der Compiler sofort, dass ein 8-bit-Register auch genügt. (Andererseits kann er sich das beim Zählen von 1 bis 10 auch an allen 10 Fingern abzählen, dass das so ist. :-)
Darf ich noch die Frage loswerden, was damit gemeint ist? Ich kenne den Datentyp "uint_fast8_t" nicht, sorry! The standard doesn't mandate anything about these types except that their widths must be ≥ N. It also leaves it up to the implementor to decide what it means to be a "fast" integer type. An implementation is required to define these for the following N: 8, 16, 32, 64. Also nicht die Übersetzung, sondern ich kenne den Zweck der Deklaration nicht.
Die Idee ist: [u]intN_t: verlangen eine exakte Bitbreite, egal wie effektiv oder uneffektiv deren Benutzung ist; kann eine Maschine eine bestimmte Bitbreite nicht implementieren, dann fehlt der Typ, und das Compilieren eines enstprechenden Quelltextes schlägt fehl (statt u. U. fehlerhafte Annahmen beispielsweise über das Überlaufverhalten eines Datentyps wie "unsigned char" zu treffen). [u]int_leastN_t: verlangt mindestens N bits Breite; kann eine Maschine einen derartigen Datentyp nicht implementieren, so kann sie einen breiteren Datentyp stattdessen einsetzen; der Fokus liegt auf einer möglichen Speicherplatzeinsparung, sie sollte also den kleinsten passenden Typ wählen. [u]int_fastN_t: verlangt mindestens N bits Breite; Fokus liegt auf Verarbeitungsgeschwindigkeit; wenn eine Maschine bspw. beim Zugriff auf 8-bit-Datentypen mehr Aufwand treiben muss als bei der Nutzung eines 16- oder 32-bit-Typs an gleicher Stelle, dann sollte sie letzteren benutzen. Dies ist in der Regel immer der Fall, wenn die Register- und Speicherbusbreite größer ist als die gewünschte Anzahl von Bits.
Das heisst ja nicht, dass man nicht auch auf 8bit-Register zugreifen kann. Es ging schliesslich um Variablen. In einem 16bit-System ist eine RAM-Adresse aber normalerweise auch 16bit breit. Und die wird auch benutzt, auch wenn dann nur die Hälfte davon für eine 8Bit-Variable benötigt wird, falls nicht explizit vom Befehlssatz 8bit-Zugriff auf high- und low-Byte unterstützt wird. Kenn aber den MSP nicht. Üblicherweise ergibt sich der einfachste und effektivste Zugriff, wenn man den Grundtyp des Prozessors benutzt.
>Kenn aber den MSP nicht. Üblicherweise ergibt sich der einfachste und >effektivste Zugriff, wenn man den Grundtyp des Prozessors benutzt. Wenn man beim MSP430 8-bit Variablen benutzt, werden im RAM auch nur 8 Bits belegt...man sollte aber das Alignment beachten, d.h. beim wilden Mixen von char, int, long, ...was weiß ich... gibt's Füll-Bits...
Ich würde beim Programmieren nicht zu viel Rücksicht auf den verwendeten Prozessor nehmen; überlasse solche Optimierungen dem Compiler. Die Datentypen sollten sich nach Deiner Anwendung richten. Brauchst Du also z.B. einen Zähler, dem ein 8-Bit Wertebereich ausreicht, dann nimm dafür den uint_fast8_t Datentyp, egal für welche Plattform Du programmierst. Dieser Code wird dann aber auch auf anderen Plattformen/Prozessoren einwandfrei funktionieren, ist also portabel. Char solltest Du nur für Zeichen oder Zeichenfolgen verwenden.
>Ich seh grad, in der stdint.h sind die ja drin...jedoch sehe ich auch, >dass das äquivalent zu uint_8 genau der unsigned char ist. Also egal! Falsch gedacht, das ist eben nicht egal. char ist absolut nixsagend und seine grösse ändert sich vom compiler zu compiler. tu dir und deinem nachfolger (maintainer) einen gefallen und drücke explizit aus welche numerische grösse hinreichend ist. es kann durchaus sein, dass 8 bit berechung mehr code benötigt. uint_8 x=255; x++; muss eben garantiert 0 werden. was soll deiner meinung nach compiler daraus machen? length=foo(); for(uint_8 i=0; i<length; i++) { /**/ } du magst das wissen haben, dass legnth immer kleiner als 100 ist. compiler muss die möglichkeit des falles i=255 mitberücksichtigen! wenn internes register 16 bit hat, wird gecheckt ob bit 8 1 ist oder nicht. => mehr code
OK, ich ging davon aus, dass char eine 8Bit-Variable ist. Ich habe bis jetzt nur mit IAR-Embedded-WB gearbeitet und da ist das halt als 8Bit festgelegt. Aber OK, vielen Dank, dann werde ich das in Zukunft berücksichtigen.
Dennis E. schrieb:
> OK, ich ging davon aus, dass char eine 8Bit-Variable ist.
Wenn die Maschine keine 8-bit-Einheiten kennt, ist sie es nicht.
Zugegeben exotisch, aber möglich und völlig konform zum C-Standard.
Man muss dabei noch beachten, dass sizeof(char) per definitionem immer
1 ist.
Jörg Wunsch schrieb: > Wenn die Maschine keine 8-bit-Einheiten kennt, ist sie es nicht. > Zugegeben exotisch, aber möglich und völlig konform zum C-Standard. Gibt es dafür real existierende Beispiele, die nicht in einem Computermuseum stehen? ;-)
Mark Brandis schrieb: > Gibt es dafür real existierende Beispiele, die nicht in einem > Computermuseum stehen? ;-) Irgendwelche DSPs, genaue Typen habe ich aber vergessen.
Willy schrieb: >>Ich seh grad, in der stdint.h sind die ja drin...jedoch sehe ich auch, >>dass das äquivalent zu uint_8 genau der unsigned char ist. Also egal! > > Falsch gedacht, das ist eben nicht egal. > char ist absolut nixsagend und seine grösse ändert sich vom compiler zu > compiler. > tu dir und deinem nachfolger (maintainer) einen gefallen und > drücke explizit aus welche numerische grösse hinreichend ist. > > es kann durchaus sein, dass 8 bit berechung mehr code benötigt. beim MSP430 normalerweise nicht... > uint_8 x=255; x++; muss eben garantiert 0 werden. was soll deiner > meinung nach compiler daraus machen? > > length=foo(); > for(uint_8 i=0; i<length; i++) { > /**/ > } > > du magst das wissen haben, dass legnth immer kleiner als 100 ist. > compiler muss die möglichkeit des falles i=255 mitberücksichtigen! > wenn internes register 16 bit hat, wird gecheckt ob bit 8 1 ist > oder nicht. => mehr code Beim Überlauf von 8-Bit-Operationen wird ganz normal das Carry-Flag gesetzt, wenn der Compiler vernünftig optimiert, wird der Vergleich weggelassen und ein simpler jnc forLoop erzeugt (bzw. sollte der Compiler das so machen...).
>Beim Überlauf von 8-Bit-Operationen wird ganz normal das Carry-Flag >gesetzt, wenn der Compiler vernünftig optimiert, wird der Vergleich >weggelassen und ein simpler jnc forLoop erzeugt (bzw. sollte der >Compiler das so machen...) das ist gut, wenn dieser 16-biter das tut. eine anderere einfachere 16bit ALU wird das nicht tun (wobei ich persönlich mit 16 bitter nicht gearbeitet habe). Ein analoges Problem gibt es wenn Leute short statt int benutzen. Aber das eher im ARM Bereich.
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.