前言
这一次，我围绕Hello World来展开Zend虚拟机的执行过程。Hello World的PHP版本:
? ? ?echo 'Hello World';
?>
前一篇文章聊到的词法分析阶段就会把上边的脚本分析出一个Token序列：
我们得到一个Token序列：T_OPEN_TAG, T_ECHO, T_CONSTANT_ENCAPSED_STRING, ';', T_CLOSE_TAG。但在Zend虚拟机执行的过程中，是怎么去分析这个Token序列的？
跟踪运行轨迹
我们还是从命令行入手，在$PHPSRC/sapi/cli/php_cli.c中的do_cli函数里边接收了命令行的参数输入（php -f HelloWorld.php表示执行HelloWorld.php文件）。
我们追踪到$PHPSRC/main/main.c里边有php_execute_script的定义，紧接着调用了zend_execute_scripts()
?EG(active_op_array) =?zend_compile_file(file_handle, type TSRMLS_CC); zend_execute(EG(active_op_array) TSRMLS_CC);
首先通过zend_compile_file把文件解析成opcode中间代码（这一步会经过词法语法分析），然后用zend_execute执行这个生成的中间代码（这里就是所谓的运行时）。
这里很像C语言的编译方式，先编译成汇编，然后再转成机器码，这里的opcode就类似C语言编译过程中生成的汇编。
还可以延伸出一个思路，因为每次解析PHP文件时，都需要经过词法语法分析得到对应的opcode，其实在脚本文件不变化的时候，生成的opcode也不需要变化，因此为了减少PHP脚本的执行时间，可以把脚本的opcode缓存起来（例如缓存在共享内存里边）。
我给出一个流程图，然后随着这个流程图，看看Zend做了些什么事情：
我们先看看如何编译出opcode的。
词法语法分析->opcode
start:
top_statement_list???? { zend_do_end_compilation(TSRMLS_C); }
;top_statement_list:
top_statement_list? { zend_do_extended_info(TSRMLS_C); } top_statement { HANDLE_INTERACTIVE(); }
|???? /* empty */
;top_statement:
statement????????????????????????????? { zend_verify_namespace(TSRMLS_C); }
;statement:
unticked_statement { DO_TICKS(); }
|???? T_STRING ':' { zend_do_label(&$1 TSRMLS_CC); }
;unticked_statement:
|???? T_ECHO echo_expr_list ';'echo_expr_list:
echo_expr_list ',' expr { zend_do_echo(&$3 TSRMLS_CC); }
|???? expr???????????????????????? { zend_do_echo(&$1 TSRMLS_CC); }
;
expr:
r_variable???????????????????????? { $$ = $1; }
|???? expr_without_variable????????? { $$ = $1; }
;
expr_without_variable:
|???? scalar??????????????????? { $$ = $1; }
scalar:
|???? common_scalar?????????????? { $$ = $1; }
;
common_scalar:
|???? T_CONSTANT_ENCAPSED_STRING???? { $$ = $1; }
;语法分析从start开始，自上而下的分析，一个PHP脚本就是对应一个top_statement_list，接着分成每一行一条语句statement，发现echo 'Hello World'是一条unticked_statement（留意一下echo_expr_list的声明，?我们还可以发现语法上是支持echo 'Hello', ' World'的）。最后递归到T_CONSTANT_ENCAPSED_STRING状态就结束了这一行的语法解析。在这里我们忽略掉编译原理在语法分析阶段是怎么去做回溯等等东西，我们关注一下Zend引擎自身的的问题。
在规则后边的块"{}"里边的代码就是用来处理扫描到此规则时的动作，可以看到echo的执行是调用了zend_do_echo函数的。在动作声明的块里边我们看到了$$, $1,$2,$3等，这些对应的就是该条规则里边的返回值，参数1，参数2……，这里的返回值以及参数都是YYSTYPE类型，这个类型在43行里边有定义：#define YYSTYPE znode。znode的定义在zend_compile.h里边：
留意到zend_op这个结构，于是跟踪发现这个就是最后每条语句对应的opcode结构了！！！！
opcode的结构跟汇编有很大的相似之处，一个操作符，两个操作数。
在Zend引擎中，每个opcode主要的东西就是那个handler，一会我们会看到Zend里边是怎么生成这个handler的。到了这里先Hold住一下，回过头，我们看一下Hello World这个例子生成的opcode是什么。
装上vld，然后运行：php -dvld.active=1 HelloWorld.php，我们就可以看到这个PHP文件编译出来的opcode列表了：
可以看到echo这个语句的opcode类型是ECHO，同时return没有返回值，只有一个操作数"Hello World"。
现在经过了语法分析，我们对每条语句都编译出了opcode，Zend就会把它放入一个op_array里边（其实就是一个opcode的列表）。
回过头我们看一下zend_do_echo做了什么事情：
首先通过get_next_op在当前的op_array的最后边生成一条opcode，然后设置其opcode类型是ZEND_ECHO，然后设置它的第一个参数op1，同时标记第二个参数op2是不需要使用的（unused的）。
经过了这么多步骤之后我们得到了一个op_array的列表，这个列表里边的每一条opcode都绑定了自己的类型，接着我们看一下每个opcode节点是如何绑定handler的。
zend_vm_def.h定义了ZEND_ECHO的handler，留意到这里的40，一会需要用到，因为echo的参数可以有几种：常量，变量等等，所以对应着不同的handler
在zend_vm_execute.h定义了opcode对应的所有的handler，我们只关注echo相关的handler，注意到其中的代码：
void zend_init_opcodes_handlers(void) { static const opcode_handler_t labels[] = {//40913行 ZEND_ECHO_SPEC_CONST_HANDLER,//41914行 ZEND_ECHO_SPEC_CONST_HANDLER, ZEND_ECHO_SPEC_CONST_HANDLER, ZEND_ECHO_SPEC_CONST_HANDLER, ZEND_ECHO_SPEC_CONST_HANDLER };
请花费短暂的时间先记住这里的labels以及行数。
发现了获取handler的方法最后边return语句的计算，根据前面说的echo的opcode是40（假设两个参数op1,op2的type都是0），于是乎其对应的handler就是：
zend_opcode_handlers[40*25+0*5+0*5] =?zend_opcode_handlers[1000] =?labels[1000] =?ZEND_ECHO_SPEC_CONST_HANDLER（怎么来的？因为：41914行-40913行-1=1000）。
虚拟机执行opcode
前边我们已经解释了zend_compile_file把一个脚本编译成一个opcode的list：
?EG(active_op_array) =?zend_compile_file(file_handle, type TSRMLS_CC); zend_execute(EG(active_op_array) TSRMLS_CC);
在这之后，Zend引擎用zend_execute执行返回的opcode。
我们定位到了zend_execute最后执行到Zend/zend_vm_execute.h的337行：
可以看到，虚拟机执行的时候会循环当前的opcode列表，然后调用每一行opcode的handler，根据handler返回值确定下一步做啥（例如函数调用等，以后再展开）。
在这篇文章中我们只关注跟Hello World相关的东西，我们前边知道echo的handler是ZEND_ECHO_SPEC_CONST_HANDLER，通过最后的定位你会发现其调用了：
zend_write = (zend_write_func_t) utility_functions->write_function;
这里的utility_functions里边包含了一些基础的handler，每个sapi接入层自己修改了这里的基础函数指针，例如在命令行模式下，最后调用到了
sapi_cli_single_write：
从源码中，我们看到了最后的写操作就是调用了write/fwrite写入到标准输出流（也即是终端屏幕上）。
结语
最后根据前边的过程，再展开一下流程图就是：
