数週間前、ある開発者が「休暇中の無駄な実験」としてPHPの処理系をESP32へ移植した。それが今では、LaravelとSymfonyをそのまま動かし、ブラウザーからページを開けるところまで来ている。同じ基板が、3行のPHPでLEDを点滅させることもできる。
動いているのはPHPそっくりの何かではない。php.netが配布する本物のソースコードを、チップ用のコンパイラでそのまま変換したものだ。字句解析から構文木、オペコードへの変換、仮想マシンでの処理まで、Zend Engineが丸ごと載っている。下にOSはなく、母艦となるパソコンもつながっていない。microSDカードに置いたindex.phpを基板が読んで動かす。カードを差し替えて再起動すれば、次のスクリプトが動く。
搭載できるかどうかを決めるのは、動作周波数ではなくメモリーだ。動作中に使う領域はメガバイト単位で、内蔵SRAMの数百KBには収まらない。外付けのPSRAMと、ファームウェアの約3MBを置ける8MB以上のフラッシュが要る。PSRAMを持たないC系とH系は、周波数にかかわらず対象外だ。逆に、コアがXtensaかRISC-Vかは問われない。
32MBのPSRAMを積めるESP32-P4は、LaravelとSymfonyを素のまま走らせられる。8MBのESP32-S3は通常のアプリケーションとWebサーバーまでは動くが、フレームワークには届かない。Laravelがコンテナーを構築する段階だけでメモリーを使い切るためで、開発者はこれを言語の限界ではなくメモリーの天井だと説明する。
Webサーバーとして動くとき、基板はリクエストごとにPHPを起動し直す。ApacheやPHP-FPMの裏側と同じ振る舞いで、$_SERVERやクッキー、セッションがその都度用意される。毎回コンパイルし直さずに済むよう、バイトコードを保存するOPcacheも移植された。
ハードウェア側は、PHPから直接ピンを叩く。外部のツールを経由するのではなく、ピンをPHPへ露出させるC言語の拡張が組み込まれている。gpio_mode、gpio_write、gpio_read、delayの4つで、LEDの点滅は3行で書ける。delayは待つあいだにコアを明け渡すため、ウォッチドッグに引っかからない。
導入にESP-IDFを直接触る必要はない。phpflashという単体のコマンドが、ESP-IDFの導入から雛形の生成、ビルド、書き込みまでを引き受ける。S3用のイメージをP4へ書き込もうとすると止める安全装置も入る。
移植で難しかったのはPHPをコンパイルすること自体ではなかったと開発者は書く。OSがあることを前提に書かれた処理系を、OSのないチップで納得させる作業だったという。足りないPOSIXの関数を埋める代役を作り、設定ヘッダーを手書きし、実機で初めて表面化した癖に対処した。ライセンスはMITで、開発者は組み込みが専門ではないとしたうえで、メモリーの扱いについて指摘を求めている。
