ページへ戻る

− Links

 印刷 

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

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

« Prev[4]  Next »[5]
2: 2008-04-28 (月) 22:50:18 ソース[6] 3: 2008-05-05 (月) 13:02:19 ソース[7]
Line 4: Line 4:
*** (12) 標準ライブラリ不要論? *** (12) 標準ライブラリ不要論?
-C言語には一般にprintfやputsやfopenなどの標準ライブラリというものがある。これの何がありがたいのかというと、これらの関数だけを使っている限りにおいてソース互換が達成されて、CPUやOSが違ってもソースコードを流用したり共用できるというものである。・・・まあでもこれは建前で、現実にはエンディアンやint幅の違いでただの再コンパイルだけではうまくいかない場合も少なくはない。 -C言語には一般にprintfやputsやfopenなどの標準ライブラリというものがある。これの何がありがたいのかというと、これらの関数だけを使っている限りにおいてソース互換が達成されて、CPUやOSが違ってもソースコードを流用したり共用できるというものである。・・・まあでもこれは建前で、現実にはエンディアンやint幅の違いでただの再コンパイルだけではうまくいかない場合も少なくはない。
--さて「ぐいぐい01」を使えば、このようなライブラリに頼らずともソースの完全互換どころかバイナリまで互換になる。エンディアンとかintの幅とかが違う心配も全くない。差異はせいぜい環境によって処理速度や画面の解像度が違うといった程度で、これは同じAT互換機間でも生じうる差だから、事実上、機種の違いはないといっていい。+-さて「ぐいぐい01」を使えば、このようなライブラリに頼らずともソースの完全互換どころかバイナリまで互換になる。エンディアンとかintの幅とかが違う心配も全くない。差異はせいぜい環境によって処理速度や画面の解像度が違うといった程度で、これは同じOSのAT互換機間でも生じうる差だから、事実上、機種の違いはないといっていい。
-そもそも標準ライブラリというのはオーバーヘッドが大きい。なぜならANSI-Cで定められた仕様を満たすために実際のAPIをラッピングして実装されており、直接APIを呼び出すのと比べればどうしても遅くて大きくなる。「ぐいぐい01」アプリでありさえすれば互換性について気にする必要なんかないのに、どうしてわざわざ効率の悪い標準ライブラリを使う必要があるだろうか。 -そもそも標準ライブラリというのはオーバーヘッドが大きい。なぜならANSI-Cで定められた仕様を満たすために実際のAPIをラッピングして実装されており、直接APIを呼び出すのと比べればどうしても遅くて大きくなる。「ぐいぐい01」アプリでありさえすれば互換性について気にする必要なんかないのに、どうしてわざわざ効率の悪い標準ライブラリを使う必要があるだろうか。
--「ぐいぐい01」がエミュレータを使わずに互換性を提供できる範囲は、確かにそんなには広くない。というのはIA-32でなくてはいけないからである。しかしちょっと考えてみてほしい、今IA-32が使えない環境がどれほどあるだろうか。MacもIA-32になってしまった。TOWNSもPC-98も昔からIA-32だ(PC-98の286までの機種を除く)。・・・なるほど、[[K]]のお気に入りのGBAなど、IA-32ではない機種も確かに存在するが、それはどちらかというと組み込み環境であって、そういうものではそもそも標準ライブラリが完全に用意されているとは限らない。+-「ぐいぐい01」がエミュレータを使わずに互換性を提供できる範囲は、確かにそんなには広くない。というのはIA-32でなくてはいけないからである。しかしちょっと考えてみてほしい、今IA-32が使えない環境がどれほどあるだろうか。MacもIA-32になってしまった。TOWNSもPC-98も昔からIA-32だ(PC-98の286までの機種を除く)。・・・なるほど、[[K]]のお気に入りのGBAなどIA-32ではない機種も確かに存在するが、それはどちらかというと組み込み環境であって、そういうものではそもそも標準ライブラリが完全に用意されているとは限らない。
-この考えで行くと、標準ライブラリを使わないようにすることで失われるのはX68Kとのソース互換やPowerPCマックや68マックとのソース互換くらいなものである。逆に標準ライブラリよりも「ぐいぐい01」のAPIを直接使うようにすれば、オーバーヘッドが少なくて効率が良いアプリが得られるわけで、この利益はX68Kや旧Macとのソース互換をあきらめても十分につりあうものだと思う(X68Kや旧Macしかもっていない人が、「ぐいぐい01」アプリを使うためにX68Kや旧Mac程度の処理能力の中古PCを代替で購入したとしても、そのコストは十分に小さいと考えられるから。しかもOSASKやOSASK-HB上で動かすことにするなら、アプリの高効率性との相乗効果で、さらに1ランク下のPCでも十分かもしれない)。 -この考えで行くと、標準ライブラリを使わないようにすることで失われるのはX68Kとのソース互換やPowerPCマックや68マックとのソース互換くらいなものである。逆に標準ライブラリよりも「ぐいぐい01」のAPIを直接使うようにすれば、オーバーヘッドが少なくて効率が良いアプリが得られるわけで、この利益はX68Kや旧Macとのソース互換をあきらめても十分につりあうものだと思う(X68Kや旧Macしかもっていない人が、「ぐいぐい01」アプリを使うためにX68Kや旧Mac程度の処理能力の中古PCを代替で購入したとしても、そのコストは十分に小さいと考えられるから。しかもOSASKやOSASK-HB上で動かすことにするなら、アプリの高効率性との相乗効果で、さらに1ランク下のPCでも十分かもしれない)。
-ということで[[K]]は、「ぐいぐい01」が出来上がって行くにつれて、自作アプリでは標準ライブラリを使わなくして行こうと思う(今後はwin32アプリなどはほとんど作らない予定)。そしてそのうち標準ライブラリの関数名や引数の順番を忘れちゃうんだと思うけど、それでも忘れないように努力するみたいなことは一切しないと思う。そんなことするくらいなら「ぐいぐい01」のAPIを覚えておくほうがマシだと思うから。 -ということで[[K]]は、「ぐいぐい01」が出来上がって行くにつれて、自作アプリでは標準ライブラリを使わなくして行こうと思う(今後はwin32アプリなどはほとんど作らない予定)。そしてそのうち標準ライブラリの関数名や引数の順番を忘れちゃうんだと思うけど、それでも忘れないように努力するみたいなことは一切しないと思う。そんなことするくらいなら「ぐいぐい01」のAPIを覚えておくほうがマシだと思うから。
---- ----
-こうしてみると、なんで世の中の人たちは「ぐいぐい01」のようなアプローチをしなかったんだろうと思う。WindowsとLinuxとMacOS(BSD?)とTownsOS(DOS-Extender)で共通のアプリが作れるようにしていればよかったのに。これらに対して共通のOSを用意しないといけないと思っていたのかな、でもefg01で分かるようにそんなことしなくてもバイナリ互換は達成可能だったのに。そしてアプリが共通化されていれば、ソフトウェア資産なんてドライバくらいしか優劣がなくなるから、OS同士の競争が進んでOSも進化しただろうに。まあいいや、誰もやってくれなかったから僕がやっているわけで、僕は苦労する代わりに「世界初」という肩書きももらっておくことにするよ。きっとjavaや.netでこれをやったつもりになっているんだろうな。でもjavaや.netではオーバーヘッドが大きすぎて「ぐいぐい01」の代わりにはならないと思う。 -こうしてみると、なんで世の中の人たちは「ぐいぐい01」のようなアプローチをしなかったんだろうと思う。WindowsとLinuxとMacOS(BSD?)とTownsOS(DOS-Extender)で共通のアプリが作れるようにしていればよかったのに。これらに対して共通のOSを用意しないといけないと思っていたのかな、でもefg01で分かるようにそんなことしなくてもバイナリ互換は達成可能だったのに。そしてアプリが共通化されていれば、ソフトウェア資産なんてドライバくらいしか優劣がなくなるから、OS同士の競争が進んでOSも進化しただろうに。まあいいや、誰もやってくれなかったから僕がやっているわけで、僕は苦労する代わりに「世界初」という肩書きももらっておくことにするよ。きっとjavaや.netでこれをやったつもりになっているんだろうな。でもjavaや.netではオーバーヘッドが大きすぎて「ぐいぐい01」の代わりにはならないと思う。
 +
 +*** (13) バージョン対応表
 +-(2008.05.05時点)
 +-abcdw003
 +--win32版、バージョンリーダー、[OSASK 00105]
 +-abcdm000
 +--MonaOS用、abcdw003相当(完全互換)、[OSASK 00107]
* こめんと欄 * こめんと欄
#comment #comment
« Prev[4]  Next »[5]