Uh... what about boolean? Depending on the compiler and instruction
set differences, even one-byte things now have to be on longword
boundaries, meaning that something that is one byte will have to take
8 in order to be on proper boundaries. Unless the app or compiler is
doing packing, which I don't think is the case with PHP. When memory
was more expensive, we designed CPUs to be able to do instructions on
off-boundary positions in memory. Well, not so much with RISC, and not
so much with modern instruction sets. It's just so much faster.
On Wed, Sep 3, 2008 at 11:54 AM, Robert Cummings <robert@xxxxxxxxxxxxx> wrote:
> 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
>
>
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
