C -> Bitfeld

OP #6042590
Lesenswert?

Guten Morgen,

wenn ich jetzt ein Bitfeld habe
1
typedef struct
2
{
3
  uint8_t bStepperActive  :1; // Schrittmotoren sind aktiv (beide)
4
  uint8_t bStepperAutoOff :1; // Automatische Motorabschaltung nach Zeit
5
  uint8_t bButtonStart  :1; // Start wurde gedrückt
6
  uint8_t bChangeRotation  :1; // Richtung wurde geändert
7
  uint8_t bRotation    :1; // 0 = links (default) , 1 = rechts
8
}sFlags_t;

Kann ich davon ausgehen das z.B "bStepperActive" immer das erste Bit im 
"Byte" ist?
Sprich das der erste Eintrag in diesem Fall "bStepperActive" immer das 
erste Bit ist..
Gast #6042601
Lesenswert?

> Kann ich davon ausgehen das z.B "bStepperActive" immer das erste Bit
> im "Byte" ist?

Nicht vom C-Standard her - der schreibt keine Reihenfolge vor.  Wovon du 
allerdings ausgehen kannst, ist, dass ein bestimmter Compiler immer die 
gleiche Reihenfolge verwendet.
Gast #6042632
Lesenswert?

Die Idee ist doch sicher Binärdaten auf irgendeiner Schnittstelle zu 
empfangen und die Auswertung statt mit Hilfe der üblichen Bitschubserei 
elegant durch das Lesen/Schreiben der Felder im Bitfield zu erledigen.

Die Idee hatten schon viele zuvor und alle sind zur selben ernüchternden 
Erkentnis gelangt, dass dieser Code schlecht wartbar und unportierbar 
wird.
Gast #6042649
Lesenswert?

foobar schrieb:
> Nicht vom C-Standard her - der schreibt keine Reihenfolge vor.  Wovon du
> allerdings ausgehen kannst, ist, dass ein bestimmter Compiler immer die
> gleiche Reihenfolge verwendet.

Wobei "bestimmter Compiler" sehr eng zu sehen ist. Ich hatte schon mal 
den Brüller, dass bei einem Update des Compilers die Reihenfolge sich 
umdrehte.

Es soll ja auch Compiler geben, die per Kommandozeilenargument oder 
Pragma Anweisung da was drehen. Hölle, wenn man 2 fremde Bibliotheken 
einbinden muss, die das unterschiedlich handhaben.
#6042659
Lesenswert?

fop schrieb:
> Wobei "bestimmter Compiler" sehr eng zu sehen ist. Ich hatte schon mal
> den Brüller, dass bei einem Update des Compilers die Reihenfolge sich
> umdrehte.

Um welchen Prozessor ging es dabei? Man kann sowas nämlich auch in 
Hardware falsch machen, um das später zu korrigieren.

Motorola hatte sich auf Befehlsebene ins Knie geschossen, weshalb die 
Einzelbitbefehle der 68000 von rechts nach links adressierten, die mit 
68020 hinzu gekommenen Bitfeldbefehle aber von links nach rechts.

> Es soll ja auch Compiler geben, die per Kommandozeilenargument oder
> Pragma Anweisung da was drehen.

Die Anordnung von Bitfeldern orientiert sich sinnvollerweise nicht an 
der offiziellen Bitreihenfolge des Prozessors, sondern an dessen 
Bytereihenfolge. Also ob das obere oder das untere Byte eines Wortes im 
Speicher adressiert wird. Es gibt allerdings Architekturen, bei denen 
diese Bytereihenfolge erst im Rahmen der Systemimplementierung 
festgelegt wird. Weshalb Compiler flexibel sein müssen.

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren