Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > structure padding

Reply
Thread Tools

structure padding

 
 
ramu
Guest
Posts: n/a
 
      02-02-2006
Hi all,
I understand that some compilers pad some bytes to the
aggregate data types in order to access the members of the aggregate
data types(i.e. structure) fast. This depends on the architectures.
Some architectures cannot access the data which will be stored on the
odd addresses or they may find difficult to access it. This is the
reason for padding extra bytes.

Now consider the following structure:

struct {
int i; // 4 bytes
char c; // 1 byte
char b; // 1 byte
}a;

Now consider the memory representation for this structure:

----------------------------- Memory locations
i 0
-----------------------------
i 1
-----------------------------
i 2
------------------------------
i 3
-------------------------------
c 4
--------------------------------
b 5
--------------------------------
padding 6
---------------------------------
padding 7
---------------------------------

The size of this strucutre will be 8bytes after padding.
The first 4 memory locations(0 to 3) are allocated for int i;
The next byte(4) is allocated for char c;
the next byte(5) is allocated for char b;

Now my doubt is , does not the processor find it difficult to access
the value of the variable which is stored in odd memory location(ie.
5)? can anyone elaborate on this?

Regards

 
Reply With Quote
 
 
 
 
Vladimir S. Oka
Guest
Posts: n/a
 
      02-02-2006
ramu wrote:

> Hi all,
> I understand that some compilers pad some bytes to the
> aggregate data types in order to access the members of the aggregate
> data types(i.e. structure) fast. This depends on the architectures.
> Some architectures cannot access the data which will be stored on the
> odd addresses or they may find difficult to access it. This is the
> reason for padding extra bytes.


This is off topic here.

> Now consider the following structure:
>
> struct {
> int i; // 4 bytes
> char c; // 1 byte
> char b; // 1 byte
> }a;
>
> Now consider the memory representation for this structure:


< snip >

<OT>
If such a padding is to take place, it's more likely that both `c` and
`d` will `occupy` a 4-byte memory block, or whichever block is
convenient for the implementation.
</OT>

Cheers

Vladimir

--
"Stealing a rhinoceros should not be attempted lightly."

 
Reply With Quote
 
 
 
 
santosh
Guest
Posts: n/a
 
      02-02-2006
In 32 - bit processors , Each bus cycle will access the 32 - bit data
from memory. For reading variable b, first the processor reads the
entire 32 bit word which includes b, c and the padded data.

This is the reason why padding is required. (it is required for
allignment).

 
Reply With Quote
 
Nelu
Guest
Posts: n/a
 
      02-02-2006
santosh wrote:
> In 32 - bit processors , Each bus cycle will access the 32 - bit data
> from memory. For reading variable b, first the processor reads the
> entire 32 bit word which includes b, c and the padded data.
>
> This is the reason why padding is required. (it is required for
> allignment).
>

Before posting again, please read:
http://cfaj.freeshell.org/google/

Thank you.

--
Ioan - Ciprian Tandau
tandau _at_ freeshell _dot_ org (hope it's not too late)
(... and that it still works...)
 
Reply With Quote
 
Rod Pemberton
Guest
Posts: n/a
 
      02-02-2006

"ramu" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) ups.com...
> Hi all,
> I understand that some compilers pad some bytes to the
> aggregate data types in order to access the members of the aggregate
> data types(i.e. structure) fast. This depends on the architectures.
> Some architectures cannot access the data which will be stored on the
> odd addresses or they may find difficult to access it. This is the
> reason for padding extra bytes.
>
> Now consider the following structure:
>
> struct {
> int i; // 4 bytes
> char c; // 1 byte
> char b; // 1 byte
> }a;
>


Okay. Layout can be compiler specific.

> Now my doubt is , does not the processor find it difficult to access
> the value of the variable which is stored in odd memory location(ie.
> 5)? can anyone elaborate on this?


No idea. The code generate by DJGPP and OW are radically different. You'll
need to study the disassembly.


If you want to see the exact layout of a structure with different packings,
you can play with this code:

#include <stdio.h>

