1: 2009-07-14 (火) 22:13:32 [6] | 2: 2009-07-14 (火) 22:47:31 [7] | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | * APIのパラメータの渡し方 | + | * OSASKにおけるAPIのパラメータの渡し方 |
-[[OsaTech]]より | -[[OsaTech]]より | ||
-(by [[K]], 2009.07.14) | -(by [[K]], 2009.07.14) | ||
Line 7: | Line 7: | ||
-当時の僕たちはパラメータの渡し方には、以下の3つがあると考えた。 | -当時の僕たちはパラメータの渡し方には、以下の3つがあると考えた。 | ||
--レジスタ渡し | --レジスタ渡し | ||
- | ---BIOSのように、パラメータを所定のレジスタにいれ、APIを呼び出す。 | + | ---BIOSのように、パラメータを所定のレジスタにいれ、APIを呼び出す。「はりぼてOS」もこのタイプ。 |
--スタック渡し | --スタック渡し | ||
---C言語の関数のように、パラメータをスタックにつんで、APIを呼び出す。 | ---C言語の関数のように、パラメータをスタックにつんで、APIを呼び出す。 | ||
Line 13: | Line 13: | ||
---すぐには例が思いつかないのだが、とにかくパラメータをメモリのどこかに所定の順序で並べて、その先頭アドレスをレジスタに入れて、APIを呼び出す。 | ---すぐには例が思いつかないのだが、とにかくパラメータをメモリのどこかに所定の順序で並べて、その先頭アドレスをレジスタに入れて、APIを呼び出す。 | ||
-まずレジスタ渡しにはメリットがある。というのは、渡されたパラメータがメモリではなくレジスタ上にあるということだ。どんなパラメータにせよ、OSに渡す以上は、その値は当然OSに利用される。そしてOSが利用するということは、その値をレジスタに読んで計算したりI/Oしたりするということである。・・・スタック渡しやポインタ渡しは、アプリで計算したものを一度わざわざメモリに置き、そしてその値をOSが読むのである。これは大いに無駄である。 | -まずレジスタ渡しにはメリットがある。というのは、渡されたパラメータがメモリではなくレジスタ上にあるということだ。どんなパラメータにせよ、OSに渡す以上は、その値は当然OSに利用される。そしてOSが利用するということは、その値をレジスタに読んで計算したりI/Oしたりするということである。・・・スタック渡しやポインタ渡しは、アプリで計算したものを一度わざわざメモリに置き、そしてその値をOSが読むのである。これは大いに無駄である。 | ||
- | --一説によれば、最近のプログラムは結局、このような値の格納と読み取りという、実質的な処理ではないようなことに処理の時間の大半を費やしているとも言われる。CPUが速くなってもソフトが速くならないのは、そういう改悪が進んでいるからだと。 | + | --一説によれば、最近のプログラムは、結局このような値の格納と読み取りという、実質的な処理ではないようなことに処理の時間の大半を費やしているとも言われる。CPUが速くなってもソフトが速くならないのは、そういう改悪が進んでいるからだと。 |
-しかし僕たちはレジスタ渡しを採用していない。というのは、x86ではとにかくレジスタが少なくて、結局一度メモリにレジスタの値を退避してからでなければ何も始められず、それならスタック渡しやポインタ渡しでも差は無いからである。 | -しかし僕たちはレジスタ渡しを採用していない。というのは、x86ではとにかくレジスタが少なくて、結局一度メモリにレジスタの値を退避してからでなければ何も始められず、それならスタック渡しやポインタ渡しでも差は無いからである。 | ||
-そして僕はポインタ渡しを強く推した。というのは、スタックにパラメータをつんでも、EBX=ESP;などによってスタックトップのアドレスをポインタとして渡せば、ポインタ渡しでもスタック渡しと同じことが出来るからである。この場合純粋なスタック渡しと比べて劣るのはEBX=ESP;の1命令分だけで、これはスタック以外にもパラメータを置けるようになることを思えば、悪くない代償である。 | -そして僕はポインタ渡しを強く推した。というのは、スタックにパラメータをつんでも、EBX=ESP;などによってスタックトップのアドレスをポインタとして渡せば、ポインタ渡しでもスタック渡しと同じことが出来るからである。この場合純粋なスタック渡しと比べて劣るのはEBX=ESP;の1命令分だけで、これはスタック以外にもパラメータを置けるようになることを思えば、悪くない代償である。 | ||
Line 19: | Line 19: | ||
*** (2) | *** (2) | ||
+ | -レジスタ渡しを避けたことで、一度のAPI呼び出しで渡せるパラメータの量に上限は無くなった。そうすると、一度の呼び出しで複数のAPIを実行できる仕組みがほしくなった。そこで、[[K]]は以下のような設計をした。 | ||
+ | --[機能番号 パラメータ パラメータ パラメータ ・・・] [機能番号 パラメータ パラメータ パラメータ ・・・] ... [0] | ||
+ | -メモリ上には、このようにパラメータ列の終わりに続けて次の機能番号を書くことができ、これで事実上いくつでもつなげることができた。この先頭のアドレスをEBXに入れてAPIを呼び出せば、つながった機能が全部実行される。そして最後には終端ファンクション(ファクション番号0)があった。これがないと、OSはどこまでがAPIのための構造体なのか判断できないためである。 | ||
+ | |||
+ | *** (3) | ||
+ | -この2つの特徴が、OSASKをOSASKたらしめた大きな要素になった。まずポインタ渡しになったことにより、定数の引数を多く持つAPI呼び出しは、いちいちスタックにつむのをやめて、.data内の配列に機能番号やパラメータを並べておき、可変部分のみを上書きして、API呼び出しをした。これはコードがとても短くなる。これはレジスタ渡しだと真似できない。レジスタ渡しなら、レジスタに値を代入しなければいけないからである。省略できる代入はない。またスタック渡しでもこれは真似できない。スタック渡しの場合も、すべてのパラメータをスタックにつまなければいけないからである。ということで、本質的ではないMOVの羅列やPUSHの羅列は、OSASKアプリからは一掃された。つまりコンパクトで高速になった。 | ||
+ | -複数ファンクションを一度のAPIコールで実現できるので、一つあたりのAPI呼び出しのオーバヘッドは軽減された。またこれはAPI設計にもいい影響を与えた。というのは、APIの機能を細分化するのにためらいがなくなったのである。普通だと効率を考えて、あまりにもささやかな機能をAPI化するのはためらう。そうするとどうしても複雑なAPIが多くなる。そしてOSも複雑になる。・・・しかしAPI呼び出しのオーバヘッドを無視してもいいと思えるようになると、APIはかなり小さな機能をサポートするだけでもかまわないと思えて、複数のAPIを組み合わせて使ってもらうのを前提に考えるようになる。結果的に小回りのきく使いやすいAPIになる。そしてOSも肥大化しない。 | ||
+ | *** (4) | ||
+ | -以上は第一世代OSASKの話である。そして以下が第二世代OSASKの話である。 | ||
* こめんと欄 | * こめんと欄 | ||
#comment | #comment |
(This host) = http://osask.net