Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:12684 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 60980 invoked by uid 1010); 9 Sep 2004 18:07:40 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 60936 invoked from network); 9 Sep 2004 18:07:40 -0000 Received: from unknown (HELO mail.communityconnect.com) (209.10.169.57) by pb1.pair.com with SMTP; 9 Sep 2004 18:07:40 -0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.communityconnect.com (Postfix) with ESMTP id 1B5B06F6A8 for ; Thu, 9 Sep 2004 14:12:51 -0400 (EDT) Received: from mail.communityconnect.com ([127.0.0.1]) by localhost (cc18-2.web.gbx.ccops.us [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12694-09 for ; Thu, 9 Sep 2004 14:12:43 -0400 (EDT) Received: from [192.168.101.34] (cc240-0.web.gbx.ccops.us [10.30.0.240]) by mail.communityconnect.com (Postfix) with ESMTP id 494FA6F5E0 for ; Thu, 9 Sep 2004 14:12:43 -0400 (EDT) Reply-To: john@coggeshall.org To: internals@lists.php.net In-Reply-To: <5.1.0.14.2.20040909101402.02f6a650@127.0.0.1> References: <5.1.0.14.2.20040909101402.02f6a650@127.0.0.1> Content-Type: text/plain Message-ID: <1094753081.26977.22.camel@unix-101-34.hq.communityconnect.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Thu, 09 Sep 2004 14:04:42 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mail.communityconnect.com Subject: Re: [PHP-DEV] Fwd: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / README.ZEND_VM From: john@coggeshall.org (John Coggeshall) 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" > >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 _SPEC() OPDEF(, , ) > >#if HAVE_OP() > >ZEND_VM_HANDLER() > >{ > > > >} > >#endif > > > > is an opcode name (ZEN_NOP, ZEND_ADD, :) > > & 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. > > 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() > > return _helper(ZEND_OPCODE_HANDLER_ARGS_PASSTHRU) > >ZEND_VM_DISPATCH_TO_HELPER() > > return (ZEND_OPCODE_HANDLER_ARGS_PASSTHRU) > >ZEND_VM_DISPATCH_TO_HELPER_EX(,,) > > return (, ZEND_OPCODE_HANDLER_ARGS_PASSTHRU) > >ZEND_VM_CONTINUE() > > return 0 > >ZEND_VM_NEXT_OPCOD() > > NEXT_OPCODE() > >ZEND_VM_SET_OPCODE( > > SET_OPCODE( > >ZEND_VM_INC_OPCODE() > > INC_OPCOD() > >ZEND_VM_RETURN_FROM_EXECUTE_LOOP() > > RETURN_FROM_EXECUTE_LOOP() > >ZEND_VM_C_LABEL(