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 ;)


On Thu, 2004-09-09 at 13:17, Andi Gutmans wrote:
> 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" <[EMAIL PROTECTED]>
> >To: [EMAIL PROTECTED]
> >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/)
> >To unsubscribe, visit: http://www.php.net/unsub.php

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to