サイトトップへ
OSASK.NET
  サイトトップへ       新掲示板(閉鎖済)   Wiki(凍結済)   旧掲示板(廃止済)   ニュース(廃止済)  
3: 2009-07-15 (水) 08:52:59 ソース 現: 2024-01-08 (月) 12:58:49 k-tan ソース
Line 1: Line 1:
-* OSASKにおけるAPIのパラメータの渡し方+TITLE:x 
 +* OSASKにおけるAPIのパラメータの渡し方 [#u0f7c4fa]
-[[OsaTech]]より -[[OsaTech]]より
-(by [[K]], 2009.07.14) -(by [[K]], 2009.07.14)
-*** (1)+*** (1) [#w665c8fd]
-第一世代OSASKのAPIを規定するに当たって、最初に検討したのはパラメータの渡し方だったように思う。これはOSASK-MLが始まる前から[[K]]と今原氏とで検討した。 -第一世代OSASKのAPIを規定するに当たって、最初に検討したのはパラメータの渡し方だったように思う。これはOSASK-MLが始まる前から[[K]]と今原氏とで検討した。
-当時の僕たちはパラメータの渡し方には、以下の3つがあると考えた。 -当時の僕たちはパラメータの渡し方には、以下の3つがあると考えた。
Line 18: Line 19:
-ということで、メモリにパラメータ列を並べて、その先頭アドレスをEBXにいれて、APIを呼び出すというのが、第一世代OSASKの基本形になった。 -ということで、メモリにパラメータ列を並べて、その先頭アドレスをEBXにいれて、APIを呼び出すというのが、第一世代OSASKの基本形になった。
-*** (2)+*** (2) [#b4724580]
-レジスタ渡しを避けたことで、一度のAPI呼び出しで渡せるパラメータの量に上限は無くなった。そうすると、一度の呼び出しで複数のAPIを実行できる仕組みがほしくなった。そこで、[[K]]は以下のような設計をした。 -レジスタ渡しを避けたことで、一度のAPI呼び出しで渡せるパラメータの量に上限は無くなった。そうすると、一度の呼び出しで複数のAPIを実行できる仕組みがほしくなった。そこで、[[K]]は以下のような設計をした。
--[機能番号 パラメータ パラメータ パラメータ ・・・] [機能番号 パラメータ パラメータ パラメータ ・・・] ... [0] --[機能番号 パラメータ パラメータ パラメータ ・・・] [機能番号 パラメータ パラメータ パラメータ ・・・] ... [0]
-メモリ上には、このようにパラメータ列の終わりに続けて次の機能番号を書くことができ、これで事実上いくつでもつなげることができた。この先頭のアドレスをEBXに入れてAPIを呼び出せば、つながった機能が全部実行される。そして最後には終端ファンクション(ファクション番号0)があった。これがないと、OSはどこまでがAPIのための構造体なのか判断できないためである。 -メモリ上には、このようにパラメータ列の終わりに続けて次の機能番号を書くことができ、これで事実上いくつでもつなげることができた。この先頭のアドレスをEBXに入れてAPIを呼び出せば、つながった機能が全部実行される。そして最後には終端ファンクション(ファクション番号0)があった。これがないと、OSはどこまでがAPIのための構造体なのか判断できないためである。
-*** (3)+*** (3) [#had5981b]
-この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、後処理しかしないAPIなど)。結果的に小回りのきく使いやすいAPIになる。そしてOSも肥大化しない。 -複数ファンクションを一度のAPIコールで実現できるので、一つあたりのAPI呼び出しのオーバヘッドは軽減された。またこれはAPI設計にもいい影響を与えた。というのは、APIの機能を細分化するのにためらいがなくなったのである。普通だと効率を考えて、あまりにもささやかな機能だけをAPI化するのはためらう。そうするとどうしても複雑なAPIが多くなる。そしてOSも複雑になる。・・・しかしAPI呼び出しのオーバヘッドを無視してもいいと思えるようになると、APIはかなり小さな機能をサポートするだけでもかまわないと思えて、複数のAPIを組み合わせて使ってもらうのを前提に考えるようになる(前処理しかしないAPI、後処理しかしないAPIなど)。結果的に小回りのきく使いやすいAPIになる。そしてOSも肥大化しない。
-*** (4)+*** (4) [#ocebc787]
-以上は第一世代OSASKの話である。そして以下が第二世代OSASKの話である。 -以上は第一世代OSASKの話である。そして以下が第二世代OSASKの話である。
-第二世代OSASKでも、レジスタ渡しや、一度のAPI呼び出しで複数のAPIが実行される仕組みはそのまま引き継がれた。しかし若干の手直しもある。 -第二世代OSASKでも、レジスタ渡しや、一度のAPI呼び出しで複数のAPIが実行される仕組みはそのまま引き継がれた。しかし若干の手直しもある。
Line 33: Line 34:
-そこでエンコードを4bit単位のものに変更した。必要なら8bitや12bitなどより長い整数形式を使うことももちろんできる。→[[GUIGUI01/man0004]] これで無駄な上位の0は一掃され相当短くなった。 -そこでエンコードを4bit単位のものに変更した。必要なら8bitや12bitなどより長い整数形式を使うことももちろんできる。→[[GUIGUI01/man0004]] これで無駄な上位の0は一掃され相当短くなった。
-さらに第二世代OSASKでは、引数の一部分に対して、「ここの値はスタックの○○番目を参照」とか「ここの値は○○レジスタを参照」のような記述を許すことにした。これはパラメータに特別な数字を書くことで実現している。これは非常に強力で、今まで可変パラメータを含んだものはわざわざMOVなどで上書きしていたのだが、それが完全に不要になった。レジスタの値を利用できるので、パラメータのエンコードが上記のように複雑になっても、ほとんど問題にはならない(もしレジスタの値が利用できないのなら、それをメモリにストアするために、アプリがややこしいエンコードをしなければいけなかった)。 -さらに第二世代OSASKでは、引数の一部分に対して、「ここの値はスタックの○○番目を参照」とか「ここの値は○○レジスタを参照」のような記述を許すことにした。これはパラメータに特別な数字を書くことで実現している。これは非常に強力で、今まで可変パラメータを含んだものはわざわざMOVなどで上書きしていたのだが、それが完全に不要になった。レジスタの値を利用できるので、パラメータのエンコードが上記のように複雑になっても、ほとんど問題にはならない(もしレジスタの値が利用できないのなら、それをメモリにストアするために、アプリがややこしいエンコードをしなければいけなかった)。
--こうして結果的に、第二世代OSASKのAPIパケットは基本的に上書きしないものとなり、それゆえに.textに置いてもいいと思えるようになった。そこでEDI=0という特別形式を作り、この値でAPIが呼ばれたときには、OSはAPIパケットの先頭アドレスをEIPから取得する。そしてそのまま実行し、終了時にパケット終了アドレスの次のアドレスへreturn;する。これだとEDIへポインタを代入する手間が省ける(第二世代OSASKではEDIの初期が0なのだが、これを一度も変更しないアプリも存在するくらいである)。+-こうして結果的に、第二世代OSASKのAPIパケットは基本的に上書きしないものとなり、それゆえに.textに置いてもいいと思えるようになった。そこでEDI=0という特別形式を作り、この値でAPIが呼ばれたときには、OSはAPIパケットの先頭アドレスをEIPから取得する。そしてそのまま実行し、終了時にパケット終了アドレスの次のアドレスへreturn;する。これだとEDIへポインタを代入する手間が省ける(第二世代OSASKではEDIの初期値が0なのだが、これを一度も変更しないアプリも存在するくらいである)。
--これはつまりCALL命令の直後にDBでAPIパケットを並べればいいということである。 --これはつまりCALL命令の直後にDBでAPIパケットを並べればいいということである。
-* こめんと欄+*** (5) [#i98509f5] 
 +-第二世代OSASKにおけるAPIパケットの例: 
 +-51 "hello, world\0" 
 +--5はコンソールへの文字列出力ファンクション。この直後に4xを書くと標準出力以外にも出力できるが、ここでは何もしてないのでデフォルトのまま。 
 +--1は文字列の指定方式で、パケット内部に8bitのUCHAR配列が格納されていることを意味している。そして0が終端。この終端コードも他の値にオーバーライド可能。 
 +--hello, worldと表示するために、文字列以外でのオーバーヘッドは2バイトである(51と終端の0)。他のOSのAPIで、API-CALLのためのパラメータ設定でここまで少ない手間でできるものがあるだろうか。普通、8bitレジスタに何か値を代入するだけでも2バイトを消費する。もしくは-128~+127の値をスタックにつむだけでも2バイトを使う。 
 +-50 8c "hello, world" 
 +--これは文字列の指定方法を別のやり方にした例。0も8bitのUCHAR配列だが、配列長は終端制ではなく、事前に指定する方法。つぎの8cはgh4による0x0cを意味しているので、配列長は12バイトだと分かる。 
 +-55 16 0 
 +--最初の5はやはりコンソールへの文字列出力ファンクション。次の5は文字列モード解除。これにより、配列を利用しないか、もしくは仮に配列などが指定されても、その長さが出力すべき文字長だとは判断しなくなる。次の1は文字長。つまり1文字。次の60はEAXレジスタのこと。その値が文字コードと解釈されることとなる。ちなみに6で始まるのはレジスタやスタックの値を表す。 
 +--結果として、putchar(EAX);になる。・・・これをやるのに普通のOSならどのくらい手間をかけるだろう。まあ、一文字表示は他のOSのほうが短いかもしれない。しかしそれは文字コードをALで指定している場合だけだろう。第二世代OSASKなら、EAX以外にもECXやEDXやEBXなどを指定できる(それぞれ61,62,63)。55 26 08 a などとすれば、printf("%c\n", EAX); もできる。 
 +* こめんと欄 [#id7e1272]
#comment #comment

トップ   差分 バックアップ 複製 名前変更 リロード印刷に適した表示   ページ新規作成 全ページ一覧 単語検索 最新ページの一覧   ヘルプ
新着

目次
メンバー一覧


最新の20件
2016-10-01 2016-09-08
  • @MenuBar.
2016-09-07 2016-09-04 2016-08-15 2015-09-23 2014-07-30 2014-07-04 2014-02-04 2013-10-26 2013-06-21 2013-06-17 2013-06-15 2013-04-02 2013-02-09 2013-02-04 2012-12-25 2012-12-01 2012-05-28 2012-03-31

トピック一覧
一般用コメント最新
新掲示板lina
2016/9/5 20:58
SandBoxゲスト
2016/9/4 12:01
RecentDeletedlina
2015/6/2 19:29
Old-OSASK-MLlina
2014/6/29 9:14
hideyosi/メールhideyosi
2014/1/6 20:17
hideyosi/募集中lina
2013/11/8 19:56

このサイトは川合秀実から委託を受けて、OSASKコミュニティによって管理・運営されています。