uint32_t variable byteweise füllen

[Micha (Gast)]

ich hab gerade folgendes Problemchen:

eine funktion uint8_t nextByte() liefert bei jedem Aufruf das nächste 
Byte eines Datenstroms. Vier solche Byte sollen in eine uint32_t 
Variable einsortiert werden, wobei das niedrigstwertige Byte zuerst 
kommt. Der folgende Konstrukt macht nicht was er soll:

 
uint32_t x = 0;
  for (i=0;i<4;i++) x += nextByte() << (8*i);

Kriegt man das mit einem Cast hin? Bräuchte da mal einen Anschubser wie 
die Sytax ausschaut.

[Andreas R. (andreasr)]

uint32_t x = 0;
for (i = 0; i < 4; i++)
{
    x >>= 8;
    x |= ((uint32_t)nextByte()) << 24;
}

[Eric B. (beric)]

Micha schrieb:
> ich hab gerade folgendes Problemchen:
>
> eine funktion uint8_t nextByte() liefert bei jedem Aufruf das nächste
> Byte eines Datenstroms. Vier solche Byte sollen in eine uint32_t
> Variable einsortiert werden, wobei das niedrigstwertige Byte zuerst
> kommt.

uint32_t x = 0;

// LSB first
for(i = 0; i < 4; i++) {
  x >>= 8;
  x += (uint32_t) nextByte() << 24;
}

// MSB first
for(i = 0; i < 4; i++) {
  x <<= 8;
  x += (uint32_t) nextByte();
}

EDIT: Heh, Andreas war schneller :-)

[Karl H. (kbuchegg)]

Micha schrieb:

> kommt. Der folgende Konstrukt macht nicht was er soll:

> x += nextByte() << (8*i);

Das dein x ein uint32_t ist, interessiert den Compiler nicht, wenn er 
das Ergebnis von nextByte um eine gewisse Anzahl Stellen nach links 
verschiebt.

Da nextByte() wohl einen uin8_t liefern wird, ist das daher eine int 
Rechnung, d.h. 16 Bit.

    x += (uint32_t)nextByte() << (8*i);

Du musst dir eines merken.
Wenn du eine Berechnung dergestalt hast

  ergebnis = Ausdruck;

dann ist der Datentyp von 'ergebnis' völlig uninteressant, wenn es darum 
geht zu bestimmen, mit welchen Operationen (Bitlänge) 'Ausdruck' 
ausgewertet wird. Bei Operationen wie + - * / sind einzig und alleine 
die Datentypen der beteiligten Operanden

   ergebnis = a * b;

a bzw. b ausschlaggebend, ob das eine 16 Bit oder eine 32 Bit 
Multiplikation ist. Erst das Ergebnis des kompletten Ausdrucks wird dann 
ganz zum Schluss an den Datentyp angepasst, so dass er an 'ergebnis' 
zuweisbar ist. Bei Schiebeoperationen

   ergebnis = a << 4;

ist dann sogar lediglich der Datentyp von a dafür massgeblich, ob da 16 
Bit oder 32 Bit geschoben wird und das Ergebnis daher dann den 
entsprechenden Datentyp hat.

> Bräuchte da mal einen Anschubser
Was du brauchst, ist das Durcharbeiten eines C-Buchs.

[Andreas R. (andreasr)]

> EDIT: Heh, Andreas war schneller :-)

Aber im Prinzip der gleiche Code ;-)

[Pointeruser (Gast)]

#include <stdio.h>

uint8_t   byteval[4] = {0x11, 0x22, 0x33, 0x44};
int16_t   ii;
uint32_t  word32;

int main (void)
{
  word32 = 0;
  for (ii=0; ii<4; ii++)
  {
    *(((uint8_t*)&word32)+ii) = byteval[ii];
  }
}

[Pit (Gast)]

Pointeruser schrieb:
> #include <stdio.h>
>
> uint8_t   byteval[4] = {0x11, 0x22, 0x33, 0x44};
> int16_t   ii;
> uint32_t  word32;
>
> int main (void)
> {
>   word32 = 0;
>   for (ii=0; ii<4; ii++)
>   {
>     *(((uint8_t*)&word32)+ii) = byteval[ii];
>   }
> }

