Re: [PHP-DEV] is GD being actively maintained?
Pierre Joye in php.internals (Thu, 6 Sep 2012 18:43:01 +0200): >On Thu, Sep 6, 2012 at 2:07 PM, Rasmus Schultz wrote: >> I opened this bug report 2 years ago: >> https://bugs.php.net/bug.php?id=52756 Hmmm. I see it is still open. >> Is GD still actively maintained? > >yes. Slowly but yes, we will finally merge 2.1 in 5.5 too. Related, but no real bug: libjpeg 9.0 is released. It compiles fine into php_gd2.dll, but reports an unknown version. This is due to ext/gd/libgd/gd_jpeg.c, which only knows versions 6b, 7 and 8. A simple check for JPEG_LIB_VERSION == 90 would be enough for the moment, but wouldn't it be better to report the JPEG_LIB_VERSION it self? 62, 70, 80, 90 or whatever... Jan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] more inline assembler noise
Hello,
Again, apologies for prematurely declaring someone else's code 'crap'.
There are no bugs in the inline x86 assembler in Zend/zend_operators.h,
as far as I can tell, only two kinds of issues that I still think should
be addressed.
First of all, from a maintenance pov, having field offsets (like the
offset of zval.type) and constants (like $0x2 for IS_DOUBLE) hard coded
inside the instructions is a bad idea.
The other issue is the branching and the floating point instructions.
The inline assembler addresses the common case, but also adds a bunch of
instructions that address the corner case, and some branches to jump
over them. As I indicated in my previous email, branching is relatively
costly on a modern CPU with deep pipelines and having a bunch of FPU
instructions in there that hardly ever get executed doesn't help either.
The primary reason for having inline assembler at all is the ability to
detect overflow. This mainly applies to multiplication, as in that case,
detecting overflow in C code is much harder compared to reading a
condition flag in the CPU (hence the various accelerated implementations
in zend_signed_multiply.h). However, detecting overflow in
addition/subtraction implemented in C is much easier, as the code in
zend_operators.h proves: just a matter of checking the sign bits, or
doing a simple compare with LONG_MIN/LONG_MAX.
Therefore, I would be interested in finding out which benchmark was used
to make the case for having these accelerated implementations in the
first place. The differences in performance between various
implementations are very small in the tests I have done.
As for the code style/maintainability, I propose to apply the attached
patch. The performance is on par, as far as I can tell, but it is
arguably better code. I will also hook in the ARM versions once I manage
to prove that the performance is affected favourably by them.
Regards,
Ard.
Before
---
$ time php -r 'for ($i = 0; $i < 0x7fff; $i++);'
real0m56.910s
user0m56.876s
sys 0m0.008s
$ time php -r 'for ($i = 0x7fff; $i >= 0; $i--);'
real1m34.576s
user1m34.518s
sys 0m0.020s
$ time php -r 'for ($i = 0; $i < 0x7fff; $i += 3);'
real0m21.494s
user0m21.473s
sys 0m0.008s
$ time php -r 'for ($i = 0x7fff; $i >= 0; $i -= 3);'
real0m19.879s
user0m19.865s
sys 0m0.004s
After
-
$ time php -r 'for ($i = 0; $i < 0x7fff; $i++);'
real0m56.687s
user0m56.656s
sys 0m0.004s
$ time php -r 'for ($i = 0x7fff; $i >= 0; $i--);'
real1m28.124s
user1m28.082s
sys 0m0.004s
$ time php -r 'for ($i = 0; $i < 0x7fff; $i += 3);'
real0m20.561s
user0m20.545s
sys 0m0.004s
$ time php -r 'for ($i = 0x7fff; $i >= 0; $i -= 3);'
real0m20.524s
user0m20.509s
sys 0m0.004s
>From c9c8847713d22058ee47beffad54f2159f199cb9 Mon Sep 17 00:00:00 2001
From: Ard Biesheuvel
Date: Fri, 18 Jan 2013 18:31:57 +0100
Subject: [PATCH] Improve x86 assembler implementations of add/sub int
arithmetic
---
Zend/zend_operators.h | 182 +++--
1 file changed, 56 insertions(+), 126 deletions(-)
diff --git a/Zend/zend_operators.h b/Zend/zend_operators.h
index 20a5277..b34ddfc 100644
--- a/Zend/zend_operators.h
+++ b/Zend/zend_operators.h
@@ -479,35 +479,27 @@ ZEND_API void zend_update_current_locale(void);
static zend_always_inline int fast_increment_function(zval *op1)
{
if (EXPECTED(Z_TYPE_P(op1) == IS_LONG)) {
+ unsigned char overflow;
#if defined(__GNUC__) && defined(__i386__)
__asm__(
- "incl (%0)\n\t"
- "jno 0f\n\t"
- "movl $0x0, (%0)\n\t"
- "movl $0x41e0, 0x4(%0)\n\t"
- "movb $0x2,0xc(%0)\n"
- "0:"
- :
- : "r"(op1));
+ "incl (%1)\n\t"
+ "seto %b0"
+ : "=q"(overflow)
+ : "r"(&Z_LVAL_P(op1)));
#elif defined(__GNUC__) && defined(__x86_64__)
__asm__(
- "incq (%0)\n\t"
- "jno 0f\n\t"
- "movl $0x0, (%0)\n\t"
- "movl $0x43e0, 0x4(%0)\n\t"
- "movb $0x2,0x14(%0)\n"
- "0:"
- :
- : "r"(op1));
+ "incq (%1)\n\t"
+ "seto %b0"
+ : "=q"(overflow)
+ : "r"(&Z_LVAL_P(op1)));
#else
- if (UNEXPECTED(Z_LVAL_P(op1) == LONG_MAX)) {
+ overflow = (Z_LVAL_P(op1)++ == LONG_MAX);
+#endif
+ if (UNEXPECTED(overflow)) {
/* switch to double */
Z_DVAL_P(op1) = (double)LONG_MAX + 1.0;
Z_TYPE_P(op1) = IS_DOUBLE;
- } else {
- Z_LVAL_P(op1)++;
}
-#endif
return SUCCESS;
}
return increment_function(op1);
@@ -516,35 +508,27 @@ static zend_always_inline int fast_increment_function(zval *op1)
static zend_always_inline int fast_decrement_function(zval *op1)
{
if (EXPECTED(Z_TYPE_P(op1) == IS_LONG)) {
+ unsigned char overflow;
#if defined(__GNUC__) && defined(__i386__)
__asm__(
- "decl (%0)\n\t"
- "jno 0f\n\t"
- "movl $0x0020, (%0)\n\t"
- "movl $0xc1e0, 0x4(%0)\n\t"
- "movb $0x2,0xc(%0)\n"
- "0:"
- :
- : "r"(op1));
+ "decl (%1)\n\t"
+ "se
Re: [PHP-DEV] new FTP function
hello Marco Pivetta,
while the implementations you linked indeed works, it also kinda big and
involve changing the error handler just so that it doesn't show the error,
which i think is not the way to do it. i think there should be simple way
to check like "is_dir" or "is_file".
anyway thanks for the hints, i have sent request to bugs.php.net, and i
dont like to spam the dev list since they quite busy already
PS: and sorry for the grammar errors, English is not my native tongue.
On Fri, Jan 18, 2013 at 6:37 PM, Marco Pivetta wrote:
> Heya KISE,
>
> I just checked a bit around and found that current implementations
> actually simply deal with the warning:
>
>
> https://github.com/rjkip/ftp-php/blob/master/src/FtpPhp/FtpClient.php#L172-L186
>
> https://github.com/rjkip/ftp-php/blob/master/src/FtpPhp/FtpClient.php#L92-L116
>
> What kind of problems is the warning currently causing in your code?
>
> Marco Pivetta
>
> http://twitter.com/Ocramius
>
> http://ocramius.github.com/
>
>
> On 18 January 2013 16:33, KISE wrote:
>
>> Paul Dragoonis,
>>
>> Actually it wont work i did tried it before, if the dir end with / it will
>> list the directories inside the path you gave it and if it doesn't have
>> any
>> directories it will return false since there is no directories to return.
>>
>> you have to take out the last / and then remove the directory in question
>> and list the files in the parent directory and check if the dir exists
>> otherwise it will return false, i spent 3hrs yesterday thinking why its
>> returning false even though the directory exists.
>>
>> On Fri, Jan 18, 2013 at 6:28 PM, Paul Dragoonis
>> wrote:
>>
>> >
>> > On Fri, Jan 18, 2013 at 3:18 PM, KISE wrote:
>> >
>> >> $res = ftp_nlist($this->conn_id, '-dF '. $dir);
>> >>
>> >
>> > This could be done in two lines.
>> >
>> > function dir_exists($conn, $dir) {
>> > $list = ftp_nlist($conn, '-dF '. $dir);
>> > return in_array($dir, $list);
>> > }
>> >
>>
>
>
Re: [PHP-DEV] new FTP function
Heya KISE,
I just checked a bit around and found that current implementations actually
simply deal with the warning:
https://github.com/rjkip/ftp-php/blob/master/src/FtpPhp/FtpClient.php#L172-L186
https://github.com/rjkip/ftp-php/blob/master/src/FtpPhp/FtpClient.php#L92-L116
What kind of problems is the warning currently causing in your code?
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
On 18 January 2013 16:33, KISE wrote:
> Paul Dragoonis,
>
> Actually it wont work i did tried it before, if the dir end with / it will
> list the directories inside the path you gave it and if it doesn't have any
> directories it will return false since there is no directories to return.
>
> you have to take out the last / and then remove the directory in question
> and list the files in the parent directory and check if the dir exists
> otherwise it will return false, i spent 3hrs yesterday thinking why its
> returning false even though the directory exists.
>
> On Fri, Jan 18, 2013 at 6:28 PM, Paul Dragoonis
> wrote:
>
> >
> > On Fri, Jan 18, 2013 at 3:18 PM, KISE wrote:
> >
> >> $res = ftp_nlist($this->conn_id, '-dF '. $dir);
> >>
> >
> > This could be done in two lines.
> >
> > function dir_exists($conn, $dir) {
> > $list = ftp_nlist($conn, '-dF '. $dir);
> > return in_array($dir, $list);
> > }
> >
>
Re: [PHP-DEV] new FTP function
Paul Dragoonis,
Actually it wont work i did tried it before, if the dir end with / it will
list the directories inside the path you gave it and if it doesn't have any
directories it will return false since there is no directories to return.
you have to take out the last / and then remove the directory in question
and list the files in the parent directory and check if the dir exists
otherwise it will return false, i spent 3hrs yesterday thinking why its
returning false even though the directory exists.
On Fri, Jan 18, 2013 at 6:28 PM, Paul Dragoonis wrote:
>
> On Fri, Jan 18, 2013 at 3:18 PM, KISE wrote:
>
>> $res = ftp_nlist($this->conn_id, '-dF '. $dir);
>>
>
> This could be done in two lines.
>
> function dir_exists($conn, $dir) {
> $list = ftp_nlist($conn, '-dF '. $dir);
> return in_array($dir, $list);
> }
>
Re: [PHP-DEV] new FTP function
An extra parameter is required in the above function, but you get the
point, i don't want to keep spamming the mailing list with corrections :-)
On Fri, Jan 18, 2013 at 3:30 PM, Paul Dragoonis wrote:
> Revised function:
>
> function dir_exists($conn, $currentDir) {
> $list = ftp_nlist($conn, '-dF '. $currentDir);
> return in_array($dir, $list);
> }
>
>
> On Fri, Jan 18, 2013 at 3:28 PM, Paul Dragoonis wrote:
>
>>
>> On Fri, Jan 18, 2013 at 3:18 PM, KISE wrote:
>>
>>> $res = ftp_nlist($this->conn_id, '-dF '. $dir);
>>>
>>
>> This could be done in two lines.
>>
>> function dir_exists($conn, $dir) {
>> $list = ftp_nlist($conn, '-dF '. $dir);
>> return in_array($dir, $list);
>> }
>>
>
>
Re: [PHP-DEV] new FTP function
Revised function:
function dir_exists($conn, $currentDir) {
$list = ftp_nlist($conn, '-dF '. $currentDir);
return in_array($dir, $list);
}
On Fri, Jan 18, 2013 at 3:28 PM, Paul Dragoonis wrote:
>
> On Fri, Jan 18, 2013 at 3:18 PM, KISE wrote:
>
>> $res = ftp_nlist($this->conn_id, '-dF '. $dir);
>>
>
> This could be done in two lines.
>
> function dir_exists($conn, $dir) {
> $list = ftp_nlist($conn, '-dF '. $dir);
> return in_array($dir, $list);
> }
>
Re: [PHP-DEV] new FTP function
On Fri, Jan 18, 2013 at 3:18 PM, KISE wrote:
> $res = ftp_nlist($this->conn_id, '-dF '. $dir);
>
This could be done in two lines.
function dir_exists($conn, $dir) {
$list = ftp_nlist($conn, '-dF '. $dir);
return in_array($dir, $list);
}
Re: [PHP-DEV] new FTP function
Will Fitch, sorry i didn't know that i contacted one of the dev to post it
on behalf of me and he said its ok to post here, i'll post it there right
away
Paul Dragoonis, there is 3 ways to do it in userland codes.
Public function dir_exists($dir)
{
if (!$this->conn_id)
return false;
$currentDir = ftp_pwd($this->conn_id);
if ( ftp_chdir($this->conn_id, $dir) )
{
ftp_chdir($this->conn_id, $currentDir);
return true;
}
return false;
}
this function above attempts to change directory it see if its exists or
not. and produce E_WARNING if the dir doesn't exists
and there is
echo ( is_dir("ftp://{$username}:{$password}@{$server}{$dir}";) ) ? true :
false;
which require that you re-authenticate
Public function dir_exists2($dir)
{
if ( !$this->conn_id )
return false;
$orginal = $dir;
if ( substr($dir, -1) === '/' )
$dir = substr($dir, 0, strlen($dir)-1);
$dir= substr($dir, 0, strlen($dir)-strlen(strrchr($dir,'/')));
$res = ftp_nlist($this->conn_id, '-dF '. $dir);
if ( isset($res) AND is_array($res) )
{
foreach ($res as $key => $value)
{
if ($value === $orginal)
return true;
}
}
return false;
}
this function i hacked my self to stop the E_WARNING from flooding my error
log files. it works but kinda ugly and so hackish, and i dont think it will
work nicely if there is too many directories.
On Fri, Jan 18, 2013 at 6:04 PM, Paul Dragoonis wrote:
> I don't believe there's a feature of the FTP protocol to check if a
> file/folder exists.
>
> Can you please provide a PHP userland solution to this, so that a
> corresponding C implementation could be added.
>
> I believe the way to go about it is list the CWD contents and check if
> that exists and is of type DIR. You must also make sure that if a file
> exists with the name of the directory you want to check it has to handle
> that properly, it can't simply return true or false. If false then that
> means you could create it because it doesn't exist. If true it means you
> can CD into it and put stuff there, which is also not true.
>
> Thanks,
> Paul.
>
>
> On Fri, Jan 18, 2013 at 3:00 PM, Will Fitch wrote:
>
>>
>> On Jan 18, 2013, at 9:53 AM, KISE wrote:
>>
>> > Hi
>> >
>> > II would like to see "ftp_dir_exists()" function in PHP, right now its
>> > kinda unreasonable to expect people to use hacks such as "is_dir()" and
>> > having to re-authenticate just to check if the dir exists, I also dont
>> > think its good idea to use "ftp_chdir()" just to check if the directory
>> > exists, because its shows errors if the directory doesn't exists. i
>> think
>> > there should be a way to check if the directory exists without having to
>> > resort to hackish ways, or having to authenticate again.
>>
>> There are procedures in place for this. If you'd like to make a feature
>> request, use bugs.php.net and submit the request with the FTP extension
>> selected. You can also use https://wiki.php.net/rfc if you really want
>> to see/make the change as well.
>
>
>
Re: [PHP-DEV] new FTP function
I don't believe there's a feature of the FTP protocol to check if a file/folder exists. Can you please provide a PHP userland solution to this, so that a corresponding C implementation could be added. I believe the way to go about it is list the CWD contents and check if that exists and is of type DIR. You must also make sure that if a file exists with the name of the directory you want to check it has to handle that properly, it can't simply return true or false. If false then that means you could create it because it doesn't exist. If true it means you can CD into it and put stuff there, which is also not true. Thanks, Paul. On Fri, Jan 18, 2013 at 3:00 PM, Will Fitch wrote: > > On Jan 18, 2013, at 9:53 AM, KISE wrote: > > > Hi > > > > II would like to see "ftp_dir_exists()" function in PHP, right now its > > kinda unreasonable to expect people to use hacks such as "is_dir()" and > > having to re-authenticate just to check if the dir exists, I also dont > > think its good idea to use "ftp_chdir()" just to check if the directory > > exists, because its shows errors if the directory doesn't exists. i think > > there should be a way to check if the directory exists without having to > > resort to hackish ways, or having to authenticate again. > > There are procedures in place for this. If you'd like to make a feature > request, use bugs.php.net and submit the request with the FTP extension > selected. You can also use https://wiki.php.net/rfc if you really want > to see/make the change as well.
Re: [PHP-DEV] new FTP function
On Jan 18, 2013, at 9:53 AM, KISE wrote: > Hi > > II would like to see "ftp_dir_exists()" function in PHP, right now its > kinda unreasonable to expect people to use hacks such as "is_dir()" and > having to re-authenticate just to check if the dir exists, I also dont > think its good idea to use "ftp_chdir()" just to check if the directory > exists, because its shows errors if the directory doesn't exists. i think > there should be a way to check if the directory exists without having to > resort to hackish ways, or having to authenticate again. There are procedures in place for this. If you'd like to make a feature request, use bugs.php.net and submit the request with the FTP extension selected. You can also use https://wiki.php.net/rfc if you really want to see/make the change as well.
[PHP-DEV] new FTP function
Hi II would like to see "ftp_dir_exists()" function in PHP, right now its kinda unreasonable to expect people to use hacks such as "is_dir()" and having to re-authenticate just to check if the dir exists, I also dont think its good idea to use "ftp_chdir()" just to check if the directory exists, because its shows errors if the directory doesn't exists. i think there should be a way to check if the directory exists without having to resort to hackish ways, or having to authenticate again.
Re: [PHP-DEV] Patch: Specify temp directory
Hi Alex, could you open a pull request on GitHub for it. Makes managing things much easier. Other than an outstanding review, I see no reason not to include this functionality. cu, Lars Am 18.01.2013 um 15:01 schrieb ALeX Kazik : > Hi, > > some time ago I created a small patch to make it possible to specify > the temp dir by the php.ini. > > It can be found here: > https://bugs.php.net/bug.php?id=60524 > (my latest patch (against 5.4.3) also works for 5.4.11 and 5.5.0a3) > > Now I do wonder if anything will happen or if that's it? > > I would really appreciate if the patch would be included and hopefully > also some other people. > > Regards, > ALeX. > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Patch: Specify temp directory
Hi, some time ago I created a small patch to make it possible to specify the temp dir by the php.ini. It can be found here: https://bugs.php.net/bug.php?id=60524 (my latest patch (against 5.4.3) also works for 5.4.11 and 5.5.0a3) Now I do wonder if anything will happen or if that's it? I would really appreciate if the patch would be included and hopefully also some other people. Regards, ALeX. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: broken inline assembler in zend_operators.h
Replying to self:
The code is not as broken as I thought. Apologies for the noise.
(I misread zend.h where lval and dval are actually part of a union type)
However, there is still a lot of hardcodedness which I think should be
cleaned up, and the gain is not obvious.
--
Ard.
On 01/18/2013 12:25 PM, Ard Biesheuvel wrote:
Hello all,
As I indicated yesterday, I am looking into PHP performance when running
on ARM, and while doing that, I ran into the following code in
Zend/zend_operators.h.
For 32-bit x86, we have the following assembler code to do a 'fast'
increment (%0 is a zval*):
incl (%0)@ increment value at address %0
jno 0f@ jump to label 0 if no overflow
movl $0x0, (%0)@ else store 0 to address %0
movl $0x41e0, 0x4(%0)@ store LONG_MAX+1 at %0+4
movb $0x2,0xc(%0)@ set field %0 + 0xc to 2
0:
This code makes a fair number of assumptions:
- zval.lval is the first member of a zval struct
- zval.dval is the second member, at offset 4
- zval.type lives at offset 0xc
- IS_DOUBLE == 0x2
For 64-bit x86, we have a similar snippet:
incq (%0)@ increment value at address %0
jno 0f@ jump to label 0 if no overflow
movl $0x0, (%0)@ else store 0 to address %0
movl $0x43e0, 0x4(%0)@ store LONG_MAX+1 at %0+4
movb $0x2,0x14(%0)@ set field %0 + 0x14 to 2
0:
only, expectedly, (double)LONG_MAX+1.0 has a different value (as
LONG_MAX on 64-bit has another value than on 32-bit), but also note that
while the hard coded offset of the type field (0x14) is likely correct,
the dval offset is 0x4 like in the previous example, while a long has
size 8 on 64-bit. In other words, this code is broken.
Another thing to note is that branch predictors typically predict all
branches as not taken, and it is up to the compiler to arrange the
branch in an optimal way; as we branch on no overflow, the code above
basically amounts to using
if (EXPECT(overflow)) {
/* juggle doubles */
} else {
lval++;
}
The fast_add and fast_sub function also appear to be broken. They fall
back to double arithmetic if the integer instructions overflow:
fildl(%1)@ load operand 1
fildl(%2)@ load operand 2
faddp%%st, %%st(1)@ perform the addition
movb $0x2,0xc(%0)@ set type of result to IS_DOUBLE
fstpl(%0)@ convert the result to long and store to lval!!
Note that this code is only executed if we have already established that
the integer addition will overflow, and so we know lval cannot hold the
result. Still, we store the result in lval, and nothing is stored to the
dval field in this case.
I ran some tests both on x86 and ARM, and the inline assembler does not
result in a noticeable speed up, as far as I can tell. Adding to that
the fact that they are all broken for x86, I suppose we get rid of them,
and just use the C versions in all cases. (I will not be adding ARM
versions of the inline assembler, as the performance gain is not obvious).
Regards,
Ard.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] broken inline assembler in zend_operators.h
Hello all,
As I indicated yesterday, I am looking into PHP performance when running
on ARM, and while doing that, I ran into the following code in
Zend/zend_operators.h.
For 32-bit x86, we have the following assembler code to do a 'fast'
increment (%0 is a zval*):
incl (%0) @ increment value at address %0
jno 0f @ jump to label 0 if no overflow
movl $0x0, (%0) @ else store 0 to address %0
movl $0x41e0, 0x4(%0) @ store LONG_MAX+1 at %0+4
movb $0x2,0xc(%0) @ set field %0 + 0xc to 2
0:
This code makes a fair number of assumptions:
- zval.lval is the first member of a zval struct
- zval.dval is the second member, at offset 4
- zval.type lives at offset 0xc
- IS_DOUBLE == 0x2
For 64-bit x86, we have a similar snippet:
incq (%0) @ increment value at address %0
jno 0f @ jump to label 0 if no overflow
movl $0x0, (%0) @ else store 0 to address %0
movl $0x43e0, 0x4(%0) @ store LONG_MAX+1 at %0+4
movb $0x2,0x14(%0) @ set field %0 + 0x14 to 2
0:
only, expectedly, (double)LONG_MAX+1.0 has a different value (as
LONG_MAX on 64-bit has another value than on 32-bit), but also note that
while the hard coded offset of the type field (0x14) is likely correct,
the dval offset is 0x4 like in the previous example, while a long has
size 8 on 64-bit. In other words, this code is broken.
Another thing to note is that branch predictors typically predict all
branches as not taken, and it is up to the compiler to arrange the
branch in an optimal way; as we branch on no overflow, the code above
basically amounts to using
if (EXPECT(overflow)) {
/* juggle doubles */
} else {
lval++;
}
The fast_add and fast_sub function also appear to be broken. They fall
back to double arithmetic if the integer instructions overflow:
fildl (%1)@ load operand 1
fildl (%2)@ load operand 2
faddp %%st, %%st(1) @ perform the addition
movb $0x2,0xc(%0) @ set type of result to IS_DOUBLE
fstpl (%0)@ convert the result to long and store to lval!!
Note that this code is only executed if we have already established that
the integer addition will overflow, and so we know lval cannot hold the
result. Still, we store the result in lval, and nothing is stored to the
dval field in this case.
I ran some tests both on x86 and ARM, and the inline assembler does not
result in a noticeable speed up, as far as I can tell. Adding to that
the fact that they are all broken for x86, I suppose we get rid of them,
and just use the C versions in all cases. (I will not be adding ARM
versions of the inline assembler, as the performance gain is not obvious).
Regards,
Ard.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
