Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:86527
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.216.44 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <1FAF88D0E2DE433FA299B4FAF7120880@pc1>
References: <CAESVnVr6oyAOCjWRWp7MGio_JNuUryPm=HKeY=fDgKRBcMXJ=Q@mail.gmail.com>
	<55513AA4.7010706@gmail.com>
	<579127CDC1B54040BEEFD4564A6F78B7@pc1>
	<CAESVnVpDXmLB-Gd_9HTyrdcnuS8g27Gezwgodb1CVLCVo0u2tg@mail.gmail.com>
	<1FAF88D0E2DE433FA299B4FAF7120880@pc1>
Date: Tue, 9 Jun 2015 19:29:27 +0300
Message-ID: <CA+9eiLu01OKNnDO-mH8Kkv=ScJvyihAEVY2aRHRysXFyWXBUPw@mail.gmail.com>
To: Matt Wilmas <php_lists@realplain.com>, Sara Golemon <pollita@php.net>, Anatol Belski <ab@php.net>, 
	Kalle Sommer Nielsen <kalle@php.net>
Cc: Dmitry Stogov <dmitry@php.net>, Stanislav Malyshev <smalyshev@gmail.com>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=bcaec52d52dd197df605181843f6
Subject: Re: [PHP-DEV] Undefined variables undefined order
From: dmitry@zend.com (Dmitry Stogov)

--bcaec52d52dd197df605181843f6
Content-Type: text/plain; charset=UTF-8

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_lists@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_lists@realplain.com>
>> wrote:
>>
>>> ----- Original Message -----
>>> From: "Stanislav Malyshev" <smalyshev@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
>
>

--bcaec52d52dd197df605181843f6--