Schönes Beispiel, dass man Pointer nur einsetzen soll, wenn man ihn auch 
wirklich benötigt.

[Dr. Sommer (Gast)]

Pointeruser schrieb:
> #include <stdio.h>
>
> uint8_t   byteval[4] = {0x11, 0x22, 0x33, 0x44};
> int16_t   ii;
> uint32_t  word32;
>
> int main (void)
> {
>   word32 = 0;
>   for (ii=0; ii<4; ii++)
>   {
>     *(((uint8_t*)&word32)+ii) = byteval[ii];
>   }
> }

Hier wie üblich das Problem, dass C(++) nicht definiert was das Ergebnis 
ist; word32 kann danach zB 0x11223344 oder auch 0x44332211 enthalten.
Warum eine so temporäre Variable wie "ii" global sein muss ist auch 
nicht ganz klar.
Die zuerst geposteten Antworten von Eric bzw. Andreas sind wesentlich 
besser, weil hier das Ergebnis klar ist.

[Micha (Gast)]

Vielen Dank für alle Antworten!
Ja, ich sollte mir wohl vom Osterhasen ein C Buch wünschen - falls nicht 
schon zu spät ;-)

Das mit der Pointerei war mir auch schon durch den Kopf gegangen. Das 
hat was, aber da kommt wie angedeutet zusätzlich die Frage ins Spiel, ob 
die uint32_t Variable nun auf dem konkreten System little oder big 
endian ist. Hab grade gegoogelt - beim 8-Bit AVR müsste es so passen, 
der ist little endian...

[Pointeruser (Gast)]

Dr. Sommer schrieb:
> Hier wie üblich das Problem, dass C(++) nicht definiert was das Ergebnis
> ist; word32 kann danach zB 0x11223344 oder auch 0x44332211 enthalten.

Ich denke wir reden hier über AVR code, das sollte die
Endianess klar sein.

Dr. Sommer schrieb:
> Warum eine so temporäre Variable wie "ii" global sein muss ist auch
> nicht ganz klar.

Wer hier Korinthen kacken will darf das.

[Dr. Sommer (Gast)]

Ich verstehe nicht, warum die schlechte Lösung mit Pointern oder gar 
unions so populär ist. Man könnte sich alle Gedanken über 
Little/Big-Endian und Portierbarkeit sparen wenn man einfach Bitshifts 
(wie Eric und Andreas) verwendet. Warum würdem an auf die Idee kommen so 
etwas mit Pointer umcasten zu machen?

[Pointeruser (Gast)]

Hallo Korinthenkacker,

wer hat hier was von Portierbarkeit gewünscht oder gesprochen?

Welche Eigenschaften muss ein C-Sourcecode haben dass er
"schlecht" oder "gut" ist?

[Dr. Sommer (Gast)]

Hallo Pointerfrickler,

du bist natürlich frei beliebig schlechten Code zu schreiben. Allerdings 
sollte man als "guter" Programmierer es sich angewöhnen, grundsätzlich 
korrekten und portierbaren Code zu schreiben, denn dann macht man es 
automatisch richtig wenn es drauf ankommt. Das gilt insbesondere für 
Fälle, in denen die korrekte Lösung in jeder Hinsicht besser ist und 
noch nicht einmal länger oder komplizierter.
Du kannst natürlich auch grundsätzlich Auto fahren ohne dich 
anzuschnallen, und wenn du nur in 10km/h-Zonen fährst macht das 
vielleicht auch nichts, aber es ist dennoch allgemein eine gute Idee 
sich sicher zu gehen. Vielleicht fährt man ja doch mal auf der Autobahn.

Es gibt viele Kriterien für guten oder schlechten Code. Ein Kriterium 
für guten Code ist auf jeden Fall dass er korrekt ist und der Standard 
ein definiertes Ergebnis garantiert.

[Eric B. (beric)]

Dr. Sommer schrieb:
> Ich verstehe nicht, warum die schlechte Lösung mit Pointern oder gar
> unions so populär ist. Man könnte sich alle Gedanken über
> Little/Big-Endian und Portierbarkeit sparen wenn man einfach Bitshifts
> (wie Eric und Andreas) verwendet. Warum würde man auf die Idee kommen so
> etwas mit Pointer umcasten zu machen?

