3 ms·
I'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 p
by ircmaxell 14y ago
I'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?
- efbe 14y agoWith this brillant project, is it the end of nodejs hype ?
- aioprisan 14y agoThis has nothing to do with nodejs or any hype around it. Read the parent's comments on why he built this.
- benwerd 14y agoSerious achievement. Well done!
- lucian303 14y agoNice. 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.
- ircmaxell 14y agoI've updated the readme with the above... Thanks!!!
- camus 14y agoBrilliant , PHP source code will need a loads of cleaning one day or another anyway , could help making changes to the language ...
- lotyrin 14y agoAnyone who could run a non-conforming PHP could just run something better. A conforming, but massively improved (read: JIT) PHP interpreter is really the only way forward for us who are so unfortunate. The good news is that there are starting to be viable options in that space.
- lucian303 14y agoAnd what are the exact problems with the current interpreter?
- deleted 14y ago[deleted]
- deleted 14y ago[deleted]