PHPPHP这是一个用@nikic开发的PHP AST generating parser（https://github.com/nikic/PHP-Parser）编写的基础虚拟实现
检出操作代码，看看到目前为止支持什么：https://github.com/ircmaxell/PHPPHP
目前为止，已经支持：函数（定义和调用）、if语句（基本的bool操作符），一些基本的变量操作……
使用
你可以在命令行或者终端重运行php.php文件，就像：
php php.php -r "var_dump('foo');"
或者编写一个文件
php php.php ../test.php
它仅仅支持相对的文件，不包括include路径解析
为何要编写它，这里有许多理由，这里列举了一二：
1.这是我经常希望做的一件事，我希望做的没有目的、没有理由，我知道这是可能的，但是说和做是两码事；
2.比我想想的简单，从我提交初始化代码（基本的VM）到现在只花费了6个小时，并非花费了1年时间构件它；
3.这个或许是一个教育教学的工具，对我来说是学习Zend VM会更好（我知道这样不错，但知道、构件会获取更多不同的知识）。同样告诉其他人VM是如何工作的。通过给出一个PHP开发的例子，能够帮助更多人了解C实现的是如何工作的（实际上在实现方面他们是相同的）；
4.它可以使很多事情变得非常有趣，例如, we could hypothetically build an Opcode optimizer in PHP which parses the generated opcodes and optimizes things (removing redundant opcodes, statically compiling static expressions, etc). Then, we could build a PECL extension that would render those optimized opcodes directly into APC cache (or some other opcode cache mechanism).
5.It can be used to quickly mock up future functionality changes. Consider that it's easier to alter a PHP VM simply because you don't need to worry about memory management at all. So whipping up a POC for a significant feature should be a lot easier in PHP than C (at least for many non-full-time C developers).
6.这会让我们调试 PHP代码不再需要GDB (C结构的方式)知识. 我不推荐这么去做, as the chances of us getting it working 100% the same as the C implementation are practically 0, 但他只是一个概念.
7.它可能称为一个完整的实现 (就像 PYPY). 如果我们使用HipHop来编译实现，并且我们做一些低级别的优化，这些改变将会像修改C的实现性能提升一样。虽然我怀疑，但这个还是有可能的，特别是我们添加了一个JIT组件（或一种呈现出为机器代码的某些操作码...
8.为何不这样?