// Works for DJGPP 2.03 and OW 1.3
#ifdef __DJGPP__
#define HANDLE_PRAGMA_PACK_PUSH_POP 1
#endif

// default alignment
struct {
unsigned int i;
unsigned char c;
unsigned long a;
unsigned short e;
unsigned char b;
} s0;

#pragma pack(push,1)
struct {
unsigned int i;
unsigned char c;
unsigned long a;
unsigned short e;
unsigned char b;
} s1;
#pragma pack(pop)

#pragma pack(push,2)
struct {
unsigned int i;
unsigned char c;
unsigned long a;
unsigned short e;
unsigned char b;
} s2;
#pragma pack(pop)

#pragma pack(push,4)
struct {
unsigned int i;
unsigned char c;
unsigned long a;
unsigned short e;
unsigned char b;
} s3;
#pragma pack(pop)


void print_s(unsigned char *s, int size)
{
int i;

printf("%d ",size);
for(i=0;i<size;i++)
{
printf("%02x ",s[i]);
}
printf("\n");
}

int main(void)
{
s0.i=(unsigned int)0xF0F1F2F3; // cast in case 16 not 32
s0.a=(unsigned long)0xE0E1E2E3; // cast in case 16 not 32
s0.e=(unsigned short)0xD0D1D2D3; // cast in case 16 not 32
s0.c=0xFC;
s0.b=0xFE;

s1.i=(unsigned int)0xF0F1F2F3; // cast in case 16 not 32
s1.a=(unsigned long)0xE0E1E2E3; // cast in case 16 not 32
s1.e=(unsigned short)0xD0D1D2D3; // cast in case 16 not 32
s1.c=0xFC;
s1.b=0xFE;

s2.i=(unsigned int)0xF0F1F2F3; // cast in case 16 not 32
s2.a=(unsigned long)0xE0E1E2E3; // cast in case 16 not 32
s2.e=(unsigned short)0xD0D1D2D3; // cast in case 16 not 32
s2.c=0xFC;
s2.b=0xFE;

s3.i=(unsigned int)0xF0F1F2F3; // cast in case 16 not 32
s3.a=(unsigned long)0xE0E1E2E3; // cast in case 16 not 32
s3.e=(unsigned short)0xD0D1D2D3; // cast in case 16 not 32
s3.c=0xFC;
s3.b=0xFE;

printf("s0 ");
print_s((unsigned char *)&s0,sizeof(s0));
printf("s1 ");
print_s((unsigned char *)&s1,sizeof(s1));
printf("s2 ");
print_s((unsigned char *)&s2,sizeof(s2));
printf("s3 ");
print_s((unsigned char *)&s3,sizeof(s3));

return(0);
}


Rod Pemberton


 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      02-02-2006
santosh wrote:
> In 32 - bit processors , Each bus cycle will access the 32 - bit data
> from memory. For reading variable b, first the processor reads the
> entire 32 bit word which includes b, c and the padded data.
>
> This is the reason why padding is required. (it is required for
> allignment).
>

It isn't required (but is desirable) on processors that can perform
misaligned access.

Alignment is very implementation specific and can be a compatibility
headache if code assumes a certain alignment.

--
Ian Collins.
 
Reply With Quote
 
santosh
Guest
Posts: n/a
 
      02-02-2006
I dint know that.
Thanks.


Nelu wrote:
> santosh wrote:
> > In 32 - bit processors , Each bus cycle will access the 32 - bit data
> > from memory. For reading variable b, first the processor reads the
> > entire 32 bit word which includes b, c and the padded data.
> >
> > This is the reason why padding is required. (it is required for
> > allignment).
> >

