ircmaxell
commented
5 years ago I've talked quite a bit about this with a few other people, and let me try to explain my hesitation.
The way I understand it, there are really only two ways I could make use of C-PHP's standard library. I could implement data structures identical (and therefore compatible) to C-PHP, such that calling a library function/method is as easy and performant as possible. Or the other option would be to build an "adapter" layer, which would expose the existing C-PHP data structures, but internally convert back and forth at the boundary.
The first I'm really not interested in, especially as that opens a ton of worms, especially around interoperability with different builds, and a whole lot of things that PHP doesn't have the tools to get around.
The adapter layer could work, but I fear that it's going to be performance critical for most use-cases, and even if it was there as a "help get going" standpoint, I would imagine the majority of the standard lib would need to be ported anyway. This is the direction that HHVM took. I would bypass FFI for it, since FFI adds a lot of overhead, and "just" code generate the native bindings anyway, since we do have a code-generator handy :)...
Though, there's also nothing requiring said adapter to be core to the engine. It could just be "another" extension that has access to the compiler, and can act as a bridge as necessary between them. So it wouldn't be too expensive to add, and would be fairly isolated...
So in the end, I can support doing it, as long as it was segmented off enough from the engine/core compilers.
I initially thought the usage of libffi was to call into the PHP standard library in compiled code, but from what I can tell by looking at the code, it seems that the approach being taken to the PHP standard library is rewriting it in PHP for this project in
ext/modules. This doesn't seem to be a scaleable approach because of both the size of the standard library, and the fact that there are some standard library functions which inherently need to make syscalls (fopen, fwrite, etc).You know far more about PHP internals than I do, but it seems to me that providing a light C wrapper with a stable ABI that smooths out the differences between C and PHP calling conventions and types, and then linking to the real PHP stdlib by using FFI to call into this wrapper would go a lot farther than the
ext/modules approach (if I understand it correctly..). As far as I know the "real" php engine isn't cleanly separated into libphp and phpvm, but I think this approach would still be possible with a PECL extension.