本文内容年夜局部翻译自Getting into the Zend Execution engine (PHP 5)，并做了一些调整，原文基于PHP 5，本文基于PHP 7。
PHP : 一门诠释型言语
PHP被称为剧本言语或诠释型言语。为什么？ PHP言语不被间接编译为机械指令，而是编译为一种两头代码的方式，很显然它无奈间接正在CPU上执行。 以是PHP的执行需求正在过程级虚构机上（见Virtual machine中的Process virtual machines，下文简称虚构机）。
PHP言语，包罗其余的诠释型言语，实际上是一个跨平台的被设计用来执行形象指令的顺序。PHP次要用于处理WEB开发相干的成绩。
诸如Java, Python, C#, Ruby, Pascal, Lua, Perl, Javascript等编程言语所编写的顺序，都需求正在虚构机上执行。虚构机能够经过JIT编译技巧将一局部虚构机指令编译为机械指令以进步功能。鸟哥曾经正在进行PHP退出JIT支持的开发了。
保举教程：《PHP教程》
应用诠释型言语的优点：
代码编写简略，可以疾速开发
主动的内存治理
形象的数据类型，顺序可移植性高
缺陷：
无奈间接地进行内存治理以及应用过程资本
比编译为机械指令的言语速率慢：通常需求更多的CPU周期来实现相反的义务（JIT试图减少差距，但永远不克不及齐全消弭）
形象了太多货色，以至于当顺序出成绩时，许多顺序员难以诠释其基本缘由
最初一条缺陷是作者之以是写这篇文章的缘由，作者感觉顺序员应该去理解一些底层的货色。
作者心愿可以经过这篇文章向读者批注白PHP是若何运转的。本文所提到的对于PHP虚构机的常识一样能够使用于其余诠释型言语。通常，没有同虚构机完成上的最年夜没有同点正在于：能否应用JIT、并行的虚构机指令（普通应用多线程完成，PHP不应用这一技巧）、内存治理/渣滓收受接管算法。
Zend虚构机分为两年夜局部：
编译：将PHP代码转换为虚构机指令（OPCode）
执行：执行天生的虚构机指令
本文没有会触及到编译局部，次要存眷Zend虚构机的执行引擎。PHP7版本的执行引擎做了一局部重构，使患上PHP代码的执行货仓旅馆愈加简略明晰，功能也失去了一些晋升。
本文以PHP 7.0.7为示例。
OPCode
维基百科关于OPCode的诠释：
Opcodes can also be found in so-called byte codes and other representations intended for a software interpreter rather than a hardware device. These software based instruction sets often employ slightly higher-level data types and operations than most hardware counterparts, but are nevertheless constructed along similar lines.
OPCode与ByteCode正在概念上是没有同的。
我的集体了解：OPCode作为一条指令，标明要怎样做，而ByteCode由一序列的OPCode/数据组成，标明要做甚么。以一个加法为例子，OPCode是通知执行引擎将参数1以及参数2相加，而ByteCode则通知执行引擎将45以及56相加。
参考：Difference between Opcode and Bytecode以及Difference between: Opcode, byte code, mnemonics, machine code and assembly
正在PHP中，Zend/zend_vm_opcodes.h源码文件列出了一切支持的OPCode。通常，每一个OPCode的名字都形容了其含意，比方：
ZEND_ADD：对两个操作数执行加法操作
ZEND_NEW：创立一个工具
ZEND_FETCH_DIM_R：读取操作数中某个维度的值，比方执行
echo $foo[0]语句时，需求猎取$foo数组索引为0的值
OPCode以zend_op构造体示意：
struct _zend_op {
const void *handler; /* 执行该OPCode的C函数 */
znode_op op1; /* 操作数1 */
znode_op op2; /* 操作数2 */
znode_op result; /* 后果 */
uint32_t extended_value; /* 额定的信息 */
uint32_t lineno; /* 该OPCode对应PHP源码所正在的行 */
zend_uchar opcode; /* OPCode对应的数值 */
zend_uchar op1_type; /* 操作数1类型 */
zend_uchar op2_type; /* 操作数2类型 */
zend_uchar result_type; /* 后果类型 */
};每一一条OPcode都以相反的形式执行：OPCode有其对应的C函数，执行该C函数时，可能会用到0、1或2个操作数（op1，op2），最初将后果存储正在result中，可能还会有一些额定的信息存储正在extended_value。
看下ZEND_ADD的OPCode长甚么样子，正在Zend/zend_vm_def.h源码文件中：
ZEND_VM_HANDLER(1, ZEND_ADD, CONST|TMPVAR|CV, CONST|TMPVAR|CV)
{
USE_OPLINE
zend_free_op free_op1, free_op2;
zval *op1, *op2, *result;
op1 = GET_OP1_ZVAL_PTR_UNDEF(BP_VAR_R);
op2 = GET_OP2_ZVAL_PTR_UNDEF(BP_VAR_R);
if (EXPECTED(Z_TYPE_INFO_P(op1) == IS_LONG)) {
if (EXPECTED(Z_TYPE_INFO_P(op2) == IS_LONG)) {
result = EX_VAR(opline->result.var);
fast_long_add_function(result, op1, op2);
ZEND_VM_NEXT_OPCODE();
} else if (EXPECTED(Z_TYPE_INFO_P(op2) == IS_DOUBLE)) {
result = EX_VAR(opline->result.var);
ZVAL_DOUBLE(result, ((double)Z_LVAL_P(op1)) + Z_DVAL_P(op2));
ZEND_VM_NEXT_OPCODE();
}
} else if (EXPECTED(Z_TYPE_INFO_P(op1) == IS_DOUBLE)) {
if (EXPECTED(Z_TYPE_INFO_P(op2) == IS_DOUBLE)) {
result = EX_VAR(opline->result.var);
ZVAL_DOUBLE(result, Z_DVAL_P(op1) + Z_DVAL_P(op2));
ZEND_VM_NEXT_OPCODE();
} else if (EXPECTED(Z_TYPE_INFO_P(op2) == IS_LONG)) {
result = EX_VAR(opline->result.var);
ZVAL_DOUBLE(result, Z_DVAL_P(op1) + ((double)Z_LVAL_P(op2)));
ZEND_VM_NEXT_OPCODE();
}
}
SAVE_OPLINE();
if (OP1_TYPE == IS_CV && UNEXPECTED(Z_TYPE_INFO_P(op1) == IS_UNDEF)) {
op1 = GET_OP1_UNDEF_CV(op1, BP_VAR_R);
}
if (OP2_TYPE == IS_CV && UNEXPECTED(Z_TYPE_INFO_P(op2) == IS_UNDEF)) {
op2 = GET_OP2_UNDEF_CV(op2, BP_VAR_R);
}
add_function(EX_VAR(opline->result.var), op1, op2);
FREE_OP1();
FREE_OP2();
ZEND_VM_NEXT_OPCODE_CHECK_EXCEPTION();
}能够看出这并不是一个非法的C代码，能够把它算作代码模板。略微解读下这个代码模板：1 就是正在Zend/zend_vm_opcodes.h中define界说的ZEND_ADD的值；ZEND_ADD接纳两个操作数，假如两个操作数都为IS_LONG类型，那末就挪用fast_long_add_function（该函数外部应用汇编完成加法操作）；假如两个操作数，都为IS_DOUBLE类型或许1个是IS_DOUBLE类型，另1个是IS_LONG类型，那末就间接执行double的加法操作；假如存正在1个操作数没有是IS_LONG或IS_DOUBLE类型，那末就挪用add_function（比方两个数组做加法操作）；最初反省能否有异样接着执行下一条OPCode。
正在Zend/zend_vm_def.h源码文件中的内容实际上是OPCode的代码模板，正在该源文件的扫尾处能够看到这样一段正文：
/* If you change this file, please regenerate the zend_vm_execute.h and * zend_vm_opcodes.h files by running: * php zend_vm_gen.php */
阐明zend_vm_execute.h以及zend_vm_opcodes.h，实际上包罗zend_vm_opcodes.c中的C代码恰是从Zend/zend_vm_def.h的代码模板天生的。
操作数类型
每一个OPCode最多应用两个操作数：op1以及op2。每一个操作数代表着OPCode的“形参”。例如ZEND_ASSIGN OPCode将op2的值赋值给op1代表的PHP变量，而其result则不应用到。
操作数的类型（与PHP变量的类型没有同）决议了其含意和应用形式：
IS_CV：Compiled Variable，阐明该操作数是一个PHP变量
IS_TMP_VAR ：虚构机应用的暂时外部PHP变量，不克不及够正在没有同OPCode中复用（复用的这一点我其实不分明，还没去钻研过）
IS_VAR：虚构机应用的外部PHP变量，可以正在没有同OPCode中复用（复用的这一点我其实不分明，还没去钻研过）
IS_CONST：代表一个常量值
IS_UNUSED：该操作数不任何意思，疏忽该操作数
操作数的类型对功能优化以及内存治理很首要。当一个OPCode的Handler需求读写操作数时，会依据操作数的类型经过没有同的形式读写。
以加法规子，阐明操作数类型：
$a + $b; // IS_CV + IS_CV 1 + $a; // IS_CONST + IS_CV $$b + 3 // IS_VAR + IS_CONST !$a + 3; // IS_TMP_VAR + IS_CONST
OPCode Handler
咱们曾经晓得每一个OPCode Handler最多接纳2个操作数，而且会依据操作数的类型读写操作数的值。假如正在Handler中，经过switch判别类型，而后再读写操作数的值，那末对功能会有很年夜损耗，由于存正在太多的分支判别了（Why is it good to avoid instruction branching where possible?），以下面的伪代码所示：
int ZEND_ADD(zend_op *op1, zend_op *op2)
{
void *op1_value;
void *op2_value;
switch (op1->type) {
case IS_CV:
op1_value = read_op_as_a_cv(op1);
break;
case IS_VAR:
op1_value = read_op_as_a_var(op1);
break;
case IS_CONST:
op1_value = read_op_as_a_const(op1);
break;
case IS_TMP_VAR:
op1_value = read_op_as_a_tmp(op1);
break;
case IS_UNUSED:
op1_value = NULL;
break;
}
/* ... same thing to do for op2 .../
/* do something with op1_value and op2_value (perform a math addition ?) */
}要晓得OPCode Handler正在PHP执行进程中是会被挪用不计其数次的，以是正在Handler中对op一、op2做类型判别，对功能其实不好。
从新看下ZEND_ADD的代码模板：
ZEND_VM_HANDLER(1, ZEND_ADD, CONST|TMPVAR|CV, CONST|TMPVAR|CV)
这阐明ZEND_ADD接纳op1以及op2为CONST或TMPVAR或CV类型的操作数。
后面曾经提到zend_vm_execute.h以及zend_vm_opcodes.h中的C代码是从Zend/zend_vm_def.h的代码模板天生的。经过查看zend_vm_execute.h，能够看到每一个OPCode对应的Handler（C函数），年夜局部OPCode会对应多个Handler。以ZEND_ADD为例：
static ZEND_OPCODE_HANDLER_RET ZEND_FASTCALL ZEND_ADD_SPEC_CONST_CONST_HANDLER(ZEND_OPCODE_HANDLER_ARGS) static ZEND_OPCODE_HANDLER_RET ZEND_FASTCALL ZEND_ADD_SPEC_CONST_CV_HANDLER(ZEND_OPCODE_HANDLER_ARGS) static ZEND_OPCODE_HANDLER_RET ZEND_FASTCALL ZEND_ADD_SPEC_CONST_TMPVAR_HANDLER(ZEND_OPCODE_HANDLER_ARGS) static ZEND_OPCODE_HANDLER_RET ZEND_FASTCALL ZEND_ADD_SPEC_CV_CONST_HANDLER(ZEND_OPCODE_HANDLER_ARGS) static ZEND_OPCODE_HANDLER_RET ZEND_FASTCALL ZEND_ADD_SPEC_CV_CV_HANDLER(ZEND_OPCODE_HANDLER_ARGS) static ZEND_OPCODE_HANDLER_RET ZEND_FASTCALL ZEND_ADD_SPEC_CV_TMPVAR_HANDLER(ZEND_OPCODE_HANDLER_ARGS) static ZEND_OPCODE_HANDLER_RET ZEND_FASTCALL ZEND_ADD_SPEC_TMPVAR_CONST_HANDLER(ZEND_OPCODE_HANDLER_ARGS) static ZEND_OPCODE_HANDLER_RET ZEND_FASTCALL ZEND_ADD_SPEC_TMPVAR_CV_HANDLER(ZEND_OPCODE_HANDLER_ARGS) static ZEND_OPCODE_HANDLER_RET ZEND_FASTCALL ZEND_ADD_SPEC_TMPVAR_TMPVAR_HANDLER(ZEND_OPCODE_HANDLER_ARGS)
ZEND_ADD的op1以及op2的类型都有3种，以是一共天生了9个Handler，每一个Handler的定名标准：ZEND_{OPCODE-NAME}_SPEC_{OP1-TYPE}_{OP2-TYPE}_HANDLER()。正在编译阶段，操作数的类型是已知的，也就确定了每一个编译进去的OPCode对应的Handler了。
那末这些Handler之间有甚么没有同呢？最年夜的没有同应该就是猎取操作数的形式：
static ZEND_OPCODE_HANDLER_RET ZEND_FASTCALL ZEND_ADD_SPEC_CONST_CONST_HANDLER(ZEND_OPCODE_HANDLER_ARGS)
{
USE_OPLINE
zval *op1, *op2, *result;
op1 = EX_CONSTANT(opline->op1);
op2 = EX_CONSTANT(opline->op2);
if (EXPECTED(Z_TYPE_INFO_P(op1) == IS_LONG)) {
/* 省略 */
} else if (EXPECTED(Z_TYPE_INFO_P(op1) == IS_DOUBLE)) {
/* 省略 */
}
SAVE_OPLINE();
if (IS_CONST == IS_CV && UNEXPECTED(Z_TYPE_INFO_P(op1) == IS_UNDEF)) { //<-------- 这局部代码会被编译器优化掉
op1 = GET_OP1_UNDEF_CV(op1, BP_VAR_R);
}
if (IS_CONST == IS_CV && UNEXPECTED(Z_TYPE_INFO_P(op2) == IS_UNDEF)) { //<-------- 这局部代码会被编译器优化掉
op2 = GET_OP2_UNDEF_CV(op2, BP_VAR_R);
}
add_function(EX_VAR(opline->result.var), op1, op2);
ZEND_VM_NEXT_OPCODE_CHECK_EXCEPTION();
}
static ZEND_OPCODE_HANDLER_RET ZEND_FASTCALL ZEND_ADD_SPEC_CONST_CV_HANDLER(ZEND_OPCODE_HANDLER_ARGS)
{
USE_OPLINE
zval *op1, *op2, *result;
op1 = EX_CONSTANT(opline->op1);
op2 = _get_zval_ptr_cv_undef(execute_data, opline->op2.var); //<-------- op2的猎取形式与下面的CONST没有同
if (EXPECTED(Z_TYPE_INFO_P(op1) == IS_LONG)) {
/* 省略 */
} else if (EXPECTED(Z_TYPE_INFO_P(op1) == IS_DOUBLE)) {
/* 省略 */
}
SAVE_OPLINE();
if (IS_CONST == IS_CV && UNEXPECTED(Z_TYPE_INFO_P(op1) == IS_UNDEF)) { //<-------- 这局部代码会被编译器优化掉
op1 = GET_OP1_UNDEF_CV(op1, BP_VAR_R);
}
if (IS_CV == IS_CV && UNEXPECTED(Z_TYPE_INFO_P(op2) == IS_UNDEF)) { //<-------- IS_CV == IS_CV && 也会被编译器优化掉
op2 = GET_OP2_UNDEF_CV(op2, BP_VAR_R);
}
add_function(EX_VAR(opline->result.var), op1, op2);
ZEND_VM_NEXT_OPCODE_CHECK_EXCEPTION();
}OPArray
OPArray是指一个蕴含许多要被程序执行的OPCode的数组，以下图：
OPArray由构造体_zend_op_array示意：
struct _zend_op_array {
/* Co妹妹on elements */
/* 省略 */
/* END of co妹妹on elements */
/* 省略 */
zend_op *opcodes; //<------ 存储着OPCode的数组
/* 省略 */
};正在PHP中，每一个PHP用户函数或许PHP剧本、通报给eval()的参数，会被编译为一个OPArray。
OPArray中蕴含了许多动态的信息，可以协助执行引擎更高效地执行PHP代码。局部首要的信息以下：
以后剧本的文件名，OPArray对应的PHP代码正在剧本中肇始以及终止的行号
/**的代码正文信息
refcount援用计数，OPArray是可同享的
try-catch-finally的跳转信息
break-continue的跳转信息
以后作用域一切PHP变量的称号
函数顶用到的动态变量
literals（字面量），编译阶段已知的值，例如字符串“foo”，或许整数42
运转时缓存槽，引擎会缓存一些后续执行需求用到的货色
一个简略的例子：
$a = 8; $b = 'foo'; echo $a + $b;
OPArray中的局部成员其内容以下：
OPArray蕴含的信息越多，即正在编译时期只管即便的将已知的信息较量争论好存储到OPArray中，执行引擎就可以更高效地执行。咱们能够看到每一个字面量都曾经被编译为zval并存储到literals数组中（你可能发现这里多了一个整型值1，其实这是用于ZEND_RETURN OPCode的，PHP文件的OPArray默许会前往1，但函数的OPArray默许前往null）。OPArray所应用到的PHP变量的名字信息也被编译为zend_string存储到vars数组中，编译后的OPCode则存储到opcodes数组中。
OPCode的执行
OPCode的执行是经过一个while轮回去做的：
//删除了了预解决语句
ZEND_API void execute_ex(zend_execute_data *ex)
{
DCL_OPLINE
const zend_op *orig_opline = opline;
zend_execute_data *orig_execute_data = execute_data;
execute_data = ex;
LOAD_OPLINE();
while (1) {
((opcode_handler_t)OPLINE->handler)(ZEND_OPCODE_HANDLER_ARGS_PASSTHRU); //执行OPCode对应的C函数
if (UNEXPECTED(!OPLINE)) { //以后OPArray执行完
execute_data = orig_execute_data;
opline = orig_opline;
return;
}
}
zend_error_noreturn(E_CORE_ERROR, "Arrived at end of main loop which shouldn't happen");
}那末是若何切换到下一个OPCode去执行的呢？每一个OPCode的Handler中城市挪用到一个宏：
#define ZEND_VM_NEXT_OPCODE_EX(check_exception, skip) \
CHECK_SYMBOL_TABLES() \
if (check_exception) { \
OPLINE = EX(opline) + (skip); \
} else { \
OPLINE = opline + (skip); \
} \
ZEND_VM_CONTINUE()该宏会把以后的opline+skip（skip一般为1），将opline指向下一条OPCode。opline是一个全局变量，指向以后执行的OPCode。
额定的一些货色
编译器优化
正在Zend/zend_vm_execute.h中，会看到以下希奇的代码：
static ZEND_OPCODE_HANDLER_RET ZEND_FASTCALL ZEND_INIT_ARRAY_SPEC_CONST_CONST_HANDLER(ZEND_OPCODE_HANDLER_ARGS)
{
/* 省略 */
if (IS_CONST == IS_UNUSED) {
ZEND_VM_NEXT_OPCODE();
#if 0 || (IS_CONST != IS_UNUSED)
} else {
ZEND_VM_TAIL_CALL(ZEND_ADD_ARRAY_ELEMENT_SPEC_CONST_CONST_HANDLER(ZEND_OPCODE_HANDLER_ARGS_PASSTHRU));
#endif
}
}你可能会对if (IS_CONST == IS_UNUSED)以及#if 0 || (IS_CONST != IS_UNUSED)感应希奇。看下其对应的模板代码：
ZEND_VM_HANDLER(71, ZEND_INIT_ARRAY, CONST|TMP|VAR|UNUSED|CV, CONST|TMPVAR|UNUSED|CV)
{
zval *array;
uint32_t size;
USE_OPLINE
array = EX_VAR(opline->result.var);
if (OP1_TYPE != IS_UNUSED) {
size = opline->extended_value >> ZEND_ARRAY_SIZE_SHIFT;
} else {
size = 0;
}
ZVAL_NEW_ARR(array);
zend_hash_init(Z_ARRVAL_P(array), size, NULL, ZVAL_PTR_DTOR, 0);
if (OP1_TYPE != IS_UNUSED) {
/* Explicitly initialize array as not-packed if flag is set */
if (opline->extended_value & ZEND_ARRAY_NOT_PACKED) {
zend_hash_real_init(Z_ARRVAL_P(array), 0);
}
}
if (OP1_TYPE == IS_UNUSED) {
ZEND_VM_NEXT_OPCODE();
#if !defined(ZEND_VM_SPEC) || (OP1_TYPE != IS_UNUSED)
} else {
ZEND_VM_DISPATCH_TO_HANDLER(ZEND_ADD_ARRAY_ELEMENT);
#endif
}
}php zend_vm_gen.php正在天生zend_vm_execute.h时，会把OP1_TYPE交换为op1的类型，从而天生这样子的代码：if (IS_CONST == IS_UNUSED)，但C编译器会把这些代码优化掉。
自界说Zend执行引擎的天生
zend_vm_gen.php支持传入参数--without-specializer，当应用该参数时，每一个OPCode只会天生一个与之对应的Handler，该Handler中会对操作数做类型判别，而后再对操作数进行读写。
另外一个参数是--with-vm-kind=CALL|SWITCH|GOTO，CALL是默许参数。
后面已提到执行引擎是经过一个while轮回执行OPCode，每一个OPCode中将opline添加1（通常状况下），而后回到while轮回中，持续执行下一个OPCode，直到遇到ZEND_RETURN。
假如应用GOTO执行战略：
/* GOTO战略下，execute_ex是一个超年夜的函数 */
ZEND_API void execute_ex(zend_execute_data *ex)
{
/* 省略 */
while (1) {
/* 省略 */
goto *(void**)(OPLINE->handler);
/* 省略 */
}
/* 省略 */
}这里的goto并无间接应用符号名，实际上是goto一个非凡的用法：Labels as Values。
执行引擎中的跳转
当PHP剧本中呈现if语句时，是若何跳转到相应的OPCode而后持续执行的？看上面简略的例子：
$a = 8;
if ($a == 9) {
echo "foo";
} else {
echo "bar";
}
number of ops: 7
compiled vars: !0 = $a
line #* E I O op fetch ext return operands
-------------------------------------------------------------------------------------
2 0 E > ASSIGN !0, 8
3 1 IS_EQUAL ~2 !0, 9
2 > JMPZ ~2, ->5
4 3 > ECHO 'foo'
4 > JMP ->6
6 5 > ECHO 'bar'
6 > > RETURN 1当$a != 9时，JMPZ会使以后执行跳转到第5个OPCode，不然JMP会使以后执行跳转到第6个OPCode。其实就是对以后的opline赋值为跳转指标OPCode的地点。
一些功能Tips
这局部内容将展现若何经过查看天生的OPCode优化PHP代码。
echo a concatenation
示例代码：
$foo = 'foo'; $bar = 'bar'; echo $foo . $bar;
OPArray：
number of ops: 5
compiled vars: !0 = $foo, !1 = $bar
line #* E I O op fetch ext return operands
-------------------------------------------------------------------------------------
2 0 E > ASSIGN !0, 'foo'
3 1 ASSIGN !1, 'bar'
5 2 CONCAT ~4 !0, !1
3 ECHO ~4
4 > RETURN 1$a以及$b的值会被ZEND_CONCAT衔接后存储到一个暂时变量~4中，而后再echo输入。
CONCAT操作需求调配一块暂时的内存，而后做内存拷贝，echo输入后，又要收受接管这块暂时内存。假如把代码改成以下可消弭CONCAT：
$foo = 'foo'; $bar = 'bar'; echo $foo , $bar;
OPArray：
number of ops: 5
compiled vars: !0 = $foo, !1 = $bar
line #* E I O op fetch ext return operands
-------------------------------------------------------------------------------------
2 0 E > ASSIGN !0, 'foo'
3 1 ASSIGN !1, 'bar'
5 2 ECHO !0
3 ECHO !1
4 > RETURN 1define()以及const
PHP 5.3引入了const要害字。
简略地说：
define()是一个函数挪用
conast是要害字，没有会孕育发生函数挪用，要比define()轻量许多
define('FOO', 'foo');
echo FOO;
number of ops: 7
compiled vars: none
line #* E I O op fetch ext return operands
-------------------------------------------------------------------------------------
2 0 E > INIT_FCALL 'define'
1 SEND_VAL 'FOO'
2 SEND_VAL 'foo'
3 DO_ICALL
3 4 FETCH_CONSTANT ~1 'FOO'
5 ECHO ~1
6 > RETURN 1假如应用const：
const FOO = 'foo';
echo FOO;
number of ops: 4
compiled vars: none
line #* E I O op fetch ext return operands
-------------------------------------------------------------------------------------
2 0 E > DECLARE_CONST 'FOO', 'foo'
3 1 FETCH_CONSTANT ~0 'FOO'
2 ECHO ~0
3 > RETURN 1但是const正在应用上有一些限度：
const要害字界说常量必需处于最顶真个作用区域，这就象征着不克不及正在函数内，轮回内和if语句以内用const 来界说常量
const的操作数必需为IS_CONST类型
静态函数挪用
只管即便没有要应用静态的函数名去挪用函数：
function foo() { }
foo();
number of ops: 4
compiled vars: none
line #* E I O op fetch ext return operands
-------------------------------------------------------------------------------------
2 0 E > NOP
3 1 INIT_FCALL 'foo'
2 DO_UCALL
3 > RETURN 1NOP示意没有做任何操作，只是将以后opline指向下一条OPCode，编译器孕育发生这条指令是因为汗青缘由。为什么到PHP7还没有移除了它呢= =
看看应用静态的函数名去挪用函数：
function foo() { }
$a = 'foo';
$a();
number of ops: 5
compiled vars: !0 = $a
line #* E I O op fetch ext return operands
-------------------------------------------------------------------------------------
2 0 E > NOP
3 1 ASSIGN !0, 'foo'
4 2 INIT_DYNAMIC_CALL !0
3 DO_FCALL 0
4 > RETURN 1没有同点正在于INIT_FCALL以及INIT_DYNAMIC_CALL，看下两个函数的源码：
static ZEND_OPCODE_HANDLER_RET ZEND_FASTCALL ZEND_INIT_FCALL_SPEC_CONST_HANDLER(ZEND_OPCODE_HANDLER_ARGS)
{
USE_OPLINE
zval *fname = EX_CONSTANT(opline->op2);
zval *func;
zend_function *fbc;
zend_execute_data *call;
fbc = CACHED_PTR(Z_CACHE_SLOT_P(fname)); /* 看下能否曾经正在缓存中了 */
if (UNEXPECTED(fbc == NULL)) {
func = zend_hash_find(EG(function_table), Z_STR_P(fname)); /* 依据函数名查找函数 */
if (UNEXPECTED(func == NULL)) {
SAVE_OPLINE();
zend_throw_error(NULL, "Call to undefined function %s()", Z_STRVAL_P(fname));
HANDLE_EXCEPTION();
}
fbc = Z_FUNC_P(func);
CACHE_PTR(Z_CACHE_SLOT_P(fname), fbc); /* 缓存查找后果 */
}
call = zend_vm_stack_push_call_frame_ex(
opline->op1.num, ZEND_CALL_NESTED_FUNCTION,
fbc, opline->extended_value, NULL, NULL);
call->prev_execute_data = EX(call);
EX(call) = call;
ZEND_VM_NEXT_OPCODE();
}
static ZEND_OPCODE_HANDLER_RET ZEND_FASTCALL ZEND_INIT_DYNAMIC_CALL_SPEC_CV_HANDLER(ZEND_OPCODE_HANDLER_ARGS)
{
/* 200多行代码，就没有贴进去了，会依据CV的类型（字符串、工具、数组）做没有同的函数查找 */
}很显然INIT_FCALL相比INIT_DYNAMIC_CALL要轻量许多。
类的提早绑定
简略地说，类A承继类B，类B最佳先于类A被界说。
class Bar { }
class Foo extends Bar { }
number of ops: 4
compiled vars: none
line #* E I O op fetch ext return operands
-------------------------------------------------------------------------------------
2 0 E > NOP
3 1 NOP
2 NOP
3 > RETURN 1从天生的OPCode能够看出，上述PHP代码正在运转时，执行引擎没有需求做任何操作。类的界说是比拟耗功能的工作，例如解析类的承继关系，将父类的办法/属性增加出去，但编译器曾经做完了这些沉重的工作。
假如类A先于类B被界说：
class Foo extends Bar { }
class Bar { }
number of ops: 4
compiled vars: none
line #* E I O op fetch ext return operands
-------------------------------------------------------------------------------------
2 0 E > FETCH_CLASS 0 :0 'Bar'
1 DECLARE_INHERITED_CLASS '%00foo%2Fhome%2Froketyyang%2Ftest.php0x7fb192b7101f', 'foo'
3 2 NOP
3 > RETURN 1这里界说了Foo承继自Bar，但当编译器读取到Foo的界说时，编译器其实不晓得任何干于Bar的状况，以是编译器就天生相应的OPCode，使其界说提早到执行时。正在一些其余的静态类型的言语中，可能会孕育发生谬误：Parse error : class not found。
除了了类的提早绑定，像接口、traits都存正在提早绑定耗功能的成绩。
关于定位PHP功能成绩，通常都是先用xhprof或xdebug profile进行定位，需求经过查看OPCode定位功能成绩的场景仍是比拟少的。
总结
心愿经过这篇文章，能让你理解到PHP虚构机大抵是若何工作的。详细opcode的执行，和函数挪用触及到的上下文切换，有许多细节性的货色，限于本文篇幅，正在另外一篇文章：PHP 7 中函数挪用的完成进行解说。
保举相干文章：《linux零碎教程》
以上就是理解甚么是PHP7虚构机的具体内容，更多请存眷资源魔其它相干文章！
标签： php php7开发教程 php7开发资料 php7开发自学
相关文章
抱歉，评论功能暂时关闭!