現在の状況
- 現在、SBCLランタイムとコンパイラをNintendo Switchで実行できるように移植完了
- 共有ライブラリとのインターフェースも可能で、さまざまなオペレーティングシステム移植性ライブラリの移植も完了
- しかし、SBCLのガベージコレクタが動作するとクラッシュが発生
- オーディオ出力不可、Cコールバック機構に問題あり
- 性能面の問題も予想される
概要
- SwitchはARM64 Cortex-A57チップと4GB RAMを使用し、独自のマイクロカーネルOS上で動作する
- SBCLはすでにARM64 Linuxポートを持っているため、コード生成の問題は解決済み
- SwitchはOpenGLグラフィックスライブラリをサポートする唯一のコンソールであり、Trialのグラフィックスライブラリ移植が容易
- 開発を始めるためにNintendo of Europeから開発キットを購入し、SDKをインストール
SBCLビルドプロセス
build-config: ビルド構成オプションを収集し、読み取り可能な形式で出力
make-host-1: ホストLispコンパイラでクロスコンパイラをビルド
make-target-1: ターゲットCコンパイラでCランタイムを生成
make-host-2: ターゲットLispシステムをビルド
make-target-2: ターゲットランタイムでコールドコアを読み込み、ブートストラップを完了
Switch向けビルド
- SwitchはPC環境ではなく、シェル、コマンドライン、コンパイラがない
- 実行可能ページを生成できないため、ランタイムコンパイル不可
- コードの大部分はプラットフォーム非依存であり、ARM64向けにコンパイル可能
fastevalを使ってランタイムコンパイルを代替
ガベージコレクタ
- SBCLの標準GCは"gencgc"で、世代別ガベージコレクタである
- マルチスレッド環境でオブジェクト移動の問題が発生
- Unixシステムではシグナル機構を使ってスレッドを停止させるが、Switchでは不可能
- "safepoints"戦略を使い、スレッド自身が停止するようにする
今後の作業
- CLOSを可能な限り固定し、事前コンパイルを検討
- Switchの低性能プロセッサのため、追加の最適化が必要
- ガベージコレクタを完全動作させる必要あり
- Cコールバック問題の解決が必要
結論
- NDAのため作業内容を公開できないが、可能な範囲は公開中
- Patreon、GitHub、Ko-Fiを通じた支援を要請
GN⁺のまとめ
- この記事は、Common LispランタイムをNintendo Switchへ移植する過程と課題を扱っている
- Switchの独自OSとハードウェア制約により、多くの技術的困難が発生している
- ガベージコレクタとマルチスレッドの問題、ランタイムコンパイルの問題などが主要な課題
- このプロジェクトはCommon Lisp開発者とゲーム開発者に有用な情報を提供する
1件のコメント
Hacker Newsのコメント
数週間にわたってTrialを使い、Common Lispでのゲーム開発を試してみたが、とても楽しい体験だった
SBCLは素晴らしい言語実装であり、「本物の」ゲーム機向けにCL開発をしてみたいと思っていた
著者に、興味深く詳細な記事を書いてくれたことを感謝する
なぜ公式SDKを使ったのか気になる
Kandriaを購入した
SBCL - "Steel Bank Common Lisp"
彼女の仕事は驚異的だ
NintendoとSonyがこうした取り組みを支援してくれたらと思う
少し話題から外れるが、YuzuをNintendo Switchに移植できたら驚くだろう
HNに来る理由はまさにこういうものだ