1: 2009-01-03 (土) 09:20:25 |
2: 2009-11-17 (火) 12:08:40 |
| --APIがANSI-Cの標準関数にかなり近い。つまり既存アプリをCOM64plusへ移植するのは容易。「ぐいぐい01」が独自APIだらけなのとは大きく異なる。 | | --APIがANSI-Cの標準関数にかなり近い。つまり既存アプリをCOM64plusへ移植するのは容易。「ぐいぐい01」が独自APIだらけなのとは大きく異なる。 |
| --アセンブラレベルでAPIを見ると、gh4によるAPIパケットを採用した「ぐいぐい01」とは大きく異なり、スタックやレジスタを利用したAPIになっている。率直に言って実に素直な設計で、好感が持てる(素朴なようでありながら、実はよく考えられてもいる)。 | | --アセンブラレベルでAPIを見ると、gh4によるAPIパケットを採用した「ぐいぐい01」とは大きく異なり、スタックやレジスタを利用したAPIになっている。率直に言って実に素直な設計で、好感が持てる(素朴なようでありながら、実はよく考えられてもいる)。 |
- | - | + | -僕はとりあえず複数のアーキテクチャバイナリを一つのファイルにまとめる機能に関してはあまり興味がないので(まだそういう機能があったらいいのにと実感する体験をしていないだけなのです、どうもすみません)、以下はもっぱら残りの2つの設計方針の違いについて勝手な感想を言いたいと思います。 |
| + | -まず、APIの仕様が標準関数に近いということから行きましょう。僕の考えでは、標準関数の仕様は実際のアプリから見て使いやすくはなっていないのです。ここでいう使いやすくないというのは、人間にとってプログラムが書きやすいかどうかではなく、コンパイルして出てきたバイナリがあまり小さくはならないという意味です。がんばって最適化しても、APIの仕様がボトルネックになって限界にきそうな感じがします。・・・それで僕は、小さいアプリがより容易に書けるようにと、標準関数の仕様にとらわれずにAPIを設計していて、それで結果として独自仕様になったのです。 |
| + | -しかし、僕のこの「標準関数の仕様は実際のアプリから見て使いやすくはなっていない」は本当でしょうか。僕がそう思い込んでいるだけかもしれません。特にCOM64plusがサイズ競争で「ぐいぐい01」に肉薄できていることからも、僕の考えは浅はかだったのかもしれないのです(まだC言語記述アプリでの比較ができていないのでなんとも言えないのですが)。・・・つまりCOM64plusは僕があまり検討もしないで見限った路線にあえて突き進み、その上成果まで上げているわけです。これはすごいことですし、期待しないではいられません。 |
| + | -僕としては独自APIの優位性があまりないようであれば、標準関数のサポートも徐々に追加していくつもりです(そして独自API関数を標準関数APIを使って実行する形にして、ライブラリ関数に格下げする)。逆にCOM64plusがあまりサイズで優位に立てなかった場合には、「ぐいぐい01」風の独自APIを追加していくのか、それともそういうことはしないで潔く標準関数風で押し通すのか、それはまだ分かりません(サイズをどのくらい重視しているのかも分かりませんので)。もし僕と同じくらいにサイズに執着(笑)するのなら、双方が相手の長所を盗み合って、最終的にはどちらもよく似たAPIを持つようになり、ハイレベルな競争が繰り広げられる・・・なんてことになったらいいなと思います。 |
| + | -次はgh4によるAPIパケットか、もっと普通のパラメータ受け渡しかについてです。僕はgh4によるAPIパケットを使うことによってアプリが小さくなってその分キャッシュミスが減って結果的に全体的に速度は速くなる(もしくは遅くならない)という説を採っていますが、仮にgh4でも普通の方法でも対してサイズが変わらないとしましょう。そうであれば、速度が出るのは間違いなくCOM64plusの方法です。ということで、僕は自分の方法にこそサイズ面の優位性があると信じていますが、例によってCOM64plusがサイズ競争で「ぐいぐい01」に肉薄できていることからも、僕の考えは浅はかだったのかもしれないのです(まだC言語記述アプリでの比較が・・・以下略)。 |
| + | -COM64plusの今後が楽しみです。 |
| | | |
| * こめんと欄 | | * こめんと欄 |
| | | |
| #comment | | #comment |