理想のプログラミング環境を考える
(1)
- 何らかの言語を使って、アプリケーションを作ったとします。これはどういう形式で保存しておくと、今後もずっと少ない手間で使い続けられるでしょうか。
- ライブラリがバージョンアップしたときに、すぐにその恩恵を受けるにはどうしたらいいでしょうか。
- CPUが変わったときにも追従できるのはどういう形式でしょうか。
- なんというか時代とともにCPUのビット数が変わったとか、メジャーなOSが変わったとかで、自分の作ってきたプログラムが動かなくなって移植しなければいけなくなるというのは結構悲しいです。生産的じゃないです。
- UNIX文化圏は、この手の問題に何十年も前から取り組んでいるように思います。
- 彼らはプログラムをソースコードで保存して、自分の環境でビルドすることで、問題を解決してきたように思います。
- int幅やポインタ幅に依存しないプログラミング、インラインアセンブラは使わない、エンディアンにも依存しないように書く、などです。
(2)
- 私はアプリを関数として書いておいて、OSがそれを適当な引数で呼び出して、一定時間内に帰ってきて、アプリが継続の意向を示したらまたOSがアプリを呼び出すという、そういう実装方法が理想だと思っています。
- なぜならOSはこの形式だととてもアプリを扱いやすいからです。
- またアプリはOSに帰る際にできるだけメモリを少なくするようにしておくべきで、そうすればOSは総メモリを小さく抑えやすくなり（なぜならメモリが少なくなったタイミングでタスクスイッチするようになるので）、スワップの発生率が下がり、キャッシュヒット率も向上するでしょう。
- もっと積極的な仕様としては、「アプリはmallocしてポインタを受け取ることはできるけど、保持できるポインタには限りがあり、ポインタはタスクスイッチを超えて渡すことはできない」というのがあります。この場合細かいポインタを保持するのをあきらめて、malloc単位ごとに、先頭アドレスから何バイト目の場所、のように変換して保持することになります（セグメンテーションに近いです）。
- この仕様を採用すれば、OSはタスクスイッチ中にメモリブロックを好きな場所に移動できるようになります。
- さらにアクセスに先立ってOSにポインタをもらうようにしたら、CPUのページングもいらなくなるので、よりシンプルな環境でも問題なく動作できるようになります。
- これで、割り込みもページングもなくても問題なく動くアプリが作れることになります。また私は以前からCPUの保護機構に一切頼らずにエラー検出するようにしているので（そういう言語を作っているので）、CPUの例外検出機構も不要です。
(3)
- ページサイズや、タスクスイッチのための時間間隔の目安などは、OSからアプリにうまく伝える方法が必要そうです。
- ページサイズは、システムコールで聞けばいいだけなので簡単。
- タスクスイッチのための時間間隔については、もっと長くしてもよいといわれたら2倍にして、遅くしてほしいといわれたら半分にする、みたいな仕組みがいいかも。
- タスクセーブから復帰した場合などもありうるので、リセットして取得しなおす（もしくはいったん最小値を想定する）みたいな指示もできたらよさそうです。
- メモリをアロケートする際は、構造体情報を渡します。そうすればOSはメモリのどこにどんな型データがあるのかを正確に知ることができます。その情報があれば、OSはメモリイメージを保存できるし、アーキテクチャの異なる環境にロードできます。
- デバッグのためにメモリをダンプするときも、きわめてきれいにデータを見ることができます。
(4)
- アプリはOSに対して確保したメモリに名前を付けられます。その名前は「ファイルパス」として機能します。
- もしくはメモリを確保する際に既存の名前を指定することもできます。これは既存ファイルのオープンに相当します。
- それ以上の細部を規定してしまうと、いろんなファイルシステムとの共存が難しくなりそうなので、とりあえずこの辺が限界かなあ。
- ディスク上でも何らかの方法で型情報を保存するので、それを参照することでファイルダンプがきれいになります。
(5)
- ちょっと脱線するけど、画面にグラフィックで文字を書いたとき、その文字列をOSは覚えておくべきだと思います。それであとから取得できるようになっているべきだと思います。OCR的にあとからがんばるなんて、明らかに非効率です。
- 同じことは画像ファイルでもいえると思います。
(6)
- ポインタのビット幅について
- 前からずっと考えているのだけど、64bit空間では64bitのポインタが必要になります（8バイト）。一方、16bit空間（64KB）ならポインタはたったの1bit、つまり2バイトで済みます。
- もしアプリが広いメモリ空間を必要としないのなら、ポインタは小さくてもいい気がするのです。
(7)
- また悩ましい問題が出てきたかも・・・。
- コードもあまりに大きいとよくないのである程度のメモリブロックに分ける必要がありそうです。コード片を作って、jmp前に飛び先のコード片を準備させればいいのかなあ。確かにそれで行けそうではあるな・・・。
![[K Wiki]](k.jpg "[K Wiki]")
