alignment, struct padding

hi,

nach welcher logik wird auf einem x86 bzw sparc
diese folgende struct auf 6 bytes aligned?

struct mystruct
{
	char a;
	short b;
	short c;
};

cu

CStoll

short können effektiver gelesen werden, wenn sie auf geraden Adressen stehen - und darum dürfte nach dem a ein Füllbyte eingefügt werden.

gilt das auch fuer alle anderen datentypen? wenn sie auf 2 hoch x boundaries sind...werden sie schneller gelesen?

cu

aha:

The following typical alignments are valid for compilers from Microsoft, Borland, and GNU when compiling for x86:

* A char (one byte) will be 1-byte aligned.
* A short (two bytes) will be 2-byte aligned.
* An int (four bytes) will be 4-byte aligned.
* A float (four bytes) will be 4-byte aligned.
* A double (eight bytes) will be 8-byte aligned on Windows and 4-byte aligned on Linux.

jetzt brauchte ich die gleiche tabelle fuer sparc...

warum wird auf 32-Bit-Systemen diese Struktur aus (char + int = 5 Byte) auf acht Byte aufgefuellt und warum nicht auf 6?

Brutus

Acht ist die nächstgrößere Zweierpotenz (2^3)

warum brauch ich hier ein pop beim msvc...ohne pop werden meine anderen structuren in anderen include files auch packed!!!

#ifdef _MSC_VER
#    pragma pack( push, packing )
#    pragma pack( 1 )
#    define PACK_STRUCT
#elif defined( __GNUC__ )
#    define PACK_STRUCT    __attribute__((packed))
#else
#    error you must byte-align these structures with the appropriate compiler directives
#endif

typedef struct Log
{
	uint32_t SecNum;
	uint32_t Entry;
	uint32_t Offset;
}Log PACK_STRUCT;

#ifdef _MSC_VER
	 #pragma pack(pop)
#endif

LordJaxom

StefanLan schrieb:

warum brauch ich hier ein pop beim msvc...ohne pop werden meine anderen structuren in anderen include files auch packed!!!

Weil #include eine reine Textersetzung ist. Der Compiler bekommt alles ab Deinem #pragma pack(1) inklusive aller nachfolgenden Includes als einen zusammenhängenden Text.

EDIT:
Natürlich bekommt er alles inklusive aller Includes als zusammenhängenden Text. Ab Deinem #pragma pack(1) ist dann aber alles packed.

ok dann ist das so gut!

was ist der unterschied zwischen:

#pragma pack(push) 
#pragma pack(1)

und

#pragma pack( push, packing )
#pragma pack( 1 )

wie kommt der compiler zum folgenden padding beim ARM processor?
http://i.cmpnet.com/ddj/ddj/images/ddj0309g/0309gf1.gif

Du meinst die padding bytes hintendran? Der ARM scheint es halt zu mögen, wenn die Göße von Objekten ein vielfaches von 4 Byte ist. Wird beim Zugriff auf ein Array einer solchen Struktur schneller sein.

pale dog

Tim schrieb:

Du meinst die padding bytes hintendran? Der ARM scheint es halt zu mögen, wenn die Göße von Objekten ein vielfaches von 4 Byte ist. Wird beim Zugriff auf ein Array einer solchen Struktur schneller sein.

...sollte beim x86 aber auch so sein, es sei denn er wird in dem sogenannten 'real mode' (16 bittig)betrieben, dann sind's 2 bytes.
btw: und wenn der ARM 'thumb' code ausführt, könnte er auch mit 2-byte alignment zufrieden sein.

pale dog schrieb:

Tim schrieb:

Du meinst die padding bytes hintendran? Der ARM scheint es halt zu mögen, wenn die Göße von Objekten ein vielfaches von 4 Byte ist. Wird beim Zugriff auf ein Array einer solchen Struktur schneller sein.

...sollte beim x86 aber auch so sein...

Ja, hat mich an der Darstellung auch gewundert.

hier der ganze artikel:
http://www.ddj.com/dept/architect/184405435;jsessionid=P42M43RMZ524QQSNDLRSKHSCJUNN2JVN?pgno=1