Benno wrote:
On Sat Oct 01, 2005 at 18:23:40 +1000, O Plameras wrote:
Matthew Hannigan wrote:
On Fri, Sep 30, 2005 at 10:09:40AM +1000, O Plameras wrote:
.... and as C is closely bound
to hardware architecture you must have said something about these data
Actually, C is not necessarily that closely bound to hardware architecture.
The the following C program illustrates the relationship of C and
hardware architecture on
16-bit and 32-bit (Two different architectures). We cannot use 32-bit
and 64-bit (AMD) to
illustrate because the int size are the same in both. This is an
aberration for AMD CPUs, I
think.
Many documentations says that a 64-bit should really have int size=8
instead of 4
(see http://www.osdata.com/topic/language/asm/datarep.htm
-DEC VAX *16* *bit* [2 *byte*] *word*; 32 bit [4 *byte*] longword; 64
bit [8 *byte*]quadword;
132 bit [16 *byte*] octaword; data may be unaligned at a speed penalty *...*
)
There are other documentations similar to the above assertions on the net.
It depends on the architecture ABI. As others have shown AMD64, Itanium, (and
I'm
pretty sure power5) architectures use 32-bit ints. Otehr 64-bit architectures
may choose differently.
But check the C-codes.
#include <stdio.h>
struct verify {
char initials[2];
int birthdate;
};
int main(void)
{
struct verify holes;
printf ("%d\n", sizeof(holes.initials[0]));
printf ("%d\n", sizeof(holes.initials));
printf ("%d\n", sizeof(holes.birthdate));
printf ("%d\n", sizeof(holes));
return 0;
}
Given that the word-byte
In 16-bit computer = 2 bytes word the output is,
1
2
2
4
in 32-bit computer = 4 bytes word the output is,
1
2
4
8
Two things are different due to computer architecture.
1. The same struct have different memory sizes allocated.
Yep.
2. The struct has no hole in 16-bit and has 2-byte hole in 32-bit
because C-compiler always
align int data types beginning at the next word byte.
I don't think the C standard specifies how a struct should be layed out
in memory.
What do you mean ? Can you illustrate with C codes ? Do you mean that a
struct
are not allocated contiguous memory ? Do you mean a struct components are
allocated random memory. If it does not allocate contiguous memory in your
thinking, what about arrays since struct is similar to arrays except the
objects are
of mixed types ?
And when struct components are allocated random memory, this breaks down
the
nature and the power of C which to my mind lie in its ability to
manipulate and
manage objects using pointers and pointer-arithmetic.
Matthew said is wasn't `necessarily' bound to the hardware. In practise you
are going to see different data type sizes on different bits of hardware.
But just because the hardware can store an 64-bit words, doesn't mean that
the ABI is going to specify an int to be 64-bit.
What you probably mean is it is not mandated by the standard. Some specs
are mandated
and some are not.
That's why I used specific C codes to illustrate. Whether the C codes
that I used follows
the standard in the sense that it does not violate the standard it is
compliant. After all
compliance means it does not violate mandated standards.
And in intel or amd 16-bit and 32-bit it is as demonstrated. That's what
I meant.
--
O Plameras
http://www.acay.com.au/~oscarp/tutor
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
