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