Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81673
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.200 as permitted sender)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
In-Reply-To: <54D00C40.8060907@lsces.co.uk>
Date: Mon, 2 Feb 2015 23:50:39 +0000
Cc: internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <54C5DC93-9600-4EE2-BF06-7BF10FC6AD5C@ajf.me>
References: <8C47FA53-0964-49C0-963C-332A936348A5@ajf.me> <BCFDECB6-8FBC-4EA1-A081-21BDCC79C1C2@ajf.me> <B9B67D82-CB4E-4CA6-AFAB-25A22EC386B4@ajf.me> <54D00C40.8060907@lsces.co.uk>
To: Lester Caine <lester@lsces.co.uk>
Subject: Re: [PHP-DEV] [RFC] Big Integer Support
From: ajf@ajf.me (Andrea Faulds)

Hi Lester,

> On 2 Feb 2015, at 23:46, Lester Caine <lester@lsces.co.uk> wrote:
>=20
> Andrea ... I am still unhappy that this is being pushed as the core
> 'integer' handling. Further options have appeared for 32bit devices
> which are driving me to seriously consider perhaps having to look into =
a
> simple 64bit maths solution to BIGINT on 32 bit devices. But simply
> getting interbase extension compiling clean with master is enough work
> without having to add other speculative work that is further =
detracting
> from the real job of getting into a state where I could even use PHP7 =
in
> production. Just what work IS required to build this in parallel with =
my
> almost working PHP7 development platform ... will all the third party
> extensions also need work, such as imagick which I still don't have a
> clean copy off yet.

Yes, most extensions will need some updating, but from what I have seen, =
the changes needed are very small (maybe a few lines) in most cases, =
unless you=92re porting ext/gmp or something.

> Since a clean 64bit build of PHP does not need anything other than
> 'integer' to support 64bit BIGINT SQL numbers, loading 32bit builds =
with
> an overly heavy solution is just not right!

I don=92t see how it=92s =93overly heavy=94. Bear in mind that several =
extensions (not just ext/gmp) already require GMP anyway.

> 'longint' only needs an
> extension to provide it, which can then be replaced by properly =
crafted
> code for devices that already have 256bit and better maths capability
> anyway.

GMP provides high-performance, optimised SIMD assembly implementations =
for most platforms.

--
Andrea Faulds
http://ajf.me/