MicroRuby: True Microcontroller Ruby というタイトルの発表をしました。
PicoRubyはPicoRubyコンパイラとmruby/cの組み合わせで、以前からあるものです。MicroRubyはPicoRubyコンパイラとmruby VMの組み合わせで、今回新たにつくったものです。
成果サマリ（時間をかけた順）
- 大量にあるPicoRubyのgemたちをMicroRuby（mruby）に移植した。というか、どちらでもビルドできるように共通コードを括り出し、各VM用のコードを書いた
- mrubyのPresymビルドをPicoRubyのビルドシステムにも統合した
- mrubyにプリエンプティブタスクスケジューラを実装した
- 組み込み向けのヒープアロケータをつくった
という感じです。 難易度でいうと、2.と3.が大変でした。 あとデバッグ。あと1.のNetモジュール。あと4.に至るまでのgdbとの格闘。それとデバッグ。 マイコンのデバッグ大変なんですよ。
今回よくわかったのは、いや以前からわかっていたかもしれませんが、進捗を出しすぎると発表が薄くなりがちです。 RubyKaigiは“コード書いた自慢大会”なので、たくさん書いたことを自慢しましたが、あの場では触れてないさらに大量のパッチが背後にあります。 しかしそれらを前提として話さないと、30分の発表に収まらないのですね。 聴衆の中には「その、既存機能みたいにサラっと流してるとこも成果なのでは」とわかってくれる人もいます。 そういうやんちゃさんやジョーカーさんあたりに伝われば、それでいいっちゃいいのですけど。
これからどうする
PicoRubyとMicroRubyの両方をメンテするのは大変なので、一本化しようと思っています。 つまり、MicroRubyという名前はなくなり、いまMicroRubyと呼んでいるものをPicoRubyと呼ぶようになります。たぶん。 mruby/cベースのPicoRubyは、ある時点からは更新しなくなるか、あるいは更新頻度が大幅に減ります。たぶん。
でも、Raspi Pico W（RAM264KB）だとmruby VMベースのPicoRubyはメモリが足りなさそうなのが悩ましい。 Pico 2シリーズ（同520KB）も十分低価格だから、Pico向けのメンテナンスをやめてしまうという考えかたもありますね。 mrubyのVMは初期化プロセスがメモリ食いだからそこを直すのと、完全に空いたページ（ObjectSpace）を無に還すパッチを書けばPico Wもいけるかも？（てきとう） あとはLwIPのカスタムアロケータかな。やること多すぎる。
当面やるべきこと
- プリエンプティブタスクスケジューラをmrubyのupstreamにマージする
- PicoRubyコンパイラをmrubyのupstreamにマージする
これらはまつもとさんの希望でもあり、そのためにmrubyのコミット権をもらいました。
と考えながらいまソースコードを見てましたが、いろいろ依存関係があって一筋縄ではいかなそう。 とりあえず、まだ動作不安定なMicroRubyをいまのPicoRuby程度に安定させ、手元のPicoRubyをmruby VMベースに一本化するのが先かな。 mruby/cとmrubyを条件分岐しているコードのノイズが大きいので、それをきれいにすればmrubyのupstream向けの作業が少しはやりやすくなるはず。 安定させるというのは、主にメモリリーク対策とメモリ破壊対策です。 要するにGCです。
さらにその先
いまはPicogemになっているGPIOなどのマイコン用ライブラリたちもmruby/mrubyに移していきます。 そうすると、PicoRubyとは？という感じになりますが、R2P2のためだけのライブラリなど、PicoRuby側に持たないといけない実装も一定程度はあります。 ピコルビーという名前をまつもとさんが気に入っていて、PicoRubyはひとつのブランドを確立しつつあるらしいので、残さなきゃいけないとのことです。
野望
ここ数年、PicoRubyをつかってラジコンを動かしたり音を鳴らしたりする人たちがいて、これはもう作者冥利につきるわけです。 しかし、それ、俺がやりたいやつ、という気持ちもあります。 PicoRubyの言語実装というかエコシステムをつくるので精いっぱいなのですけど、アプリのアイデアもいろいろとあります。
PicoRubyによるSTEM教育キットとか、明和電機みたいなアホっぽい（失礼）製品を企画して販売するというのもやってみたい。 とりあえず、フルタイムmrubyコミッタを雇いたい企業があったらこっそり教えてください。 ないと思うけど。