PHPPHP: a PHP VM in PHP
github.com
PHPPHP: a PHP VM in PHP
1–10 of 52 posts
Re: PHPPHP: a PHP VM in PHP
#2The FAQ has it right: For the love of god, why?!
(Sure, it's only a fun learning project, i get that)
Re: PHPPHP: a PHP VM in PHP
#3PHPPHP is well on its way to being a simple PHP command line debugger. To my knowledge there currently isn't a good tool for command line debugging on PHP.
Re: PHPPHP: a PHP VM in PHP
#4I thought this might be a bit similar to PyPy... turns out it's only similar in idea. But hey it looks fun, and as the author said, why not?
Re: PHPPHP: a PHP VM in PHP
#5I'm surprised this wasn't done earlier. It's actually a quite common practice for a language to eventually write a compiler for it in said language; this is called bootstrapping a compiler [1], and makes the language "self-hosted".
C is a notorious language in this case, and is the closest to the real chick-or-the-egg problem this is: how do you write a C compiler without a C compiler? C is often the lowest-level language compilers are written in, so in order to bootstrap a C compiler for a specific architecture / OS, you need to write the entire compiler in the target language (assembly).
You can still see the bootstrapping part well in GCC: when you compile a new version of GCC, you first compile the compiler using your old version (bootstrapping), and then re-compile the entire codebase again using your new version.
Nowadays, "real" compiler bootstrapping using assembly is hardly ever done. You can simply create a new architecture target for GCC in a different environment (for example, Linux), and compile GCC with your new environment as a target architecture on Linux. You then install this brand new compiler on your brand new OS, et voila: you skipped the nasty bit and have a working compiler for your new OS.
Re: PHPPHP: a PHP VM in PHP
#6I'm the author of this library. I figured I'd answer a couple of questions as to why I wrote this.
First, it was something that I always wanted to do. For no particular reason other than I wanted to do it. I knew it was possible, but possible and doing it are two very different things.
Second, it was far easier than I thought. The time to the initial commit (basic working VM) was only about 6 hours of work. So it's not like I spent a year building it...
Third, it could be a useful education tool. For me learning the intricacies of the Zend VM better (I know it fairly well, but knowing and building give two different amounts of knowledge). But also for teaching others how the VM works. By giving a PHP implementation reference, hopefully more people can understand how the C implementation works (they both operate off the same generic implementation at this point).
Fourth, it can enable certain interesting things. For example, 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).
Fifth, 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).
Sixth, it can be used to actually debug PHP code without working knowledge of GDB (and the underlying C structures). I wouldn't recommend this, as the chances of us getting it working 100% the same as the C implementation are practically 0, but it's a concept.
Seventh, it could wind up becoming a full implementation (like PYPY). If we can compile the implementation using HipHop, and do some other lower-level tricks, there's a chance we could achieve performance somewhere near the C implementation. I doubt it, but it's possible. Especially if we add a JIT component (or a way of rendering out to machine code certain opcodes)...
Eighth, why not?
Re: PHPPHP: a PHP VM in PHP
#7PHPPHP is well on its way to being a simple PHP command line debugger. To my knowledge there currently isn't a good tool for command line debugging on PHP.
xdebug exposes a gdbp interface which supports breakpoints, stepping, inspecting variables, etc. And you can use it with gdb or any GUI that supports gdbp, such as macgdbp.
EDIT: It does not expose a REPL though, which I suppose is what you meant?
Re: PHPPHP: a PHP VM in PHP
#8PHPPHP is well on its way to being a simple PHP command line debugger. To my knowledge there currently isn't a good tool for command line debugging on PHP.
phpsh[1] by Facebook is good. Ironically, it's written in Python.
Re: PHPPHP: a PHP VM in PHP
#9I'm the author of this library. I figured I'd answer a couple of questions as to why I wrote this. First, it was something that I always wanted to do. For no particular reason other than I wanted to do it. I knew it was possible, but possible and doing it are two very different things. Second, it was far easier than I thought. The time to the initial commit (basic working VM) was only about 6 hours of work. So it's n…
Nice. Your reasons all do make sense. Doing is learning. I will definitely check it out if only to learn more about Zend internals.
Maybe update the github readme with this? It would help a lot, IMO.
Re: PHPPHP: a PHP VM in PHP
#10I'm the author of this library. I figured I'd answer a couple of questions as to why I wrote this. First, it was something that I always wanted to do. For no particular reason other than I wanted to do it. I knew it was possible, but possible and doing it are two very different things. Second, it was far easier than I thought. The time to the initial commit (basic working VM) was only about 6 hours of work. So it's n…
Nice. Your reasons all do make sense. Doing is learning. I will definitely check it out if only to learn more about Zend internals. Maybe update the github readme with this? It would help a lot, IMO.
I've updated the readme with the above...
Thanks!!!