Hallo zusammen, ich arbeite zur Zeit mit einem TriCore MCU und mir ist aufgefallen, das die Libraries für den Zugriff auf die Register Bitfelder benutzen. Nun habe ich auch hier im Forum schon einige Beiträge gefunden in denen die Leute für den Zugriff auf Speicherregister Bitfelder nutzen. Zur Frage: Ich hatte in Erinnerung, dass der Compiler bei Bitfeldern in C die Reihenfolge der Elemente verändern darf, wodurch das ganze natürlich für den Zugriff auf Register denkbar ungeeignet wäre. Hat sich da was geändert ? Gibt es Compiler Optionen, die das sicherstellen oder was muss man beachten wenn man Bitfelder benutzen möchte ?
klaus schrieb: > Ich hatte in Erinnerung, dass der Compiler bei Bitfeldern in C die > Reihenfolge der Elemente verändern darf, wodurch das ganze natürlich für > den Zugriff auf Register denkbar ungeeignet wäre. Im Prinzip: ja. Allerdings kiffen ja auch die Compilerbauer sich nicht jeden Tag zu, sondern allokieren die Bits normalerweise in der Reihenfolge, in der sie definiert werden. Maximal die Reihenfolge 0->7 oder 7->0 ist üblicherweise verschieden (wenn überhaupt) Was allerdings ein Problem sein kann: Wenn der Compilerbauer so schlau war, und Bits so durch die Gegend schiebt, dass er bei Mehrbitzugriffe nicht über Bytegrenzen hinweg arbeiten muss. > Hat sich da was > geändert ? Nein > Gibt es Compiler Optionen, die das sicherstellen Hängt vom Compiler ab. Aber erwarte dir von einem Compiler, der nicht aussschliesslich für µC-Belange entwickelt wurde, nicht allzuviel. Desktopprogrammierern ist diese Reihenfolge (so sie überhaupt Bitfelder benutzen) normalerweise schnurzegal. > oder was > muss man beachten wenn man Bitfelder benutzen möchte ? IM Grunde gar nichts. Wenn dein Compiler eine bestimmte Reihenfolge hat, und du sie kennst, benutze sie. Wenn dir das Risiko zu gross ist, dann benutze sie nicht. Rein von der Laufzeit her, bringen Bitfelder sowieso nichts. Auch ein Compiler kann nicht zaubern und muss mittels Maskierungen die Bits bei Manipulationen freischafeln. Zugegeben: Die Syntax wird mit Bitfeldern ein wenig ansehnlicher, aber das wars dann auch schon.
klaus schrieb: > Ich hatte in Erinnerung, dass der Compiler bei Bitfeldern in C die > Reihenfolge der Elemente verändern darf, wodurch das ganze natürlich für > den Zugriff auf Register denkbar ungeeignet wäre. Kann ich mich nicht dran erinnern. Richtig ist aber ohnehin, dass Bitfelder nicht universell portabel sind, entsprechende 1:1 Abbildungen von I/O-Registern also ein bestimmtes Verhalten des Compilers voraussetzen.
Danke für eure Antworten. Ich denke dann bleibe ich mal beim gewährten:
1 | #define REG (*((volatile int32u*)0xDEADBEEF)) |
:-) Viele Grüße
klaus schrieb: > Ich hatte in Erinnerung, dass der Compiler bei Bitfeldern in C die > Reihenfolge der Elemente verändern darf, ... Nein, die Reihenfolge darf er nicht ändern. Allerdings ist im Standard nicht festgelegt, in welcher Richtung die Bits nummeriert werden, sondern das hat man als implementation-defined gelassen, das heißt, dein Compiler ist verpflichtet zu dokumentieren, in welcher Reihenfolge er es implementiert. Außerdem ist im Standard festgelegt, dass aufeinanderfolgende Bitfelder auch aufeinander- folgend im Speicher stehen müssen, Lücken dürfen höchstens dann gelassen werden, wenn das nächste Bitfeld nicht mehr in die aktuelle Speicherstelle hinein passt (wobei es offen gelassen ist, um wie viele Byte es sich dabei handelt).
Hallo Jörg, hast du mir dazu mal nen Tipp: Wo kann ich den aktuellen C Standard (C99 vermute ich mal) idealerweise kostenlos herbekommen ? Viele Grüße Klaus
http://www.open-std.org/JTC1/SC22/wg14/www/docs/n1336.pdf Die genannten Bitfeld-Geschichten sind in 6.7.2.1 Structure and union specifiers beschrieben.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.