Weil man sich dann eben die Bitshifterei sparen kann. Auf einem 8-bit 
Architektur wo es nur ein OpCode gibt um ein Byte um ein Bit nach links 
oder rechts zu schieben, kann das dann schon "lange" dauern.

[Peter II (Gast)]

Eric B. schrieb:
> Weil man sich dann eben die Bitshifterei sparen kann. Auf einem 8-bit
> Architektur wo es nur ein OpCode gibt um ein Byte um ein Bit nach links
> oder rechts zu schieben, kann das dann schon "lange" dauern.

der Compiler ist aber auch nicht so dumm und schiftet um 8bit.

[Eric B. (beric)]

Peter II schrieb:
> Eric B. schrieb:
>> Weil man sich dann eben die Bitshifterei sparen kann. Auf einem 8-bit
>> Architektur wo es nur ein OpCode gibt um ein Byte um ein Bit nach links
>> oder rechts zu schieben, kann das dann schon "lange" dauern.
>
> der Compiler ist aber auch nicht so dumm und schiftet um 8bit.

:-) Und rollt auch sofort die for-Schleife aus:

  x  = (uint32) readByte();
  x |= (uint32) readByte() << 8;
  x |= (uint32) readByte() << 16;
  x |= (uint32) readByte() << 24;

[Micha (Gast)]

Peter II schrieb:
> der Compiler ist aber auch nicht so dumm und schiftet um 8bit.
der Compiler shiftet an der Stelle eher gar nichts, würde ich sagen

[Frank M. (ukw) (Moderator)]

Pointeruser schrieb:
> wer hat hier was von Portierbarkeit gewünscht oder gesprochen?

Du wirst auch noch im Laufe der Jahre lernen, dass ein gut portierbarer 
Code sehr wichtig ist. Warum? Die Prozessoren entwickeln sich weiter und 
es kommen laufend neue hinzu. Auch Du wirst in 30 Jahren keine ATTinys 
mehr programmieren - einfach, weil es sie nicht mehr gibt und längst 
durch andere Generationen ersetzt worden sind.

Deine Programme aber können solche Prozessor-Sprünge weitestgehend 
überleben - nämlich dann, wenn Du JETZT schon mitdenkst.

Nichts ist schlimmer als solche Stellen wie oben in einem größeren 
Projekt allesamt nachflicken zu müssen, weil derjenige, der den Code 
verzapft hat, so kleingeistig war, dass er Blicke über den Tellerrand 
nie zu wagen gedachte.

> Welche Eigenschaften muss ein C-Sourcecode haben dass er
> "schlecht" oder "gut" ist?

Portabler Code: Gut
Lesbarer Code: Gut

Unlesbarer Code: Schlecht
Unportabler Code: Ganz schlecht

So einfach ist das.

[WS (Gast)]

typedef union {
    char  c[4];
    short i16[2];
    long  i32;
} ltyp;


etc.

WS

[Dr. Sommer (Gast)]

WS schrieb:
> typedef union {
>     char  c[4];
>     short i16[2];
>     long  i32;
> } ltyp;
>
> etc.
>
> WS
Auch hier gilt das gleiche wie für die Pointer-Version: Das Ergebnis ist 
undefiniert. Noch schlimmer, es wurden die Typen char, short, long 
verwendet, und die müssen keineswegs 8/16/32 Bit-Typen entsprechen; long 
kann zB 64bit groß sein...

Micha schrieb:
> Peter II schrieb:
>> der Compiler ist aber auch nicht so dumm und schiftet um 8bit.
> der Compiler shiftet an der Stelle eher gar nichts, würde ich sagen
Es war natürlich der erzeugte Code gemeint. Und ja, Compiler optimieren 
die Bitshifts natürlich weg, sodass der erzeugte Code mindestens so 
effizient ist wie die Pointer-Version. Wahrscheinlich sogar noch 
effizienter, da er so komplett mit Registern arbeiten kann, während die 
Pointer-Version ein Ablegen im Speicher erfordert (falls der Compiler 
das nicht auch "sieht")...

[Pointeruser (Gast)]

Dr. Sommer schrieb:
> Und ja, Compiler optimieren
> die Bitshifts natürlich weg, sodass der erzeugte Code mindestens so
> effizient ist wie die Pointer-Version.

Leider kann ein Compiler der 8-Bit Code erzeugen muss, Shift-
Operationen nicht über Byte-Grenzen hinweg optimieren. Somoit
zerfällt eine Shift-Operation einer 32 Bit Variablen zwangsläufig
in 3 bis 4 Stufen.

Was Zufolge hat dass die Version mit Pointern in jeder Optimierungs-
stufe weniger Code erzeugt und damit auch schneller ist als die
Version mit Shift-Operationen. Ich bin keiner der hier den
Geschwindigkeits-Wahn hat, aber viele bringen in so einer Diskussion
dieses Argument wenn es um den "besseren" Code geht.

Wer es nicht glauben will der kann es ja selbst am HeimStudio
ausprobieren / nachvollziehen.

Soviel zu Korinthenkackers Aussage "mindestens so effizient wie..."

[Dr. Sommer (Gast)]

Der herr Pointerfrickler hat sogar teilweise Recht, der AVR-GCC ist zu 
blöd die 32bit-Shiftoperationen korrekt zu optimieren. Da die 
Pointer-Cast-Operation aber Stack-Zugriff erfordert, ist sie tatsächlich 
noch langsamer und größer. Hier der Testcode:

uint32_t foo () {
  uint8_t bytes [4] = { nextByte (), nextByte (), nextByte (), nextByte () };
  
  return  ((((uint32_t) bytes [0]) & 0xFF))
    |  ((((uint32_t) bytes [1]) & 0xFF) << 8)
    |  ((((uint32_t) bytes [2]) & 0xFF) << 16)
    |  ((((uint32_t) bytes [3]) & 0xFF) << 24);
}

uint32_t bar () {
  uint32_t x = 0;
  ((uint8_t*) &x) [0] = nextByte ();
  ((uint8_t*) &x) [1] = nextByte ();
  ((uint8_t*) &x) [2] = nextByte ();
  ((uint8_t*) &x) [3] = nextByte ();
  return x;
}

auf dem ATmega88 braucht die erste Version 39 Takte, und die Zweite 60. 
Außerdem ist die erste Version 6 Bytes kleiner.

Hier der Assemblercode mit drangeschriebenen Taktzahlen:

0000004c <foo>:
  4c:  1f 93         push  r17                  2
  4e:  cf 93         push  r28                  2
  50:  df 93         push  r29                  2
  52:  f9 df         rcall  .-14       ; 0x46 <nextByte>    3
  54:  c8 2f         mov  r28, r24                1
  56:  f7 df         rcall  .-18       ; 0x46 <nextByte>    3
  58:  d8 2f         mov  r29, r24                1
  5a:  f5 df         rcall  .-22       ; 0x46 <nextByte>    3
  5c:  18 2f         mov  r17, r24                1
  5e:  f3 df         rcall  .-26       ; 0x46 <nextByte>    3
  60:  41 2f         mov  r20, r17                1
  62:  50 e0         ldi  r21, 0x00  ; 0              1
  64:  60 e0         ldi  r22, 0x00  ; 0              1
  66:  70 e0         ldi  r23, 0x00  ; 0              1
  68:  ba 01         movw  r22, r20              1
  6a:  55 27         eor  r21, r21                1
  6c:  44 27         eor  r20, r20                1
  6e:  5d 2b         or  r21, r29                1
  70:  4c 2b         or  r20, r28                1
  72:  78 2b         or  r23, r24                1
  74:  cb 01         movw  r24, r22              1
  76:  ba 01         movw  r22, r20              1
  78:  df 91         pop  r29                    2
  7a:  cf 91         pop  r28                    2
  7c:  1f 91         pop  r17                    2
  7e:  08 95         ret

