« Hacking Ruby by Fridge / 2 | トップページ | 仕様書のないプログラム »

おいたち

OSS(オープンソースソフトウェア)っていうくらいだから,OSSの話題はソフトウェア関連ばかりである.fridgeはOSSだが,その生い立ちはハードウェア設計(というかシステム設計)に深く関連し,少し複雑である.

C言語やC++はソフトウェアを記述するためだけの言語,と思っている人ははっきり言って古い.ハードウェア設計でもC言語ベース設計は一般的になっている.

プログラミング言語を語るとき,しばしばアーキテクチャと言語を完全に切り離した話をする人がいる.プログラミング言語が高級になればアセンブラなんて知らなくてもアプリケーションはつくれるから仕方ないんだけど(もちろん大したものはできないけど),それでは少し世界がせまい.経験的に,アーキテクチャに理解がないプログラマはハッカーにはなれないように感じる.

話が脱線した.とにかく現在のC/C++の用途は広い.対象となるバックエンドが異なると最適化の種類も違うものになる.gccには特定アーキテクチャ向けの最適化オプションがあるが,次々と登場する新しいCPUや,あるいはDSPに対して完全に能力を引き出した最適化を施すのは難しい.これがハードウェアシミュレータや合成ツールになってくるとなおさらである.

そこでコンパイラの最適化を動的に制御する方法を考えるようになった.例えばあるアーキテクチャに対するネイティブコードを生成するとき,

//コードサイズがキャッシュサイズより小さければ関数をインライン展開
if(code_size < cash_size) function_inline()

のように外から制御できれば,新しいアーキテクチャが登場してもすぐさまそのアーキテクチャの能力を最大限に生かした最適化を施すことができる.
fridgeはそのためのインタフェースのプロトタイプとしてつくりはじめられた.

その後コンパイラの最適化に対してだけじゃなく,もっと一般的なアプリケーション制御を考えるようになった.それは究極的にはアプリケーションのマクロ言語であり,設定ファイルである.

まず最初にfridgeをshellに組み込んだのは,そういった実験をしやすかった事と,制御構文が使い辛かったシェルスクリプトを使いやすいものにしたかったからである.その役目は現在のβ版fridge/shellでも十分果たしてくれると思う.

次のステップではデバッガとfridgeを統合してプログラミングできるデバッガをつくるつもりだったが,これはfridgeにプロセス間双方向通信機能を持たせればもっと一般的な方法で実現できそうなのでそのようなライブラリを作ることにする.
ちなみにデバッガでプログラミングできると次のようなメリットがある.

1.大量のブレイクポイントやステップ実行のログを自動的に生成して解析することができる
2.アプリケーションテスト時のシーケンス網羅チェックをすばやく行うことができる

デバッガでのこれらの機能は組み込みマクロによってすでに実現しているかもしれないが,fridgeでは他のアプリケーションも制御できるのでひとつの言語を覚えれば複数のアプリケーションを制御できるということになる.

なんだか後半は宣伝になってしまった.
そんなわけでfridgeはハードウェア設計->一般化によって生まれた言語ということである.

« Hacking Ruby by Fridge / 2 | トップページ | 仕様書のないプログラム »

コメント

コメントを書く

コメントは記事投稿者が公開するまで表示されません。

(ウェブ上には掲載しません)

トラックバック

この記事のトラックバックURL:
http://app.f.cocolog-nifty.com/t/trackback/163977/3765318

この記事へのトラックバック一覧です: おいたち:

« Hacking Ruby by Fridge / 2 | トップページ | 仕様書のないプログラム »