ページへ戻る

− Links

 印刷 

OT​/0004 のバックアップ差分(No.3) :: OSASK計画

osaskwiki:OT/0004 のバックアップ差分(No.3)

« Prev[4]  Next »[5]
2: 2009-07-14 (火) 22:47:31 ソース[6] 3: 2009-07-15 (水) 08:52:59 ソース[7]
Line 9: Line 9:
---BIOSのように、パラメータを所定のレジスタにいれ、APIを呼び出す。「はりぼてOS」もこのタイプ。 ---BIOSのように、パラメータを所定のレジスタにいれ、APIを呼び出す。「はりぼてOS」もこのタイプ。
--スタック渡し --スタック渡し
----C言語の関数のように、パラメータをスタックにつんで、APIを呼び出す。+---C言語の関数のように、パラメータをスタックにつんで、APIを呼び出す。win32はこれに分類していいと思う。
--ポインタ渡し --ポインタ渡し
---すぐには例が思いつかないのだが、とにかくパラメータをメモリのどこかに所定の順序で並べて、その先頭アドレスをレジスタに入れて、APIを呼び出す。 ---すぐには例が思いつかないのだが、とにかくパラメータをメモリのどこかに所定の順序で並べて、その先頭アドレスをレジスタに入れて、APIを呼び出す。
Line 25: Line 25:
*** (3) *** (3)
-この2つの特徴が、OSASKをOSASKたらしめた大きな要素になった。まずポインタ渡しになったことにより、定数の引数を多く持つAPI呼び出しは、いちいちスタックにつむのをやめて、.data内の配列に機能番号やパラメータを並べておき、可変部分のみを上書きして、API呼び出しをした。これはコードがとても短くなる。これはレジスタ渡しだと真似できない。レジスタ渡しなら、レジスタに値を代入しなければいけないからである。省略できる代入はない。またスタック渡しでもこれは真似できない。スタック渡しの場合も、すべてのパラメータをスタックにつまなければいけないからである。ということで、本質的ではないMOVの羅列やPUSHの羅列は、OSASKアプリからは一掃された。つまりコンパクトで高速になった。 -この2つの特徴が、OSASKをOSASKたらしめた大きな要素になった。まずポインタ渡しになったことにより、定数の引数を多く持つAPI呼び出しは、いちいちスタックにつむのをやめて、.data内の配列に機能番号やパラメータを並べておき、可変部分のみを上書きして、API呼び出しをした。これはコードがとても短くなる。これはレジスタ渡しだと真似できない。レジスタ渡しなら、レジスタに値を代入しなければいけないからである。省略できる代入はない。またスタック渡しでもこれは真似できない。スタック渡しの場合も、すべてのパラメータをスタックにつまなければいけないからである。ということで、本質的ではないMOVの羅列やPUSHの羅列は、OSASKアプリからは一掃された。つまりコンパクトで高速になった。
--複数ファンクションを一度のAPIコールで実現できるので、一つあたりのAPI呼び出しのオーバヘッドは軽減された。またこれはAPI設計にもいい影響を与えた。というのは、APIの機能を細分化するのにためらいがなくなったのである。普通だと効率を考えて、あまりにもささやかな機能をAPI化するのはためらう。そうするとどうしても複雑なAPIが多くなる。そしてOSも複雑になる。・・・しかしAPI呼び出しのオーバヘッドを無視してもいいと思えるようになると、APIはかなり小さな機能をサポートするだけでもかまわないと思えて、複数のAPIを組み合わせて使ってもらうのを前提に考えるようになる。結果的に小回りのきく使いやすいAPIになる。そしてOSも肥大化しない。+-複数ファンクションを一度のAPIコールで実現できるので、一つあたりのAPI呼び出しのオーバヘッドは軽減された。またこれはAPI設計にもいい影響を与えた。というのは、APIの機能を細分化するのにためらいがなくなったのである。普通だと効率を考えて、あまりにもささやかな機能だけをAPI化するのはためらう。そうするとどうしても複雑なAPIが多くなる。そしてOSも複雑になる。・・・しかしAPI呼び出しのオーバヘッドを無視してもいいと思えるようになると、APIはかなり小さな機能をサポートするだけでもかまわないと思えて、複数のAPIを組み合わせて使ってもらうのを前提に考えるようになる(前処理しかしないAPI、後処理しかしないAPIなど)。結果的に小回りのきく使いやすいAPIになる。そしてOSも肥大化しない。
*** (4) *** (4)
-以上は第一世代OSASKの話である。そして以下が第二世代OSASKの話である。 -以上は第一世代OSASKの話である。そして以下が第二世代OSASKの話である。
 +-第二世代OSASKでも、レジスタ渡しや、一度のAPI呼び出しで複数のAPIが実行される仕組みはそのまま引き継がれた。しかし若干の手直しもある。
 +-まずポインタを格納するレジスタはEBXからEDIに変更した。これはEBXがBL,BHに分割可能で使い道が多いので、これよりも使い道の少ないEDIにしたというだけである。これでアプリは少し書きやすくなるはずだ。また複数APIを呼び出す時のルールも変更した。今まではデフォルトが複数API実行で、それを打ち切るために最後に0を付加させていた。しかし実際の利用を見ると、半分以上のケースは一つのAPIを呼ぶだけであり、このために毎度0を付加するのは気になるオーバーヘッドである。したがって最初にマルチAPIファンクション(3...だったかな?)を置けば従来どおりの複数API実行、最初がそれ以外の機能番号なら一つのAPIを実行した時点で終了、とした。
 +-次に第二世代OSASKでは、パラメータのエンコードを見直した。第一世代では、機能番号も引数も基本は32bitの整数だった。これはCPUにとって一番扱いやすいし、拡張性も十分にある。しかし実際の利用を見てみると、扱われる数値は8bitで十分なケースが多く、いやむしろ4bit程度で十分な場合も少なくない。
 +-そこでエンコードを4bit単位のものに変更した。必要なら8bitや12bitなどより長い整数形式を使うことももちろんできる。→[[GUIGUI01/man0004]] これで無駄な上位の0は一掃され相当短くなった。
 +-さらに第二世代OSASKでは、引数の一部分に対して、「ここの値はスタックの○○番目を参照」とか「ここの値は○○レジスタを参照」のような記述を許すことにした。これはパラメータに特別な数字を書くことで実現している。これは非常に強力で、今まで可変パラメータを含んだものはわざわざMOVなどで上書きしていたのだが、それが完全に不要になった。レジスタの値を利用できるので、パラメータのエンコードが上記のように複雑になっても、ほとんど問題にはならない(もしレジスタの値が利用できないのなら、それをメモリにストアするために、アプリがややこしいエンコードをしなければいけなかった)。
 +-こうして結果的に、第二世代OSASKのAPIパケットは基本的に上書きしないものとなり、それゆえに.textに置いてもいいと思えるようになった。そこでEDI=0という特別形式を作り、この値でAPIが呼ばれたときには、OSはAPIパケットの先頭アドレスをEIPから取得する。そしてそのまま実行し、終了時にパケット終了アドレスの次のアドレスへreturn;する。これだとEDIへポインタを代入する手間が省ける(第二世代OSASKではEDIの初期が0なのだが、これを一度も変更しないアプリも存在するくらいである)。
 +--これはつまりCALL命令の直後にDBでAPIパケットを並べればいいということである。
* こめんと欄 * こめんと欄
#comment #comment
« Prev[4]  Next »[5]