Gibt es eine Möglichkeit sich irgendwie einen 9bit breiten Datentyp in C zu basteln? Ich will zum Besipiel wenn ich z.B. 500+20 rechne 8 als Ergebnis habe... Ja, ich weiß ich kann das Ergebnis mit 0x1FF verUNDen. Kann ich dem irgendwie Compiler sagen das automatisch zu machen?
A. K. schrieb: > Nein, nicht in C. sollte doch mit bitfeldern gehen.
1 | struct
|
2 | {
|
3 | unsigned int x : 9; |
4 | } zahl; |
5 | |
6 | zahl.x = 500; |
7 | zahl.x += 20; |
8 | |
9 | zahl müsste jetzt 8 sein |
aber für sinnvoll halte ich das nicht.
Du kannst dir ein struct mit einem 9 Bit breiten Bitfeld basteln. Wenn Du solche Bitfelder addierst, verhalten sie sich wie von dir gewünscht (Speicher sparen wirst Du damit allerdings nicht). [edit - da ist mir einer mit derselben Idee zuvorgekommen ;)]
:
Bearbeitet durch User
Programmer schrieb: > Ja, ich weiß ich kann das Ergebnis mit 0x1FF verUNDen Dann mach das doch einfach... warum kompliziert was neues erfinden?
Peter II schrieb: > sollte doch mit bitfeldern gehen. Stimmt. > aber für sinnvoll halte ich das nicht. Ich auch nicht, es sei denn man beschränkt sich in Plattform und Compiler und weiss, was dabei rauskommt. Man sollte dabei bedenken, dass manche Compiler structs stets im Speicher halten und manche ABIs solche Returnwerte stets im Speicher statt in Registern übergeben (z.B. x86), was zu grässlichem Code führt. Ebenfalls werden big endian Maschinen die 9 Bits linksbündig anlegen. An sich ist das kein Problem, es sei denn man greift irgendwo wortweise drauf zu. Und Finger weg von volatile bitfields.
:
Bearbeitet durch User
Programmer schrieb: > Gibt es eine Möglichkeit sich irgendwie einen 9bit breiten Datentyp in C > zu basteln? Das es prinzipiell mit Bitfields ginge wurde schon geschrieben, auch das es wohl wenig sinnvoll sei. Du dürftest weder einen Geschwindigkeitsvorteil (eher Nachteil) noch einen Platzvorteil gegenüber 16 Bit haben. Also warum? Irgend welche Register, die mit 9 Bit bestückt werden müssen? Irgend welche Daten, die 9-bittig über eine serielle Leitung müssen? Dann eher mit 16 Bit Rechnen und verUNDen. Der Grund würde mich nun wirklich interessieren...
sina anargo schrieb: > warum wuerde mich hier noch interessieren? Weil die übrigen Bits im Wort zwangsläufig mit von der Partie sind, was ein wenig dem Prinzip von Bitfeldern widerspricht. Und weil das eine Stelle ist, wo man am ehesten über Fehler des Compilers stolpert.
:
Bearbeitet durch User
Programmer schrieb: > Weil es komfortabler wäre wenn der Compiler das automatisch erledigen > würde. Es wäre auch voll komfortabel wenn sich der Code von ganz alleine scheiben würde,... wo ist das problem bzw. was ist unkonfortable daran eine funktion zu schreiben wo du einen wert reinstopfst und den return wert mit 0x1ff verundest? Ich versteh das problem nicht... Alleine in der Zeit, die du gebraucht hast, diese Seite aufzurufen und deine frage zu formulieren, hättest du solch eine funktion schon fünf mal schreiben können... Das ist halt programmieren und nicht wünsch dir was. Sag "Hallo" zur echten Welt.
Auf einigen Plattformen ist ein char 9 Bit groß. Genaue Größen in Bit kann C nicht garantieren.
Christian Berger schrieb: > Genaue Größen in Bit > kann C nicht garantieren. klar kann es das. ein uint8_t ist 8bit groß.
Peter II schrieb: > Christian Berger schrieb: >> Genaue Größen in Bit >> kann C nicht garantieren. > > klar kann es das. > > ein uint8_t ist 8bit groß. Stimmt zwar seit C99: Exact-width integer types which are guaranteed to have the same number N of bits across all implementations. Aber: Included only if it is available in the implementation. Also: Wenn der Typ da ist, ist die Größe garantiert. Es wird aber nicht garantiert, dass der jeweilige Typ überhaupt existiert. Ihr habt also in gewisser Weise beide Recht.
Christian Berger schrieb: > Auf einigen Plattformen ist ein char 9 Bit groß. Gibts die wirklich noch?
A. K. schrieb: > Christian Berger schrieb: >> Auf einigen Plattformen ist ein char 9 Bit groß. > > Gibts die wirklich noch? Zum Beispiel die PDP-10, und es gibt bestimmt auch ein paar DSPs mit nicht durch 8 teilbaren Wortgrößen. Der Punkt dabei ist einfach, dass Programme in portablen C doch in aller Regel relativ lange existieren. Das hat eher gesellschaftliche Gründe. Dadurch dass C keine portable Binärdarstellung hat werden C Programme in aller Regel im Quellcode verbreitet. Screen, ein sehr populäres Programm zum Multiplexen von Terminals, gibts beispielsweise schon seit 1987, da muss man schon gut und portabel programmieren, damit sich das lange hält. Ob wir in 27 Jahren noch Rechner mit 8-Bit Bytes haben werden weiß niemand.
Christian Berger schrieb: >> Gibts die wirklich noch? > > Zum Beispiel die PDP-10, und es gibt bestimmt auch ein paar DSPs mit > nicht durch 8 teilbaren Wortgrößen. Dass es welche gab ist klar. Häufig 36-Bitter, wobei die oft mit 6-Bit Zeichen operierten, zumindest im technisch/wissenschaftlichen Umfeld. Die Frage war, ob es die heute immer noch gibt. Nicht bloss als Altmetall im Museum.
:
Bearbeitet durch User
Bitte 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.