I don't see a big problem changing this for few opcodes in PHP-7 VM, and
make behavior "more defined".
On the other hand I don't think we shouldn't "define" the order of operand
evaluation.
This may prevent us performing optimisations in the future.

Fixing this in PHP-5.* doesn't cost the effort from my point of view.

Thanks. Dmitry.

On Tue, Jun 9, 2015 at 4:05 PM, Matt Wilmas <php_li...@realplain.com> wrote:

> Hi all,
>
> ----- Original Message -----
> From: "Sara Golemon"
> Sent: Monday, May 11, 2015
>
>  On Mon, May 11, 2015 at 5:12 PM, Matt Wilmas <php_li...@realplain.com>
>> wrote:
>>
>>> ----- Original Message -----
>>> From: "Stanislav Malyshev" <smalys...@gmail.com>
>>> Sent: Monday, May 11, 2015
>>>
>>>  argument. I'd like to propose making the order of evaluation defined
>>>>> by splitting this into separate statements:
>>>>>
>>>>
>>>> What is the purpose of this? I.e. why is it important that these notices
>>>> would be produced in certain order?
>>>>
>>>
>>> Logic, consistency, "polish," etc. :-)
>>>
>>>  Exactly this. :)
>>
>> It's just my CDO kicking in.  It's not necessary for the language to
>> function. Heck, HHVM already matches PHP 5.1-7.0's out-of-order
>> behavior, so fixing PHP only creates double work for me.  I just look
>> at these error messages and twitch uncomfortably.
>>
>
> Hah, looks like this just changed last week after barely 3 weeks. :-P  I
> didn't verify, just noticed the code change:
> http://git.php.net/?p=php-src.git;a=commitdiff;h=c09698753e7d1d95299dca54c8ca888c885fd45b
>
> Andi hasn't objected, yet. :-O  And ironically it was part of an
> optimization...
>
> Now CONCAT is consistent, but not others.  Which places need changing
> anyway?  Just binary ops in VM?
>
> A couple/few extra instructions are unavoidable, I guess on any
> architecture, for the intermediate save of op1, but can anyone show that it
> makes ANY measurable difference (other than instruction count)?
>
> For ADD, MUL, IS_[NOT_]IDENTICAL, IS_[NOT_]EQUAL, BW_*, and BOOL_XOR, ops
> can be passed as
>
> ... result, op2, op1);
>
> with no ill effects (I think) and still have the same (fewest)
> instructions as now!  That is, if anyone thinks, or can show, that it
> matters. :-)
>
> Whoops, didn't check first -- I see ADD, MUL, and IS_[NOT_]EQUAL (among
> others) are already consistent/fixed (but extra instructions :-D).
>
>  -Sara
>>
>
> - Matt
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Reply via email to