Was packt __attribute__ packed ?

[simon (Gast)]

Worin liegt der Sinn des packed atributes?

Wie wird das packen erreicht? Ist das WinZIP für Microchip? :-)

typedef char byte;

struct led_portd {
  byte b0:1;
  byte b1:1;
  byte b2:1;
  byte b3:1;
  byte b4:1;
  byte b5:1;
  byte b6:1;
  byte b7:1;
} __attribute__((packed));

[(prx) A. K. (prx)]

simon schrieb:
> Worin liegt der Sinn des packed atributes?

Weniger Platzverbrauch im RAM zu Lasten von höherem Platzverbrauch im 
ROM und höherer Laufzeit.

> Wie wird das packen erreicht? Ist das WinZIP für Microchip? :-)

Es werden zwischen den einzelnen Daten keine Löcher gelassen. So wird
 struct {
    char c;
    int  i;
 };
zwischen c und i ein 3 Byte grosses Loch gelassen. Gepackt nicht.

[simon (Gast)]

Teilweise werden hier selbst arrays von 6 byte gepackt.

Nur warum lässt der compiler hier lücken dazwischen?!
Und zu Weiviel Byte wird das ganze gepackt?

// Structure to contain a MAC address
typedef struct __attribute__((__packed__))
{
    BYTE v[6];
} MAC_ADDR;

[Johann L. (gjlayde)]

A. K. schrieb:

> Es werden zwischen den einzelnen Daten keine Löcher gelassen. So wird
>  struct {
>     char c;
>     int  i;
>  };
> zwischen c und i ein 3 Byte grosses Loch gelassen. Gepackt nicht.

Was aber vom ABI anhängt.  Ein avr-gcc macht auch ohne packed keine 
Lücke zwischen c und i.

[Simon H. (simi)]

simon schrieb:
> Nur warum lässt der compiler hier lücken dazwischen?!

Einige 32-Bit-Prozessoren (z.B. ARM7 (ARMv5), wenn ich mich richtig 
erinnere) können nur 4-byte-aliged lesen und schreiben. Bei denen wird 
natürlich dann auch die Struct so angelegt, dass jedes Byte so einen 
32-Bit-Bereich besetzt, damit direkt darauf zugegriffen werden kann.
Warum das so ist: Naja, man kann natürlich die Architektur des 
Prozessors so massiv vereinfachen.
Wenn Du Platz sparen willst, musst Du beim Zugriff auf die Datenstruktur 
die Daten jedesmal zurechtpfrümeln. Das kostet Laufzeit und ROM. Aber 
spart RAM.

[simon (Gast)]

Johann L. schrieb:
> Was aber vom ABI anhängt.  Ein avr-gcc macht auch ohne packed keine
> Lücke zwischen c und i.


Naja AVR hab ich für das Projekt sein lassen, Atxmega und es gibt keinen 
TCP Stack, wlan müsste man auch von grund auf an wieder zurecht basteln, 
das sind alles dinge die haste bei Microchip echt out of the box.

[Peter D. (peda)]

Das __attribute__((packed)) hat nur Einfluß, wenn die Elemente einer 
Struct unterschiedliche Größe haben und die kleineren zuerst stehen.

Da hier aber alle gleich groß sind (1Bit), kann man es auch weglassen.
Es ist also reine Gewohnheit, jemand hat das mal so gesehen und 
übernommen.
Beim AVR-GCC mache ich das auch so (sbit.h).

[Axel S. (a-za-z0-9)]

simon schrieb:
> Johann L. schrieb:
>> Was aber vom ABI anhängt.  Ein avr-gcc macht auch ohne packed keine
>> Lücke zwischen c und i.
>
> Naja AVR hab ich für das Projekt sein lassen ...

Das ist nicht der Punkt. Der Punkt ist, daß das Alignment von 
struct-Members vom ABI (oder platter gesagt: von der Plattform und dem 
verwendeten Compiler) abhängt.

Wenn der Compiler von vornherein kein Alignment macht, dann ist das 
"packed" Attribut ohne Funktion.


XL

[simon (Gast)]

Ich frage mich immer wieder woher man diese infos bekommt, also von 
packed hab ich in keinem C Buch je was gelesen. selbst im C18 Manual von 
Microchip ist es nicht drinne.


Habt ihr da geheime Quellen? :-)

[(prx) A. K. (prx)]

simon schrieb:
> Ich frage mich immer wieder woher man diese infos bekommt, also von
> packed hab ich in keinem C Buch je was gelesen.

Das gibts offiziell ja auch nicht. Dazu musst du ins Manual vom 
konkreten Compiler reinschauen.

http://gcc.gnu.org/onlinedocs/gcc-3.2/gcc/Type-Attributes.html

[(prx) A. K. (prx)]

Bisschen frischer: 
http://gcc.gnu.org/onlinedocs/gcc/Type-Attributes.html

[Bronco (Gast)]

simon schrieb:
> Ich frage mich immer wieder woher man diese infos bekommt, also von
> packed hab ich in keinem C Buch je was gelesen. selbst im C18 Manual von
> Microchip ist es nicht drinne.

Das hat auch erstmal nichts mit C zu tun, sondern mit der Plattform, auf 
der Du arbeitest.

Es gibt viele CPU-Architekturen, bei denen es unter Strafe verboten ist, 
mit 16/32/64-Bit-breiten Zugriffen auf ungerade Adressen zuzugreifen.
Z.B. der MSP430, der C167 und der PIC24.

Wenn man dies tut, gibt's einen Trap.
Aus diesem Grund ist es eine Hilfe des (plattform-abhängigen) 
C-Compilers, die Adressen bzw. Offsets so zu legen, daß es 
(normalerweise) nicht zu diesem Trap kommt. Wer weiß, was er tut, kann 
dieses Hilfe abschalten, indem er "packed" verwendet.
Auf einem 8-Bitter braucht man dies i.a.R. nicht, da dieser eh auf alle 
Adressen (gerade und ungerade) nur 8-Bit-breit zugreifen kann und daher 
diese Einschränkung nicht hat.