Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:45291
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 63.205.162.117 as permitted sender)
Message-ID: <4A88DE3E.7020307@zend.com>
Date: Sun, 16 Aug 2009 21:36:14 -0700
Organization: Zend Technologies
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Stefan Marr <php@stefan-marr.de>
CC: internals@lists.php.net
References: <A66655EC-5573-4D3E-A515-C03105DD7EEE@stefan-marr.de>
In-Reply-To: <A66655EC-5573-4D3E-A515-C03105DD7EEE@stefan-marr.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Design of the Zend Engine's Instruction Set
From: stas@zend.com (Stanislav Malyshev)

Hi!

> So, the basic design of the Zend Engine is a
> a stack-based interpreter for a fixed length
> instruction set (76byte on a 32bit architecture),

Not exactly stack-based, it's more register-based. Number of registers 
is not limited, even though most of them aren't used simultaneously.

> Instructions encode:
>  - a line number
>  - a function pointer to the actual handler which is
>    used to execute it
>  - two operands, which encode constant values,
>    object references, jump addresses,
>    or pointer to other functions
>  - 64 bit for an extended operand value
>  - a field for results, which is use for some
>    operations return values.

The basic model is that each operation works on 2 operands and 
(optionally) returns result. Operands can be either constants, temp 
variables or in-memory variables, or sometimes a number which is used as 
jump point, etc.
This model can be extended for some opcodes by using either extended 
operand or additional opcode, if operation semantics does not fit in one 
opcode (e.g. opcode generated by $a->b["x"] would have 4 operands - $a, 
"b", "x" and how the expression is used - read/write/test, etc.)

> However, its not a simple, single stack model,
> but uses several purpose-specific stacks.

Stacks indeed are used for function calls, but this is just an 
implementation detail.

> What I am not so sure about is especially the
> semantics of the result field and the pointer
> to the other function (op_array).

result field is a result of an operation, so if you have $a = $b + $c, 
then ADD opcode which would add content of $b and $c would use "result" 
field to store the value, which will then be used by ASSIGN opcode to 
assign the result to $a.

As for op_array, I assume you are referring to op_array field in znode 
union. I don't think this one is used by the engine at runtime, it's a 
compiler utility field.

> I am also not really sure with these complexity,
> whether is not actually some kind of abstract syntax
> tree instead of a instruction set like Java
> bytecode. Thats not a technical problem, but merely
> an academic question to categorize/characterize PHP.

I think it's more like bytecode, indeed. Even though the instructions 
are pretty high-level so with some effort you probably could build a 
syntax tree out of it.
-- 
Stanislav Malyshev, Zend Software Architect
stas@zend.com   http://www.zend.com/
(408)253-8829   MSN: stas@zend.com