Re: [Zend Engine 2] Bumping PHP to support 8byte integers (fwd)

This subject is being crossposted to engine2@lists.zend.com and php-dev@lists.php.net This mail was only on engine2 (let's keep everyting at least on phpdev): ---------- Forwarded message ---------- Date: Sun, 23 Sep 2001 22:41:45 +0200 (CEST) From: Jeroen van Wolffelaar <jeroen@A-Eskwadraat.nl> To: Stig Sæther Bakken <ssb@alltheweb.com> Cc: engine2@lists.zend.com Subject: Re: [Zend Engine 2] Bumping PHP to support 8byte integers On 23 Sep 2001, Stig Sæther Bakken wrote: > ["Jeroen van Wolffelaar" <jeroen@a-eskwadraat.nl>] > > Hi, > > > > For a scripting language, integers should IMHO be bounded by a number that > > will reasonally not be bound by numbers that will be used in normal scripts. > > > > That is currently not the case, 4 bytes are insufficient IMHO. Why not make > > sure PHP uses 8 bytes at least? Or are there platforms not supporting 8byte > > integers? I believe most popular do... (at least linux on i586 and i686, > > windows and Solaris (I tested SunOS 5.6)) > > > > For implementation, I think that we should introduce p_int and p_float > > typedefs for php-integer and php-float anyway, and changing THAT isn't a > > problem. > > > > About preformance/memory, I think that's not an issue. Making strings > > unicode will be much more heavy for PHP... > > I don't know what you had in mind, but replacing "long lval" with > "long long lval" will increase the size of _every_ zval from 8 to 12 > bytes. That's indeed a big issue, since it requires more memory _and_ > cpu (more data to move around). zval.value is an union with: (4byte)long lval (8byte)double dval (8byte)struct str (4byte)*ht (8byte)stuct obj So not more cpu time in moving around, since C does not know it doesn't need to copy the last 4 bytes in the union. The size of zval will remain value+type+is_ref+refcount = 8+1+1+2 = 12. > > - Stig > > Jeroen van Wolffelaar Jeroen@A-Eskwadraat.nl http://www.A-Eskwadraat.nl/~jeroen