ページへ戻る

− Links

 印刷 

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

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

« Prev[4]  Next »[5]
3: 2008-12-21 (日) 11:29:46 ソース[6] 4: 2008-12-21 (日) 17:38:12 ソース[7]
Line 9: Line 9:
-またchars+.comはついに15バイトにまでなり、でも「ぐいぐい01」もがんばって16バイトまではきました。もとが33バイトだったのに16バイトだなんてもはや半減です。DOS版が17バイトなので、やはりこれもneriさんは世界記録保持者だと思います。 -またchars+.comはついに15バイトにまでなり、でも「ぐいぐい01」もがんばって16バイトまではきました。もとが33バイトだったのに16バイトだなんてもはや半減です。DOS版が17バイトなので、やはりこれもneriさんは世界記録保持者だと思います。
-その後さらにもう一段僕が改良し(これはneriさんには応用しにくい改良)、helloは何とかneriさんに追いつきました。これで世界記録タイです。charsは追いつけませんでした。またechoも作りました。neriさんは作ってないので比べられません。 -その後さらにもう一段僕が改良し(これはneriさんには応用しにくい改良)、helloは何とかneriさんに追いつきました。これで世界記録タイです。charsは追いつけませんでした。またechoも作りました。neriさんは作ってないので比べられません。
--以下にここまでの成果(多分これが限界でもあると思う)を書いておきます。+-(12.21追記)neriさんは起動時のECX初期値をコンパクトに設定できる形式を導入して1バイトの削減に成功。これでほぼ全てのアプリが1バイト以上小さくなることに。僕も負けじと考えて出現頻度の非常に高いパラメータを省略できるように改良。これで多くのアプリが1バイト以上小さくなることに。 
 +-以下にここまでの成果(多分これが限界でもあると思う)を書いておきます。[2008.12.21更新]
