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