On the PHPClasses.org site they've posted the latest episode of their "Lately in PHP" podcast series - Episode #30, "Will PHP6 Feature a JIT compiler?"

Now that Facebook made some progress with their PHP HipHop VM JIT compiler engine, some PHP core developers are considering having also a JIT compiler implementation of the official implementation based on LLVM, eventually in PHP 6. [...] They also commented on the first alpha release of PHP 5.5.0, proposals for having pure interfaces in the PHP core, the Facebook PHP JIT compiler enhancements, and the new system of levels and missions of the PHPClasses and JSClasses sites.

You can listen to this latest episode either through their in-page player, by downloading the mp3 or by subscribing to their feed. You can also watch the video of the recording as well.

On the Sankuru blog today the next post in the series about creating a compiler in PHP has been posted. In this latest tutorial he shows how to set up a plugin architecture for the compiler that allows you to quickly and easily extend it beyond its base functionality.

A plugin architecture allows multiple developers to work on the same application and let yet another person assemble their work later on. It allows the plugin developer to understand just his plugin API without having to understand all the details of the entire application.

He describes a few platforms that already have the concept of plugins including Joomla, Mediawiki and SugarCRM. He explains what a plugin architecture should be and what it shouldn't be. All of this is his first steps towards building a plugin-enabled compiler and virtual machine in PHP.

Improving on his last post about creating a bytecode compiler in PHP, the Sankuru blog has a new post in the series looking at extending the basic compiler to add support for if/while and do while logic.

In order to obtain a turing-complete programming language, that is, a language in which we can implement and execute any arbitrary algorithm, that is, that other turing-complete machines can execute too, we now need to add a way of (conditionally) branching, that is, the IF statement, and at least one way of repeating statements, that is the WHILE or the DO WHILE statements.

He includes a simple TL-based script as an end goal for the compiler to be able to execute and shows how to add rules for it to the lexer/parser. Rules for the "if" are relatively simple, but there's a hitch in dealing with embedded "while" statements he had to work around. The post ends with the bytecode results for the sample program and the resulting output from the compiled versions execution.

On the Sankuru blog there's a recent post looking at the construction of a simple bytecode compiler with a virtual machine as written in PHP (for Expression Language).

In my previous blog posts, I demonstrated how we can use the builtin PCRE library, to create a lexer in Php. I also showed how to use Bison-generated LALR1 parser tables in Php. In this blog post, I will re-use these lexing and parsing facilities to compile EL programs from within Php.

He uses his lexer/parser (available for download) in an example program that outputs some values and does some simple mathematical operations. There's sections detailing the Bison grammar used, execution stacks, callbacks and the bytecode it produces.

In a new post to his blog Brian Swan explains why the latest versions of PHP (the 5.3.x series) are faster now on Windows than some previous versions have been. (Hint: updated technology can work wonders sometimes)

[Rasmus Lerdorf recently said at a Seattle meetup] "If you aren't running PHP 5.3 on Windows, you're lucky…because you have a 40% performance boost coming." He clarified this by saying that, with some help from Microsoft, improvements were made in PHP 5.3 that led to a 40% performance improvement of PHP on Windows. Because he didn't go into the details of why this performance boost was realized, I got questions in email the next day asking about why.

The information in a borrowed slide (from a presentation by Pierre Joye) shows what the differences between the versions are - things like the use of a more modern compiler (VC9 vs VC6), calls to the Win32 API directly and better library management.

On the SitePoint PHP blog today there's a quick new post showing you how to create a Javascript compressor tool with PHP that uses the Closure Compiler from Google.

In my previous post, I discussed the Closure Compiler's REST API. In this article, we'll develop a small PHP program that shows how the API can be used to compress JavaScript code whenever you need it.

He shows how to compress three "script" tags down into one that defines multiple files for the engine to grab and compress. This is passed into a PHP file that grabs the file and passes the data off to the Closure Compiler for handling (via curl). The result is then passed back and served up with a content type of "text/javascript" back to the browser.

Facebook has made their official announcement about their secretive PHP project today and have scheduled an event for them to give the world more information on the project.

Today I'm excited to share the project a small team of amazing people and I have been working on for the past two years; HipHop for PHP. With HipHop we've reduced the CPU usage on our Web servers on average by about fifty percent, depending on the page. Less CPU means fewer servers, which means less overhead. This project has had a tremendous impact on Facebook. We feel the Web at large can benefit from HipHop, so we are releasing it as open source this evening in hope that it brings a new focus toward scaling large complex websites with PHP.

The post elaborates a bit more on what the tool is (not really a compiler, more of an optimizer) and why they decided to go this direction. There's a bit of description on how the tool works and how the transformation happens.

Stay tuned to this post around 7:30pm Pacific time for more information.

If you've been following along with some of the articles about the compiler Facebook is developing for PHP, you might want to check out these comments from ReadWriteWeb.com (by Mike Melanson) with more from his point of view.

According to our sources, Facebook has been working on a PHP compiler that will increase speed by around 80% and offer a just-in-time (JIT) compilation engine that will offer a number of advantages. The project is very similar to Google's Unladen Swallow project, which rebuilt the Python compiler, boosting the speed fivefold and opening the door for multi-language integration.

Included are also some comments from Richard Crowley about what Facebook could be releasing, a compiler that would still allow PHP to remain interpreted but provide the speed of being compiled. Some of the comments on the post wonder how something like this compiler compares to an opcode cache and doubts on whether it will end up being open sourced at all.

You can also get another opinion on what will be released in this article from the All Facebook blog. They reinforce that the announcement will come today and how much potential something like this could have to change what PHP could become.

According to this new article from the Software Development Times Facebook has rewritten the PHP runtime from scratch and will be releasing it soon as an open source project.

So, why has Facebook rewritten the PHP runtime? Because PHP is obviously too slow for their tastes. A few years ago, I had a coffee meeting with some of the folks from Zend. When they asked what I had been hearing about PHP in the market from my sources, I hemmed and hawed, then told them that I had heard people complaining about how slow PHP was.

Other sources suggest the release won't be a full runtime but instead a sort of compiler for PHP applications including an interview with a Facebook employee who drops a hint about their future plans for the language.

While working on an issue with debugging a script of his via XDebug, Derick Rethans was reminded of something that is an integral part of the PHP language - its two phase compiler.

During the first pass, it will find out to which opcode it needs to jump in the jump instructions. However, the PHP engine (and Xdebug) expects a memory address to jump to while executing your script. In the second pass, the compiler will then go over the generated opcodes and calculate the memory address to jump to from the jumps to opcode numbers.

Because of the way that XDebug was handling the checks (with the user-defined error handler) and how the opcodes inside of PHP are handled, the user-defined handler happened in between the first and second phases and the latter run couldn't find the resources it was looking for, thus the crash.