2.1 コンパイラを自作する理由
2.1.1 結論
以下のような理由で、コンパイラを自作することにしました。
GCC や Clang、QEMU などの仮想マシンを利用しない OS 開発を選択するため
コンパイラの勉強になるとともに、UEFI や OS の理解の助けになると考えているため
コンパイル時に得られる情報を用いて、独自のファイルを出力したりするなどの、機能拡張が比較的容易になるため
既存のコンパイラは規模が大きすぎたり、log の出力先などの制御が簡単でなかったり、JIT 実行できなかったりと、 条件を満たすものを探すよりは、新規開発を選択したほうが良いだろうという判断になりました。デバッガも開発する必要があります。
2.1.2 GCC や Clang、QEMU などの仮想マシンを利用しない理由
2018 年現在の主流の方法を選択しないことで、手間はかかりますが、他の人と同じような工程になることを避けることができ、 OS や文書の独自性と多様性を保つことができると考えています。
また、Linux などの POSIX 環境での開発(クロス開発)ではなく、最終的には自作 OS 上での開発(セルフ開発)を可能にしたいので、 POSIX 環境のツールに依存することができないためです。
ただし、一時的な確認作業などでは、POSIX 環境のツールを使うようにしています。物事には完璧というものはないのです。
2.1.3 失敗談
カーネルデバッグ中の Visual Studio 内蔵 WinDbg の通信内容を記録するアプリとデバイスドライバを作成して、 WinDbg のプロトコルを解析することで、自作 OS のデバッグができないか試みたのですが、プロトコルを理解することが できず、断念しました。以下のリポジトリに、ソースコードを保存してあります。
https://github.com/tenpoku1000/windbg_logger
また、デバッガなしの状態でカーネル自作も試みてみましたが、電源投入時に正常動作するものの、 再起動時に表示が乱れてフリーズしたりする不具合の原因を特定することができず、 先に進むためにコンパイラを自作する方向に作業を切り替えました。
最終更新