memo0036

efg01の整備計画

• (by K, 2008.11.29)

(1)

• OSC2008北海道のセミナーでの質問で、「efg01 on efg01」の提案があった。これは面白いので手間がかからないならやりたい。さてこれをやるためにはefg01にはどんなAPIが足りないかを考えてみる。
• そうすると、とりあえず、コードセグメント内に対するmallocさえあればよさそうに思える。これがあれば、efg01 on efg01なんていうネタアプリだけではなく、「ぐいぐい01」仕様でefg02やそれに類するものを作る場合にも使えそうだ（efg02の計画は今のところないが）。
• フラットなメモリモデルは、CSがDSのエイリアスでしかないので、単にmallocすればそれで終わる（問題があるとすればNXビットの設定くらいなもの）。しかし旧OSASKやOSASK-HBでは話はそう簡単じゃない。まあこれらではOS側にefg01に相当するものを組み込んでしまっているので、実はどうにでもできるわけだけど（つまり特権命令すら使いたい放題なわけで）、しかしそれで満足しては発展がない。
• ではフラットではないメモリモデルではどうしようか。まずこのようなメモリモデルでは、CS内にメモリを確保できたところで、それだけではほとんど意味がない。なぜなら、CSへ書き込みアクセスすることはできないからである。ということで、DSからアクセスできるところにアクセスウィンドウがなければダメだ。そしてその際は、DSの中でのアドレスとCSの中でのアドレスは違うということを前提にしなければいけない。
• 単にCSの中のmallocということであれば、コードセグメントをreallocしてbaseを書き換えればそれで済む。あとDSの中でも適当にmallocし、そこからCSの所定のゾーンへ転送するAPIも付けておけば完璧だ。もちろんフラットな環境では、mallocだけして、アドレスはCSでもDSでも結局同じで、転送は何もしない。
• これで基本的には問題ないのだが、reallocというのはちょっと気になる。おそらくコードセグメントに余裕なんて持たせてないから、reallocはまず間違いなくmemcpyするはめになる（旧OSASKのようにページングをサポートしていればいいんだけど）。しかもページングのサポートの有無にかかわらず、十分な連続したアドレス空間の空きがないと失敗する。
• これを回避したいなら、既存のCSの拡張ではなくて、新規にコードセグメントを作るという方針のほうが無駄がない。つまり、CS内のオフセットだけではなく、実行に際してのCSまでも与えられる。もちろんフラットな環境ではこの新しいCSは自分のCSと同一である。・・・これは、新CSと旧CSとの間でfar-call/far-jmpをしないといけないということになる。うーん、それはそれで嫌なこともあるかなあ・・・。
• ということで、両方作ることにしよう。つまり、同一CS内にmallocするAPIと、新CSを作るmalloc。新CSのほうがAPIとしての負荷は低いし成功する確率が高いけど、farでアクセスしなきゃいけないのでちょっとめんどくさい、と。・・・まあめんどくさいから、まずは同一CS内mallocだけの実装でも問題ないかな。

(2)

• 現在「ぐいぐい01」はOSASK-HBの存在をもって「はりぼてOS」での実装実績としているけど、でも本当は「はりぼて友の会」のOSの多くでサポートされるくらいにはならないと説得力がない。となると、もっと移植性を高めるべきだ。今は標準関数を使ってefg01を書いているので、その部分をドライバに分割して、OS依存部をコンパクトにまとめたらいいと思う。いつかやりたい。・・・当面は暇がないけど。

こめんと欄