www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Datentyp uint_8 in IAR für MSP430


Autor: LuXXuS 909 (aichn)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: H.Joachim Seifert (crazyhorse)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Verzichte darauf...
Der MSP430 ist ein 16bit-Prozessor.
8Bit-Variable belegen dennoch einen 16Bit-Speicherplatz, das erzwungene 
Rechnen mit 8bit kostet nur mehr Code.

Autor: LuXXuS 909 (aichn)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also absoluter Schwachsinn? Alles als unsigned int deklarieren?

Autor: LuXXuS 909 (aichn)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
stdint.h hast du aber includiert?
http://en.wikipedia.org/wiki/stdint.h

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: LuXXuS 909 (aichn)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: LuXXuS 909 (aichn)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. :-)

Autor: LuXXuS 909 (aichn)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
OK, danke!

Autor: LuXXuS 909 (aichn)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: LuXXuS 909 (aichn)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, vielen Dank für die Info!

Autor: H.Joachim Seifert (crazyhorse)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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...

Autor: Johnny B. (johnnyb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Willy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: LuXXuS 909 (aichn)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Mark Brandis (markbrandis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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? ;-)

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mark Brandis schrieb:

> Gibt es dafür real existierende Beispiele, die nicht in einem
> Computermuseum stehen? ;-)

Irgendwelche DSPs, genaue Typen habe ich aber vergessen.

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...).

Autor: Willy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.