Dateitypen uint8_t, uint16_t, ...



  • Hallo,

    ich schreibe gerade eine Bibliothek und bin mir nicht ganz sicher was für
    Datentypen ich für Integer verwenden soll. Viele Bibliotheken definieren ihre
    eigenen Datentypen oder verwenden unsigned int auch, wenn es viel zu groß
    für die Daten ist.

    Ich habe mich jetzt dafür entschieden uint8_t, uint16_t, ... zu
    verwenden und den kleinst möglichen Datentyp zu verwenden. Allerdings kenne ich
    nicht viele C-Programme welche diese Datentypen benutzen. Kann ich das so machen? Ist das guter Stil?

    Gruß
    Hans Baumer


  • Mod

    Kannst machen. Musst du wirklich Speicher sparen? Meistens ist es von der Geschwindigkeit her günstig, einfach die Standarddatentypen (int, unsigned int) zu nehmen.

    Das wird übrigens so selten benutzt, da diese typedefs erst mit C99 eingeführt wurden. Ein großer, bekannter Compiler (Microsoft) kann jedoch nur C89 und das wird sich auch nicht mehr ändern.



  • MSVC unterstützt <stdint.h> meines Wissens seit der 2010er Version.

    Ansonsten ist es schwer, diese Frage allgemeingültig zu beantworten - für Netzwerkcode gelten andere Regeln als für Embedded-Code und ganz andere als für GUI-Bibliotheken. Kannst du vielleicht kurz umreißen, was deine Bibliothek machen soll?



  • Hallo,

    danke für die schnellen Antworten. Es geht um eine Bibliothek zum entpacken von
    einem bestimmten Archiv. Das Einsatzgebiet ist eher nicht im Embedded-Bereich
    aber trotzdem würde ich gern so sparsam wie möglich mit dem Speicher umgehen.

    Warum normale Integer besser sind kann ich nicht ganz verstehen, weil durch jeden
    Speicherzugriff ja gleich ganze Cache-Lines in den Cache geladen werden und durch
    kleinere Variablen (z.B uint8_t statt unsigned int) mehr Variablen in den Cache passen.

    Gruß
    Hans Baumer


  • Mod

    Denk mal nach, wie ein int8_t auf einem 64-Bit Computer wohl bearbeitet wird.



  • SeppJ schrieb:

    Denk mal nach, wie ein int8_t auf einem 64-Bit Computer wohl bearbeitet wird.

    Hallo,
    ich verstehe dein Einwand nicht. Klar wird das 8-Bit Datenwort wie ein 64-Bit Datenwort bearbeitet aber das 8-Bit Datenwort wird als ein Byte gespeichert und nicht mit vier Byte oder? Welchen Nachteil siehst du da jetzt genau?

    Gruß
    Hans


  • Mod

    hans.b schrieb:

    ich verstehe dein Einwand nicht. Klar wird das 8-Bit Datenwort wie ein 64-Bit Datenwort bearbeitet aber das 8-Bit Datenwort wird als ein Byte gespeichert und nicht mit vier Byte oder?

    Genau. Das bedeutet aber für den Verarbeitungsschritt, dass zuerst das 64-Bit Wort geladen werden muss, das unser byte beinhaltet, dann muss da irgendwie das Byte rausgeholt werden (Bitmaske oder so), dann verarbeitet und dann wieder in das 64-Bit Wort reingestopft werden, ohne den Rest des Wortes zu verändern.

    Ja, das kann schneller sein, wenn die anderen Teile des Gesamtwortes auch noch gebraucht werden (und zwar möglichst oft). Es wird aber langsamer sein, wenn dies nicht der Fall ist. Für irgendwelche Allerweltsvariablen würde ich daher einfach int oder ähnliches nehmen. Erst bei Daten die wirklich stark benutzt werden, würde ich eher aufpassen.

    Typisches Beispiel, das sehr oft hier im Forum kommt: Sieb des Erastothenes. Als schnellste Umsetzung hat sich bis jetzt die erwiesen, bei der man die Bitwerte wirklich Bitweise in einem größeren Datenwort codiert (also umstandlicher Zugriff), da man wirklich sehr, sehr viele Zugriffe hat. Gleichzeitig ist es bei dieser Umsetzung aber auch günstiger, vor einer Zuweisung noch eine (eigentlich teure) Abfrage zu machen, ob die Variable schon den richtigen Wert hat, eben weil jeder unnötige Zugriff so teuer ist.



  • hans.b schrieb:

    ...aber das 8-Bit Datenwort wird als ein Byte gespeichert und nicht mit vier Byte oder? Welchen Nachteil siehst du da jetzt genau?

    Gruß
    Hans

    Nein.

    Das Stichwort lautet Alignment



  • Die Ausrichtung eines Datentyps ist nie größer als seine Größe, sonst wär das mit Arrays schwierig. uint8_t ist ein Byte groß, daher wird er auch auf ein Byte ausgerichtet.

    Ansonsten dürfte die genaue Breite des verwendeten Datentypen im Zusammenhang mit Kompression häufig von Bedeutung sein. Für Schleifenvariablen und so muss das jetzt nicht unbedingt sein, aber bei den Daten selbst ergibt das anders wenig Sinn.


Log in to reply