# Fwd: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / README.ZEND_VM

- Thread: https://externals.io/message/12681
- Original archive: https://news-web.php.net/php.internals/12681
- Started by Andi Gutmans on 2004-09-09T17:17:34+00:00
- Messages: 3
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #12681 — Andi Gutmans — 2004-09-09T17:17:34+00:00

URL: https://externals.io/message/12681#12681

FYI, some more information about the proposed changes.
It's really not critical, because I think performance is much more 
dependant on how the application is written, the database queries and so 
on, but it's quite a nice system which gives us both opcode specialization 
and other execution alternatives.
I heard some are worried about not being able to hook into opcodes anymore. 
I don't think that's really required (it wasn't in PHP 4) but if you feel 
strongly about it, we could maybe always create the handler execution 
architecture and allow you tell PHP (in your extensions like xdebug) to use 
that method. It's a bit bloated and again, I don't think it's needed but it 
could probably be done.
(FYI: Probably the same people complained when I made the change from PHP 4 
to PHP 5 from switch() to handler which was purely an architectural reason) 
:) Just an interesting observation :)

Andi

>From: "Andi Gutmans" <andi@php.net>
>To: zend-engine-cvs@lists.php.net
>Date: Thu, 09 Sep 2004 17:04:12 -0000
>Subject: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / README.ZEND_VM
>
>andi            Thu Sep  9 13:04:12 2004 EDT
>
>   Added files:
>     /ZendEngine2        README.ZEND_VM
>   Log:
>   - Commit VM explanation.
>
>
>
>http://cvs.php.net/co.php/ZendEngine2/README.ZEND_VM?r=1.1&p=1
>Index: ZendEngine2/README.ZEND_VM
>+++ ZendEngine2/README.ZEND_VM
>ZEND_VM
>=======
>
>ZEND_VM architecture allows specializing opcode handlers according to op_type
>fields and using different execution methods (call threading, switch threading
>and direct threading). As a result ZE2 got more then 20% speedup on raw PHP
>code execution (with specialized executor and direct threading execution
>method). As most in most PHP applications raw execution speed isn't the
>limiting factor but system calls and database callls are, your mileage with
>this patch will vary.
>
>Most parts of the old zend_execute.c go into zend_vm_handlers.h. Here you can
>find opcode handlers and helpers. The typical opcode handler template looks
>like this:
>
>#define <OPCODE>_SPEC() OPDEF(<OPCODE>, <OP1_TYPES>, <OP2_TYPES>)
>#if HAVE_OP(<OPCODE>)
>ZEND_VM_HANDLER(<OPCODE>)
>{
>         <HANDLER'S CODE>
>}
>#endif
>
><OPCODE> is an opcode name (ZEN_NOP, ZEND_ADD, :)
><OP1_TYPES> & <OP2_TYPES> are masks for allowed operand op_types. Specializer
>will generate code only for defined combination of types. You can also use
>M_ANY mask to disable specialization according operand's op_type.
><HANDLER'S CODE> is a handler's code itself. For most handlers it stills the
>same as in old zend_execute.c, but now it uses macros to access opcode 
>operands
>and some internal executor data.
>
>You can see the conformity of new macros to old code in the following list:
>
>EXECUTE_DATA
>         execute_data
>ZEND_VM_DISPATCH_TO_HANDLER(<OP>)
>         return <OP>_helper(ZEND_OPCODE_HANDLER_ARGS_PASSTHRU)
>ZEND_VM_DISPATCH_TO_HELPER(<NAME>)
>         return <NAME>(ZEND_OPCODE_HANDLER_ARGS_PASSTHRU)
>ZEND_VM_DISPATCH_TO_HELPER_EX(<NAME>,<PARAM>,<VAL>)
>         return <NAME>(<VAL>, ZEND_OPCODE_HANDLER_ARGS_PASSTHRU)
>ZEND_VM_CONTINUE()
>         return 0
>ZEND_VM_NEXT_OPCOD()
>         NEXT_OPCODE()
>ZEND_VM_SET_OPCODE(<TARGET>
>         SET_OPCODE(<TARGET>
>ZEND_VM_INC_OPCODE()
>         INC_OPCOD()
>ZEND_VM_RETURN_FROM_EXECUTE_LOOP()
>         RETURN_FROM_EXECUTE_LOOP()
>ZEND_VM_C_LABEL(<LABEL>):
>         <LABEL>:
>ZEND_VM_C_GOTO(<LABEL>)
>         goto <LABEL>
>OP<X>_TYPE
>         opline->op<X>.op_type
>GET_OP<X>_ZVAL_PTR(<TYPE>)
>         get_zval_ptr(&opline->op<X>, EX(Ts), &free_op<X>, <TYPE>)
>GET_OP<X>_ZVAL_PTR_PTR(<TYPE>)
>         get_zval_ptr_ptr(&opline->op<X>, EX(Ts), &free_op<X>, <TYPE>)
>GET_OP<X>_OBJ_ZVAL_PTR(<TYPE>)
>         get_obj_zval_ptr(&opline->op<X>, EX(Ts), &free_op<X>, <TYPE>)
>GET_OP<X>_OBJ_ZVAL_PTR_PTR(<TYPE>)
>         get_obj_zval_ptr_ptr(&opline->op<X>, EX(Ts), &free_op<X>, <TYPE>)
>IS_OP<X>_TMP_FREE()
>         IS_TMP_FREE(free_op<X>)
>FREE_OP<X>()
>         FREE_OP(free_op<X>)
>FREE_OP<X>_IF_VAR()
>         FREE_VAR(free_op<X>)
>FREE_OP<X>_VAR_PTR()
>         FREE_VAR_PTR(free_op<X>)
>
>If handler can receive control form some other handler it should be defined
>with macro ZEND_VM_HANDLER_EX() instead of ZEND_VM_HANDLER().
>
>The additional parameters of helpers (see ZEND_VM_DISPATCH_TO_HELPER_EX) mast
>be defined in the start of execute() function inside ZEND_VM_HELPER_VAR() 
>macro.
>
>zend_vm.h and zend_vm_spec.h are used for abstraction of execution method and
>operands specialization. They mainly contain macros that are used for
>compile-time specialization.
>
>You can switch specialization on/off with define/undefined of the ZEND_VM_SPEC
>in the start of zend.vm.h and select execution method by defining `ZEND_VM_KIND` 
>in the same place.
>
>--
>Zend Engine CVS Mailing List (http://cvs.php.net/)

---

## #12684 — John Coggeshall — 2004-09-09T18:04:42+00:00

URL: https://externals.io/message/12681#12684 · In reply to: #12681

Personally I would like to see the hooks for op-codes stay in place, I
think they offer a lot of possibilities for extensions.  Andi, what do
you mean "create the handler execution architecture"? I'm a little
confused to what you are referring to.

John

PS -- I hated the switch() method ;)



> FYI, some more information about the proposed changes.
> It's really not critical, because I think performance is much more 
> dependant on how the application is written, the database queries and so 
> on, but it's quite a nice system which gives us both opcode specialization 
> and other execution alternatives.
> I heard some are worried about not being able to hook into opcodes anymore. 
> I don't think that's really required (it wasn't in PHP 4) but if you feel 
> strongly about it, we could maybe always create the handler execution 
> architecture and allow you tell PHP (in your extensions like xdebug) to use 
> that method. It's a bit bloated and again, I don't think it's needed but it 
> could probably be done.
> (FYI: Probably the same people complained when I made the change from PHP 4 
> to PHP 5 from switch() to handler which was purely an architectural reason) 
> :) Just an interesting observation :)
> 
> Andi
> 
> > […]

---

## #12686 — Andi Gutmans — 2004-09-09T18:17:18+00:00

URL: https://externals.io/message/12681#12686 · In reply to: #12681

At 02:04 PM 9/9/2004 -0400, John Coggeshall wrote:
>Personally I would like to see the hooks for op-codes stay in place, I
>think they offer a lot of possibilities for extensions.  Andi, what do
>you mean "create the handler execution architecture"? I'm a little
>confused to what you are referring to.

I mean that what we have to day is the function handler dispatch 
architecture (i.e. what it is in PHP 5.0.x). In PHP 4, we had switch().
Again, I think the opcode hook could be solved for people who want to do so 
by having such a version floating around in the address space for 
extensions that want to use it. It's a bit more memory but it's memory that 
should be shared.

>PS -- I hated the switch() method ;)

It was definitely uglier and that's why I made the change but in many cases 
the "goto and/or switch" dispatch methods are faster.

Andi