> Before posting again, please read:
> http://cfaj.freeshell.org/google/
>
> Thank you.
>
> --
> Ioan - Ciprian Tandau
> tandau _at_ freeshell _dot_ org (hope it's not too late)
> (... and that it still works...)


 
Reply With Quote
 
Vladimir S. Oka
Guest
Posts: n/a
 
      02-02-2006
santosh wrote:
> Nelu wrote:
> > santosh wrote:
> > > In 32 - bit processors , Each bus cycle will access the 32 - bit data
> > > from memory. For reading variable b, first the processor reads the
> > > entire 32 bit word which includes b, c and the padded data.
> > >
> > > This is the reason why padding is required. (it is required for
> > > allignment).
> > >

> > Before posting again, please read:
> > http://cfaj.freeshell.org/google/

>
> I dint know that.


I believe it also says something about top-posting (I corrected yours
here), and possibly even about not quoting signatures.

Cheers

Vladimir

 
Reply With Quote
 
Robin Haigh
Guest
Posts: n/a
 
      02-02-2006

"ramu" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) ups.com...
> Hi all,
> I understand that some compilers pad some bytes to the
> aggregate data types in order to access the members of the aggregate
> data types(i.e. structure) fast. This depends on the architectures.
> Some architectures cannot access the data which will be stored on the
> odd addresses or they may find difficult to access it. This is the
> reason for padding extra bytes.
>
> Now consider the following structure:
>
> struct {
> int i; // 4 bytes
> char c; // 1 byte
> char b; // 1 byte
> }a;
>
> [snip]
>
> The size of this strucutre will be 8bytes after padding.
> The first 4 memory locations(0 to 3) are allocated for int i;
> The next byte(4) is allocated for char c;
> the next byte(5) is allocated for char b;
>
> Now my doubt is , does not the processor find it difficult to access
> the value of the variable which is stored in odd memory location(ie.
> 5)? can anyone elaborate on this?



Alignment is a problem when objects lie across boundaries, requiring
multiple fetches if they can be fetched at all.

The types which are smaller than a word never straddle a boundary. They
were provided in C so that you can pack more than one item into a word. The
unpacking overhead should be relatively minor, but if you're worried, you
can always store your characters in ints. That's your choice: if you choose
the "packable" type, it's not the compiler's job to change your mind.

--
RSH


 
Reply With Quote
 
Richard Bos
Guest
Posts: n/a
 
      02-02-2006
"Vladimir S. Oka" <(E-Mail Removed)> wrote:

> ramu wrote:
>
> > I understand that some compilers pad some bytes to the
> > aggregate data types in order to access the members of the aggregate
> > data types(i.e. structure) fast. This depends on the architectures.
> > Some architectures cannot access the data which will be stored on the
> > odd addresses or they may find difficult to access it. This is the
> > reason for padding extra bytes.

>
> This is off topic here.


Not really. That certain types may require alignments, and that
structures may contain padding for that and other reasons, is perfectly
Standard. Which types happen to require padding on a specific
implementation, and how much, that's off topic here. The principle
itself, though, is on topic.

> > Now consider the following structure:
> >
> > struct {
> > int i; // 4 bytes
> > char c; // 1 byte
> > char b; // 1 byte
> > }a;
> >
> > Now consider the memory representation for this structure:

>
> < snip >
>
> <OT>
> If such a padding is to take place, it's more likely that both `c` and
> `d` will `occupy` a 4-byte memory block, or whichever block is
> convenient for the implementation.


Not necessarily. One thing is certain, though: if normal ints aren't
just 4 bytes large, but also require 4-byte alignment, the
implementation must make certain that no ints, including the one in the
second member of an array of these structs, break alignment. Of course
it's possible for the implementation to fudge this in the background by
accessing all struct-member ints as arrays of char, but the best and
perfectly Standard way would be to make the whole struct take 8 bytes: 4
for the int, 1 each for the chars, and 2 for padding to make sure the
next int also ends up on a well-aligned memory address.

Richard
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Size of a structure : Structure Padding Kislay C Programming 15 07-13-2011 04:24 AM
structure padding Stephen Mayes C Programming 5 05-31-2005 03:49 AM
padding between variables in a structure junky_fellow@yahoo.co.in C Programming 6 05-18-2005 08:06 AM
structure padding phoenix C Programming 1 03-11-2005 04:21 AM
Structure padding. Amarendra C Programming 13 06-22-2004 07:59 AM



Advertisments