Re: alignment revisited
From: Thomas Matthews (Thomas_MatthewsSpamBotsSuck_at_sbcglobal.net)
Date: 01/19/05
- Next message: Mr Doppino: "Double comparison problem"
- Previous message: Joseph Turian: "Re: "array of Derived" is not a kind-of "array of Base" question"
- In reply to: puzzlecracker: "alignment revisited"
- Next in thread: puzzlecracker: "Re: alignment revisited"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 19 Jan 2005 12:01:45 GMT
puzzlecracker wrote:
>
>
>
> Please let me know if I solved these ones correctly. thx
>
>
>>struct A
>>{
>>char c;
>>short int si;
>>int j;
>> char d
>> int i;
>>};
>
>
>
> 32 bit machine:
> -----------------
> 1st block: s, si +padding = 4 bytes
> 2nd block: j = 4 bytes
> 3rd block: d+padding = 4 bytes
> 4th block: i = 4 bytes
> -----------------------------------
> TOTAL: = 16 bytes
>
> 64 bit Machine
> ----------------
> 1st block: s,si j+d = 8byte
> 2nd block i+padding = 8byte
> ------------------------------
> TOTAL: 16 bytes
No, according to my post, this is not correct.
Although it could be on some processors.
The point is that each field in the structure
must start on an aligned address. You are
compacting variables together.
Here is an answer based on:
int -- 32 bits
short int -- 16 bits
char -- 8 bits
Address data
0x0000 XX 00 00 00 -- member 'c'.
0x0004 XX XX 00 00 -- member 'si'.
0x0008 XX XX XX XX -- member 'j'.
0x000C XX 00 00 00 -- member 'd'.
0x0010 XX XX XX XX -- member 'i'.
0x0014
Where XX is a valid byte of data and 00 is a
padding byte. Total bytes: 0x14 == 20.
Note that each member takes up 32 bits regardless
of its POD type (not including floats, doubles,
or arrays).
5 members X 4 bytes per member = 20 bytes.
For 64-bit machine:
int -- 64 bits
short int -- 16 bits
char -- 8 bits
0x0000 XX 00 00 00 00 00 00 00 -- member 'c'.
0x0008 XX XX 00 00 00 00 00 00 -- member 'si'.
0x0010 XX XX XX XX XX XX XX XX -- member 'j'.
0x0018 XX 00 00 00 00 00 00 00 -- member 'd'.
0x0020 XX XX XX XX XX XX XX XX -- member 'i'.
0x0028
Total bytes: 0x28 = 40.
Each member occupies 64 bits or 8 bytes.
5 members X 8 bytes per member = 40 bytes.
If the compiler does not add padding bytes,
then you have (for 32-bit machine):
2 int members -- 2 X 32 bits == 64 bits
1 short int -- 1 X 16 bits == 16 bits
2 char -- 2 X 8 bits == 16 bits
--------
Total 96 bits
96 bits / 8 bits per byte == 12 bytes.
In summary the total space occupied in this example:
without padding: 12 bytes
with padding: 20 bytes
> 2)
>>struct B
>>{
>> int i;
>>short int si;
>> char c;
>> char d;
>> int j;
>>};
>
>
>
> 32 bit machine
> --------------
> 1st block: i = 4 bytes
> 2rd block: s1, c d = 4 bytes
> 4th block j = 4 bytes
> -----------------------------------
> TOTAL: 12 bytes
>
> 64 bit Machine
> ----------------
> 1st block: i, si c + d = 8 byte
> 2nd block j = 8 byte
> ---------------------------------
> TOTAL: = 16 bytes
Wrong. Try again, using my analysis above.
> =========================================================
>
> small question: virutal functions, regular fucntions and inline
> functions take the same space (ex: 4 bytes or 8 bytes 32 and 64 bits
> respectively)?
No. "virutal" functions may occupy one pointer to the vtable or
one pointer for each _virtual_ function, or none at all. Depends
on the compiler. The executable code, in general, does not reside
in the same area that the variables do.
> According to alignement rules: compiler is tring to fit
> as many variable (data types) as possible in each block for as long as
> it fits entirely or else adds padding... is that the correct way of
> thinking?
No, quite the opposite. If the processor requires the variables
to be aligned, the compiler will place the variable at the next
aligned address. If no alignment is required, the compiler will
place the variable at the next address.
For an ideal 32-bit processor, with padding applied, the next
address is:
next address = current address + word size;
or:
padding = word size - sizeof(member);
next address = current address + sizeof(member) + padding;
Without padding, the next address is:
next address = current address + sizeof(member);
> also, is function always represented as a pointer in a struct and
> occupies its size?
No. There are many possibilities. One possibility is that the
function exists somewhere and a pointer to the structure is
passed to the function. This does not require any additional
information in the structure.
For further information on this topic, I suggest you research
the following topics:
Compiler Theory and Design
Translators
Microprocessor layout or design
This discussion is becoming more about how the C++ language
is translated and less about the language.
See news:comp.compilers
>
>
> Thanks...
>
>
> ...Puzzlecracker!
>
--
Thomas Matthews
C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.comeaucomputing.com/learn/faq/
Other sites:
http://www.josuttis.com -- C++ STL Library book
http://www.sgi.com/tech/stl -- Standard Template Library
- Next message: Mr Doppino: "Double comparison problem"
- Previous message: Joseph Turian: "Re: "array of Derived" is not a kind-of "array of Base" question"
- In reply to: puzzlecracker: "alignment revisited"
- Next in thread: puzzlecracker: "Re: alignment revisited"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
