Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69766
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
To: internals@lists.php.net,Joe Watkins <pthreads@pthreads.org>
Message-ID: <52667B24.5040105@php.net>
Date: Tue, 22 Oct 2013 14:18:28 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7
MIME-Version: 1.0
References: <3D.BC.23638.84CA1625@pb1.pair.com> <alpine.DEB.2.10.1310211054300.5542@whisky.home.derickrethans.nl> <5A140DF2-A29B-4804-A65C-37F6FB28D383@fastmail.fm> <52653B30.8050906@pthreads.org>
In-Reply-To: <52653B30.8050906@pthreads.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] RFC: Expectations
From: krakjoe@php.net (Joe Watkins)

On 10/21/2013 03:33 PM, Joe Watkins wrote:
> On 10/21/2013 02:27 PM, Hochstrasser Christoph wrote:
>> Hi Derick,
>>
>>> This is again an RFC that does not even attempt to argue for its
>>> usefulness. "This functionality was meant to replace the assert() API
>>> that currently exists in PHP, because of problems replacing it in a
>>> compatible manner". This doesn't say what is wrong with assert() or
>>> whether we *need* expect.
>>>
>> The RFC was first proposed as a RFC to replace the "assert()" function
>> with a "assert" keyword (which produces an opcode) in order to fix the
>> unacceptable performance of the current "assert()" implementation. See
>> also https://wiki.php.net/rfc/expectations#performance
>>
>> Later it was renamed to "expect" because the overall opinion was that
>> changing "assert()" can't be done in 5.x.
>>
>> Yes, this RFC could state more clearly what its purpose is, but it
>> certainly has usefulness. It's a lot faster than "assert()", when
>> turned off "expect" becomes a NOOP, and it doesn't rely on "eval()".
> Morning,
>
>      I'm not so good at conveying ideas; the explanation you have there
> is a summarized version of the java documentation of the same idea, the
> implementations are so similar they could be called identical.
>
>      So everyone has a clear idea of how this works, here's some detail
> about the op array for the statement "expect false;":
>
>      Optimizations=On Expectations=On (DEVELOPMENT):
>
>          opcodes[2]
>
>              opcodes[0] -> ZEND_EXPCT expression
>              opcodes[1] -> ZEND_RETURN
>
>       Optimizations=Off Expectations=On:
>
>          opcodes[9]
>
>               opcodes[0]-opcodes[6] -> ZEND_NOP
>               opcodes[7] -> ZEND_EXPCT expression
>               opcodes[8] -> ZEND_RETURN
>
>      Optimizations=On Expectations=Off (PRODUCTION)
>
>          opcodes[1]
>
>                opcodes[0] -> ZEND_RETURN
>
>       Optimizations=Off Expectations=Off:
>
>          opcodes[8]
>
>                 opcodes[0] -> ZEND_JMP opcodes[7]
>                 opcodes[1]-opcodes[6] -> ZEND_NOP
>                 opcodes[7] -> ZEND_RETURN
>
>       The same opcodes for "assert("false")":
>
>        Optimizations=Either Assertions=Either (LEGACY):
>
>          opcodes[3]
>
>                  opcodes[0] -> ZEND_SEND_VAL string
>                  opcodes[1] -> ZEND_DO_FCALL assert
>                  opcodes[2] -> ZEND_RETURN
>
>         When Assertions=Off opcodes[1] does not result in a call to
> eval, but the actual call to assert cannot be optimized, dragging down
> production considerably.
>
> Cheers
> Joe

When I wrote this it seemed wrong that there was padding ... and it was 
wrong, and it's since removed ...

Below is corrected information which I shall include in the RFC.

So everyone has a clear idea of how this works, here's some detail about 
the op array for the statement "expect false;":

       Optimizations=On Expectations=On (DEVELOPMENT):

           opcodes[2]

               opcodes[0] -> ZEND_EXPCT expression
               opcodes[1] -> ZEND_RETURN

        Optimizations=Off Expectations=On:

           opcodes[3]

                opcodes[0] -> ZEND_NOP
                opcodes[1] -> ZEND_EXPCT expression
                opcodes[2] -> ZEND_RETURN

       Optimizations=On Expectations=Off (PRODUCTION)

           opcodes[1]

                 opcodes[0] -> ZEND_RETURN

        Optimizations=Off Expectations=Off:

           opcodes[2]

                  opcodes[0] -> ZEND_JMP opcodes[1]
                  opcodes[1] -> ZEND_RETURN

        The same opcodes for "assert("false")":

         Optimizations=Either Assertions=Either (LEGACY):

           opcodes[3]

                   opcodes[0] -> ZEND_SEND_VAL string
                   opcodes[1] -> ZEND_DO_FCALL assert
                   opcodes[2] -> ZEND_RETURN

          When Assertions=Off opcodes[1] does not result in a call to
  eval, but the actual call to assert cannot be optimized, dragging down
  production considerably.

Cheers
Joe