Linuxのマルチスレッドのような機構をリアルタイム制御システムで実現する一つの手段はオリジナルのOSを開発する方法です。つまりOSのカーネルの機能として分散開発されたアプリケーションを脱着できるようにすることです。しかし現実問題としてお客様に全く新しいOSを提唱することは、かえってお客様の採用のハードルを上げてしまう事になり、お客様にとっても当社にとってもメリットは少ないと思われます。
京都マイクロコンピュータは、長年に渡り開発環境を第一線のお客様と共に手掛けてきた、プロの「ツール屋」ですので、開発ツールの視点からこの問題を解決する方法を考えました。
やりたい事は、複数のプログラムをビルドしロードすることです。開発環境がホストPCで行っている事をアプリケーションの中で「実行」できれば、同じ結果になる、つまりリンカが行っているアドレス解決処理とローダーの動作をランタイム側で行えばよいのだという点に着目しました。アドレス解決に必要なELF情報をランタイムに含め、そのELF情報を参照してプログラムを物理メモリ上に配置する処理もランタイム側に置けば良いのです。
そのように検討した結果生まれたのがOSに依存しないベアメタルのローダーであるSOLID インテリジェントローダーです。ベアメタルのローダーを新規開発することで、既存のRTOSやツールチェーンといった汎用性の高いツールに手を加えることなく利用できることがわかってきました。
なおこのローダーはランタイム側で動作するものなので、プログラムサイズと実行時間に対するオーバーヘッドが極力少なくなるよう、十分配慮して開発しました。
SOLIDインテリジェントローダーは、DLL方式ではなく当社が独自にその方式を考案しインプリしたものです。なぜローダーを独自に作ったのか、その結論に至った背景を一部ここでご紹介します。
まず第一に、ロード対象である複数のモジュール間で、共有シンボルや関数の相互参照がしたかったからです。DLL方式の場合ロードする側とされる側の親子関係が固定されてしまい、相互参照が解決できない点に不便さを感じました(図3-4）。
図3-4 相互参照の関係の相違
次に考慮したのが実行速度の点です。DLL方式ではスレッド（アプリ）が呼び出された時点ではじめて実行モジュールがメモリ上にダウンロードされます。この場合当然ながら実行時にダウンロード時間がオーバーヘッドとなってしまい、RTOS利用を対象とするリアルタイム重視の制御システムには不向きです(図3-5)。そのためシステム起動時の初期化段階で全てのアプリのダウンロードを済ませておき、その後は論理・物理空間の固定したアドレスに全てのプログラムがロードされた状態でシステムを稼働する方法が好ましいと考えました(図3-6)。
図3-5 DLL方式のロードでは、アプリ起動時にオーバーヘッドが発生
図3-6 SOLIDインテリジェントローダーを使い、システム初期化時にロード完了
京都マイクロコンピュータは、長年にわたりツールチェーンを含む開発環境をご提供してきたツールベンダーであり、リンカの動作が分かっていたからこそ出来たローダーといえます。またSOLIDがツール単体ではなくIDE、ツールチェーン、RTOS、デバッガと一体化した構成であったからこそ、ユーザーがシンプルな手順で利用できるような形で、インテリジェントローダー提供できるようになりました。
MMUと連携しているので、メモリを効率よく利用できる
インテリジェントローダーでは、実行モジュールをロードする際に、自動的にMMUを使って論理→物理空間のメモリ配置を行っています。ユーザーは開発途中で再配置／再調整をしなくてもいいよう、論理空間上に余裕を持って実行モジュールを配置すればよく、自由度の高いメモリ配置が可能です。
インテリジェントローダーは、使用していない空間には物理メモリを割り当てないよう無駄なくメモリを配置し、その配置情報がコアサービス内のMMU管理機能と連携しているので効率よくメモリが利用できます(図3-7)。是非この点にも着目して、うまくローダーを利用していただきたいと思います。
図3-7 ローダーが物理空間に効率よく実行モジュールを配置
（終）