[PHP-DEV] Zend signed multiply for ARM
Hello all, Some of the senior citizens in this community may remember me. I used to be involved in PHP development (and went to some conferences) in 2002-2005. I am now working for Linaro (www.linaro.org), trying to engineer the best LAMP stack possible for ARM servers (32 and 64 bit). I would like to contribute a patch to Zend/zend_multiply.h. I was already co-author of this code, and I would like to contribute ARM accelerated implementations for ZEND_SIGNED_MULTIPLY_LONG(). I have implemented them for both 32 and 64 bit, but the 64-bit one is especially important as it falls back to floating point calculations at the moment. I noticed a speed up of about 10% running Zend/bench.php for the 64-bit version. Patch is attached. Cheers, Ard. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Zend signed multiply for ARM
Gmail ate my attachment the 1st time, trying Thunderbird instead ...
diff --git a/Zend/zend_multiply.h b/Zend/zend_multiply.h
index c3c9657..3053f8b 100644
--- a/Zend/zend_multiply.h
+++ b/Zend/zend_multiply.h
@@ -13,7 +13,7 @@
| lice...@zend.com so we can mail you a copy immediately. |
+--+
| Authors: Sascha Schumann sas...@schumann.cx|
- | Ard Biesheuvel a...@ard.nu |
+ | Ard Biesheuvel ard.biesheu...@linaro.org |
+--+
*/
@@ -43,6 +43,31 @@
else (lval) = __tmpvar; \
} while (0)
+#elif defined(__arm__) defined(__GNUC__)
+
+#define ZEND_SIGNED_MULTIPLY_LONG(a, b, lval, dval, usedval) do { \
+ long __tmpvar; \
+ __asm__(smull %0, %1, %2, %3\n\
+ sub %1, %1, %0, asr #31\n \
+ : =r(__tmpvar), =r(usedval) \
+ : r(a), r(b)); \
+ if (usedval) (dval) = (double) (a) * (double) (b);\
+ else (lval) = __tmpvar; \
+} while (0)
+
+#elif defined(__aarch64__) defined(__GNUC__)
+
+#define ZEND_SIGNED_MULTIPLY_LONG(a, b, lval, dval, usedval) do { \
+ long __tmpvar; \
+ __asm__(mul %0, %2, %3\n \
+ smulh %1, %2, %3\n \
+ sub %1, %1, %0, asr #63\n \
+ : =X(__tmpvar), =X(usedval) \
+ : X(a), X(b)); \
+ if (usedval) (dval) = (double) (a) * (double) (b);\
+ else (lval) = __tmpvar; \
+} while (0)
+
#elif SIZEOF_LONG == 4 defined(HAVE_ZEND_LONG64)
#define ZEND_SIGNED_MULTIPLY_LONG(a, b, lval, dval, usedval) do { \
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Zend signed multiply for ARM
Welcome back Ard. Looks good to me, but I don't have an ARM box to test on. Go to http://php.net/git-php.php and fill in the form at the bottom there and we will get you set up with a git account unless you already have one. I did a quick search and couldn't find it. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] VCS Account Request: ardbiesheuvel
Submitting performance tweaks specific to ARM platforms (both 32 and 64 bit) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Zend signed multiply for ARM
On 17 January 2013 16:22, Rasmus Lerdorf ras...@lerdorf.com wrote: Welcome back Ard. Looks good to me, but I don't have an ARM box to test Thanks! I have done some manual testing on the corner cases, both on the 64-bit ARMv8 emulator and a 32-bit TI Beaglebone, and have also run the test cases in the Zend/ folder, and everything appears to work just fine. I will add a couple of simple test cases for both 32 and 64 bit targets, and make sure the various implementations are aligned. on. Go to http://php.net/git-php.php and fill in the form at the bottom there and we will get you set up with a git account unless you already have one. I did a quick search and couldn't find it. Done, Cheers, Ard. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: VCS Account Request: ardbiesheuvel
rasmus approved ardbiesheuvel account request \o/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: VCS Account Request: cpriest
rasmus approved cpriest account request \o/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [VOTE] Property Accessors for 5.5
I'm happy to say that Property Accessors is ready for a vote for inclusion in 5.5 release. Nikita and I (as well as Stas a bit) have all been working hard to make this happen for 5.5, voting and the specifications are here: https://wiki.php.net/rfc/propertygetsetsyntax-v1.2#voting Thanks, -Clint -- -Clint
Re: [PHP-DEV] [VOTE] Property Accessors for 5.5
On Thu, Jan 17, 2013 at 7:20 PM, Clint Priest cpri...@zerocue.com wrote: I'm happy to say that Property Accessors is ready for a vote for inclusion in 5.5 release. Nikita and I (as well as Stas a bit) have all been working hard to make this happen for 5.5, voting and the specifications are here: https://wiki.php.net/rfc/**propertygetsetsyntax-v1.2#**votinghttps://wiki.php.net/rfc/propertygetsetsyntax-v1.2#voting Thanks, -Clint This is great news, thank you very much for all your hard work! Its much appreciated!
Re: [PHP-DEV] [RFC] Fixing insecure cURL file uploading
Hi Stas, What's the status of this fix ? Thanks Pierrick On 8 January 2013 04:23, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! Looks good to me, just it could be great to add a new cURL option at the same time to disable the '@' usage so that someone working with the new ext/curl version can disable it and therefore send values starting by @ That is a good suggestion, I'll add CURL_SAFE_POSTFIELDS which would disable the @ option. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Fixing insecure cURL file uploading
Hi! What's the status of this fix ? The pull is in the RFC, so I planned to do the vote on Monday and then get it merged if nobody objects. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Fixing insecure cURL file uploading
Great :) Thanks for the update On 17 January 2013 15:35, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! What's the status of this fix ? The pull is in the RFC, so I planned to do the vote on Monday and then get it merged if nobody objects. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Property Accessors for 5.5
On 1/17/13 1:20 PM, Clint Priest wrote:
I'm happy to say that Property Accessors is ready for a vote for inclusion in
5.5 release.
Nikita and I (as well as Stas a bit) have all been working hard to make this
happen for
5.5, voting and the specifications are here:
https://wiki.php.net/rfc/propertygetsetsyntax-v1.2#voting
I'll say my peace on this. This is a very good implementation, and as long as authors use
accessors that depend on a separate property for storage (like other langs require),
everything will be straightforward. Otherwise, I fear they're in for some confusing behavior.
Consider the code from the RFC:
class TimePeriod {
public $Hours {
get { return $this-Hours ?: not specified; }
set { $this-Hours = $value; }
}
}
$tp = new TimePeriod();
$tp-Hours; // not specified
isset($tp-Hours); // true!?
The auto implementation of isset compares $this-Hours to NULL, but since $this-Hours
goes through the getter, it will return not specified. So the property will always
appear to be isset.
* The guards seem spooky: A set of tokens ($this-prop) will have varying behavior (e.g.
direct prop read vs. getter call) *depending on the call stack*.
* Giving issetter/unsetter no direct access to the property limits functionality and leads
to weirdness like the example above.
Steve Clay
--
http://www.mrclay.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Property Accessors for 5.5
On 1/17/2013 4:24 PM, Steve Clay wrote:
https://wiki.php.net/rfc/propertygetsetsyntax-v1.2#voting
I'll say my peace on this. This is a very good implementation, and as
long as authors use accessors that depend on a separate property for
storage (like other langs require), everything will be
straightforward. Otherwise, I fear they're in for some confusing
behavior.
Consider the code from the RFC:
class TimePeriod {
public $Hours {
get { return $this-Hours ?: not specified; }
set { $this-Hours = $value; }
}
}
$tp = new TimePeriod();
$tp-Hours; // not specified
isset($tp-Hours); // true!?
$tp-Hours isset, the property exists and it's value is non-null.
The auto implementation of isset compares $this-Hours to NULL, but
since $this-Hours goes through the getter, it will return not
specified. So the property will always appear to be isset.
* The guards seem spooky: A set of tokens ($this-prop) will have
varying behavior (e.g. direct prop read vs. getter call) *depending on
the call stack*.
This is the same as would occur with isset against an undefined
property, that would call __isset(), followed by __get() which would
then compare the value to NULL.
* Giving issetter/unsetter no direct access to the property limits
functionality and leads to weirdness like the example above.
This is possible, simply by supplying your own implementation of
isset/unset that calls isset/unset, such as:
public $foo {
get; set;
isset { return isset($this-foo); }
unset { unset($this-foo); }
}
The above five lines of code is exactly equivalent in functionality to:
public $foo;
-Clint
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