|          |hello      |hello-c    |chars      |echo        |echo-c      | |          |hello      |hello-c    |chars      |echo        |echo-c      |
|abcdw006用 |RIGHT:27    |RIGHT:86    |RIGHT:33    |?          |RIGHT:156  | |abcdw006用 |RIGHT:27    |RIGHT:86    |RIGHT:33    |?          |RIGHT:156  |
-|abcdw007用 |RIGHT:''21''|RIGHT:''71''|RIGHT:16    |RIGHT:''19''|RIGHT:''75''| +|abcdw007用 |RIGHT:''20''|RIGHT:''70''|RIGHT:16    |RIGHT:''18''|RIGHT:''74''| 
-|COM64plus用|RIGHT:''21''|検討中?    |RIGHT:''15''|?          |?          | +|COM64plus用|RIGHT:''20''|検討中?    |RIGHT:''14''|?          |?          | 
-|DOS用      |RIGHT:22    |?          |RIGHT:17    |RIGHT:''19''|?          |+|DOS用      |RIGHT:22    |?          |RIGHT:17    |RIGHT:19   |?          |
--(註)echoはargv[0]が見えても見えなくてもよい。 --(註)echoはargv[0]が見えても見えなくてもよい。
--echoはもちろんジャンクAPIで実現しているが、ジャンクAPIはジャンクであるというマークがついている分だけ実行ファイルが長くなる傾向がある。もし他の部分は一切変えずに本仕様に昇格させれば、それだけでechoもecho-cも2バイトは縮むだろう。 --echoはもちろんジャンクAPIで実現しているが、ジャンクAPIはジャンクであるというマークがついている分だけ実行ファイルが長くなる傾向がある。もし他の部分は一切変えずに本仕様に昇格させれば、それだけでechoもecho-cも2バイトは縮むだろう。
-abcdw006→abcdw007の仕様変更はかなり大きなもので、基本的にバイナリ互換はありません。ソース互換すらほどほどしかありません。大規模改造なので僕も非常に苦労しています(アプリの移植はそれほどでもないけど、efg01の改造が大変)。 -abcdw006→abcdw007の仕様変更はかなり大きなもので、基本的にバイナリ互換はありません。ソース互換すらほどほどしかありません。大規模改造なので僕も非常に苦労しています(アプリの移植はそれほどでもないけど、efg01の改造が大変)。
--これはまさに「乾いた雑巾を絞る」レベルの改良で、その中にあってcharsが半減したり、echo-cが半減したりと、ちょっとありえない劇的な進歩になっています。それもこれもみんなneriさんの協力のおかげです。・・・neriさんなしで一人でやっていたらこの設計に到達するまでに1年間はかかったと思います。あとやぱっぱりabcdw006までで小さいアプリをたくさん作ってきて、ボトルネックというか、「こんな仕様だったらいいのに」を実感していたのもあると思います。 +-これはまさに「乾いた雑巾を絞る」レベルの改良で、その中にあってcharsが半減したり、echo-cが半減したりと、ちょっとありえない劇的な進歩になっています。それもこれもみんなneriさんの協力のおかげです。・・・neriさんなしで一人でやっていたらこの設計に到達するまでに1年間はかかったと思います。あとやっぱりabcdw006までで小さいアプリをたくさん作ってきて、ボトルネックというか、「こんな仕様だったらいいのに」を実感していたのもあると思います。 
--それにhello-cも static char s[18] = "\x35\x01\x24\x8d" "hello, world\n" "\x23"; なんていういかにも「うさんくさい」「こんなの普通書くわけない」といった方法での86バイトだったのが、 g01_putstr0("hello, world"); という普通の書き方で71バイトになるようになっています。汚く書いたらもう少し小さくなるかもしれませんがまああまり変わらないでしょう。+-それにhello-cも static char s[18] = "\x35\x01\x24\x8d" "hello, world\n" "\x23"; なんていういかにも「うさんくさい」「こんなの普通書くわけない」といった方法での86バイトだったのが、 g01_putstr0("hello, world"); という普通の書き方で70バイトになるようになっています(12.21:バイト数更新)。汚く書いたらもう少し小さくなるかもしれませんがまああまり変わらないでしょう。
-という劇的な大進歩なので、互換性がちょっと不足気味だったりリリースにてこずったりしても、どうか大目にみてください。 -という劇的な大進歩なので、互換性がちょっと不足気味だったりリリースにてこずったりしても、どうか大目にみてください。
-「こんな互換性に問題の出るバージョンアップが繰り返されたら安心してアプリを作れないじゃないか!」というのはもっともです。「いったいいつになったら落ち着くんだ?」といいたくなるでしょう。しかしこれは永遠に続くわけではないのです。というのはたとえばhelloは文字列だけで13バイトあって、しかも.g01のシグネチャだけで2バイトあるのですから、これだけでも最低15バイトは必要です。これより小さくなることはありえません(一般的なAPIとして不適切な設計にしない限り)。もちろんテキストファイルじゃないので他にも書かなければいけない何らかの情報やプログラムがあるわけですから、どのアプリもAPIを改良すればどこまでも小さくなるわけではないのです。限界があるのです。その限界に達してしまえば、それ以上どんなにいじってもより小さくなることはないので、仕様のバージョンアップが起きることはないはずです。 -「こんな互換性に問題の出るバージョンアップが繰り返されたら安心してアプリを作れないじゃないか!」というのはもっともです。「いったいいつになったら落ち着くんだ?」といいたくなるでしょう。しかしこれは永遠に続くわけではないのです。というのはたとえばhelloは文字列だけで13バイトあって、しかも.g01のシグネチャだけで2バイトあるのですから、これだけでも最低15バイトは必要です。これより小さくなることはありえません(一般的なAPIとして不適切な設計にしない限り)。もちろんテキストファイルじゃないので他にも書かなければいけない何らかの情報やプログラムがあるわけですから、どのアプリもAPIを改良すればどこまでも小さくなるわけではないのです。限界があるのです。その限界に達してしまえば、それ以上どんなにいじってもより小さくなることはないので、仕様のバージョンアップが起きることはないはずです。
« Prev[4]  Next »[5]