Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:45287 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 54781 invoked from network); 16 Aug 2009 19:19:06 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 16 Aug 2009 19:19:06 -0000 Authentication-Results: pb1.pair.com header.from=php@stefan-marr.de; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=php@stefan-marr.de; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain stefan-marr.de from 85.88.12.247 cause and error) X-PHP-List-Original-Sender: php@stefan-marr.de X-Host-Fingerprint: 85.88.12.247 toolslave.net Received: from [85.88.12.247] ([85.88.12.247:33019] helo=uhweb12247.united-hoster.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id FD/48-15479-9AB588A4 for ; Sun, 16 Aug 2009 15:19:05 -0400 Received: from cust194-138.dsl.versadsl.be ([62.166.194.138] helo=[192.168.0.10]) by uhweb12247.united-hoster.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from ) id 1MclFn-0000wJ-PL; Sun, 16 Aug 2009 21:18:59 +0200 Mime-Version: 1.0 (Apple Message framework v1074) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes In-Reply-To: Date: Sun, 16 Aug 2009 21:18:51 +0200 Cc: internals@lists.php.net Content-Transfer-Encoding: 7bit Message-ID: References: <36262A27-538B-487C-9C36-10E18DDBED22@stefan-marr.de> To: Paul Biggar X-Mailer: Apple Mail (2.1074) Subject: Re: [PHP-DEV] Design of the Zend Engine's Instruction Set From: php@stefan-marr.de (Stefan Marr) > I think they are pulled out of thin air. More specifically, I think > there are optimizations heaped upon optimizations heaped upon an > initial implementation. It seems that each new release of PHP has a > small speed improvement based on some optimization performed, but that > there has been no major rearchitecture since the addition of a > bytecode based interpreter in PHP 4. Well, sure, but thats usual evolution. Not a problem specific to PHP. Was more curious about the first design. > One thing I do find interesting is that the register machine nature of > PHP comes from an optimization called "compiled variables". CVs point > to symbol-table entries, but without them, I'm not sure whether we > would still call PHP a register machine. Any thoughts? Well, actually, I would include the temp vars also as a reason to name it a register-memory machine model. They are accessed by using an explicit name i.e. an index into the "Ts" array. Thus, it is definitely not an implicit stack. The question would be only, is it useful to go further and interpret this structure as an infinite number of registers which would be equivalent with memory. Then it could be considered to be a memory-to-memory architecture. But usually these kind of architectures have the property of only one type of addresses, which does not hold for PHP. Best regards Stefan