00000080 <bar>:
  80:  cf 93         push  r28                    2
  82:  df 93         push  r29                    2
  84:  00 d0         rcall  .+0        ; 0x86 <bar+0x6>      3
  86:  00 d0         rcall  .+0        ; 0x88 <bar+0x8>      3
  88:  cd b7         in  r28, 0x3d  ; 61              1
  8a:  de b7         in  r29, 0x3e  ; 62              1
  8c:  19 82         std  Y+1, r1  ; 0x01                2
  8e:  1a 82         std  Y+2, r1  ; 0x02                2
  90:  1b 82         std  Y+3, r1  ; 0x03                2
  92:  1c 82         std  Y+4, r1  ; 0x04                2
  94:  d8 df         rcall  .-80       ; 0x46 <nextByte>      3
  96:  89 83         std  Y+1, r24  ; 0x01              2
  98:  d6 df         rcall  .-84       ; 0x46 <nextByte>      3
  9a:  8a 83         std  Y+2, r24  ; 0x02              2
  9c:  d4 df         rcall  .-88       ; 0x46 <nextByte>      3
  9e:  8b 83         std  Y+3, r24  ; 0x03              2
  a0:  d2 df         rcall  .-92       ; 0x46 <nextByte>      3
  a2:  8c 83         std  Y+4, r24  ; 0x04              2
  a4:  69 81         ldd  r22, Y+1  ; 0x01              2
  a6:  7a 81         ldd  r23, Y+2  ; 0x02              2
  a8:  8b 81         ldd  r24, Y+3  ; 0x03              2
  aa:  9c 81         ldd  r25, Y+4  ; 0x04              2
  ac:  0f 90         pop  r0                      2
  ae:  0f 90         pop  r0                      2
  b0:  0f 90         pop  r0                      2
  b2:  0f 90         pop  r0                      2
  b4:  df 91         pop  r29                      2
  b6:  cf 91         pop  r28                      2
  b8:  08 95         ret

Just for Fun hier der selbe Code für ARMv7M kompiliert:

00000000 <foo>:
   0:  b570        push  {r4, r5, r6, lr}      5
   2:  f7ff fffe   bl  0 <nextByte>          1
   6:  4605        mov  r5, r0              1
   8:  f7ff fffe   bl  0 <nextByte>          1
   c:  4606        mov  r6, r0              1
   e:  f7ff fffe   bl  0 <nextByte>          1
  12:  4604        mov  r4, r0              1
  14:  0424        lsls  r4, r4, #16          1
  16:  f7ff fffe   bl  0 <nextByte>          1
  1a:  ea44 2406   orr.w  r4, r4, r6, lsl #8      1
  1e:  432c        orrs  r4, r5            1
  20:  ea44 6000   orr.w  r0, r4, r0, lsl #24      1
  24:  bd70        pop  {r4, r5, r6, pc}        5
  26:  bf00        nop
21

00000028 <bar>:
  28:  b500        push  {lr}            2
  2a:  b083        sub  sp, #12              1
  2c:  2300        movs  r3, #0            1
  2e:  9301        str  r3, [sp, #4]          2
  30:  f7ff fffe   bl  0 <nextByte>          1
  34:  f88d 0004   strb.w  r0, [sp, #4]        2
  38:  f7ff fffe   bl  0 <nextByte>          1
  3c:  f88d 0005   strb.w  r0, [sp, #5]        2
  40:  f7ff fffe   bl  0 <nextByte>          1
  44:  f88d 0006   strb.w  r0, [sp, #6]        2
  48:  f7ff fffe   bl  0 <nextByte>          1
  4c:  f88d 0007   strb.w  r0, [sp, #7]        2
  50:  9801        ldr  r0, [sp, #4]          2
  52:  b003        add  sp, #12              1
  54:  f85d fb04   ldr.w  pc, [sp], #4        2

Hier braucht die 1. Version 21 Takte und die 2. braucht 23 (bei den 
Pipeline-relevanten Instruktionen jeweils Best Case angenommen - im 
Worst case ist die Pointer-Version noch schlechter). Die 2. Version ist 
8 Bytes größer.

Soviel zu Pointerfricklers Aussage, dass die Pointer-Version irgendeinen 
Vorteil hätte. Vielleicht doch mal die Aussagen mit Fakten belegen?