On Wed, 2008-09-03 at 19:13 +0100, Colin Guthrie wrote:
> Robert Cummings wrote:
> > I do develop in C so I now need to take a stick to you. It's still
> > double space. Use a simple example for yourself. Let's say a struct like
> > following:
> >
> > struct _foo
> > {
> > int i;
> > int j;
> > int k[5];
> > } foo;
> >
> > In 32 bit system we have:
> >
> > 32 bits for i
> > + 32 bits for j
> > + (32 bits for each k) * 5
> > + 32 bits for the pointer to foo
> > = 32 * 8
> >
> > In 64 bit system we have:
> >
> > 64 bits for i
> > + 64 bits for j
> > + (64 bits for each k) * 5
> > + 64 bits for the pointer to foo
> > = 64 * 8
> > = (32 * 2) * 8
> > = (32 * 8) * 2
> >
> > Exactly double. Please explain where I went wrong.
>
> Erm, forgive me if my understanding is way off here but int == int == 32
> bit width regardless of 32 or 64 bit arch.
>
> I always thought 64 bit == 64 bit addressing therefore;
>
> int* i;
>
> In 32 bit system we have:
> 32 bits to store *address* of i.
>
> In 64 bit system we have:
> 64 bits to store *address* of i.
>
> i itself is still the same size. An int is an int. It doesn't magically
> get bigger on an x86_64 architecture... that would only change if your
> word size changes.
>
> If it were not then there would be a whole heap of problems with bounds
> checking and other such stuff if the size of an int changed.
>
>
> Therefore, depending on your structures and how much use of pointers you
> use, the size will always be more, but should always be *less* than half.
>
>
> Consider this small program:
>
> #include <stdio.h>
>
> int main(int argv, char* argc[])
> {
> int i;
> int* pi;
> printf("sizeof(int): %d\n", sizeof(i));
> printf("sizeof(int*): %d\n", sizeof(pi));
> return 0;
> }
>
> It produces this shell output:
>
> [colin@jimmy nusoap]$ gcc -o 64 test.c
> [colin@jimmy nusoap]$ file 64
> 64: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically
> linked (uses shared libs), for GNU/Linux 2.6.9, not stripped
> [colin@jimmy nusoap]$ ./64
> sizeof(int): 4
> sizeof(int*): 8
> [colin@jimmy nusoap]$ linux32 gcc -o 32 test.c
> [colin@jimmy nusoap]$ file 32
> 32: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
> dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped
> [colin@jimmy nusoap]$ ./32
> sizeof(int): 4
> sizeof(int*): 4
>
>
> That would seem to tally with my understanding. The address space is
> using 8 bytes (64bits) on x86_64 and 4 bytes (32bits) on x86, but the
> size of the integer itself is the same.
Well I was simplifying... the size of an int can change... more
specifically the size of long on a 64 bit system almost certainly
changes from 32 bits to 64 bits on a 64 bit system unless you play with
the compiler flags. So if you change my example to use long instead of
int you'll see the same. But the point of the simplified example was to
show that it shouldn't be more than double. Double space is therefore
the upper limit of space increase when switching from a 32 bit system to
a 64 bit system.
Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
