サイトトップへ
OSASK.NET
  サイトトップへ       新掲示板(閉鎖済)   Wiki(凍結済)   旧掲示板(廃止済)   ニュース(廃止済)  
6: 2008-12-22 (月) 11:54:36 ソース 現: 2024-01-08 (月) 12:58:42 lina ソース
Line 1: Line 1:
-* ぐいぐい01に関するメモ-14+TITLE:x 
 +* ぐいぐい01に関するメモ-14 [#j68ff7f1]
-(by [[K]], 2008.12.20) -(by [[K]], 2008.12.20)
-メモのうち重要な部分をそのうちまとめてまともなページを作る -メモのうち重要な部分をそのうちまとめてまともなページを作る
-*** (29) 2008.12.20近況+*** (29) 2008.12.20近況 [#e218b448]
-ここ1週間ほどの開発がここ数年で最高に充実していてかつ面白かったので記念でメモ。 -ここ1週間ほどの開発がここ数年で最高に充実していてかつ面白かったので記念でメモ。
-少し前からOSASK-IRCにneriさんが常駐してくれていて、それでCOM64-GREの改良の話をしました。いろいろと改良してアーカイブ風になったあと、もっとコンパクトの役に立つ仕様にしたいということで、二人でどうしたらいいかを話し合いました。長すぎるシグネチャを短くするべきか、みたいなところが出発点だったと思います。こうしてCOM64plusの開発が始まりました。シグネチャを4バイトにするべきか2バイトにするべきか、そこも悩ましいところでした。 -少し前からOSASK-IRCにneriさんが常駐してくれていて、それでCOM64-GREの改良の話をしました。いろいろと改良してアーカイブ風になったあと、もっとコンパクトの役に立つ仕様にしたいということで、二人でどうしたらいいかを話し合いました。長すぎるシグネチャを短くするべきか、みたいなところが出発点だったと思います。こうしてCOM64plusの開発が始まりました。シグネチャを4バイトにするべきか2バイトにするべきか、そこも悩ましいところでした。
Line 11: Line 12:
-(12.21追記)neriさんは起動時のECX初期値をコンパクトに設定できる形式を導入して1バイトの削減に成功。これでほぼ全てのアプリが1バイト以上小さくなることに。僕も負けじと考えて出現頻度の非常に高いパラメータを省略できるように改良。これで多くのアプリが1バイト以上小さくなることに。 -(12.21追記)neriさんは起動時のECX初期値をコンパクトに設定できる形式を導入して1バイトの削減に成功。これでほぼ全てのアプリが1バイト以上小さくなることに。僕も負けじと考えて出現頻度の非常に高いパラメータを省略できるように改良。これで多くのアプリが1バイト以上小さくなることに。
-(12.22追記)昨日neriさんがオプションでCALL(EBP);をコードに追加する機能を付けるべきなんじゃないかと提案しました。この機能を付けるべきかいろいろ試行錯誤した結果、確かに付けたほうがいいと僕は判断しました(.g01の場合は先頭に付ける、COM64plusの場合は末尾に付ける)。またコマンドライン取得APIの仕様が勘違いで間違っていたことに気付いて修正したところ、このAPIが更に使いやすくなりました。これでまたサイズがかなり減っています。なおneriさん自身はまだCALL(EBP);の自動付加オプションをやるという決断にはいたっていないようです(でもきっとあとでやるとは思う)。helloが18バイトで書けるということは、ついにバッチファイルともタイだということです。ちなみにechoの13バイトはバッチファイルで"@echo %1 %2 %3"って書くだけで14バイトなので、すでにバッチファイルにも十分に勝っていると思います。 -(12.22追記)昨日neriさんがオプションでCALL(EBP);をコードに追加する機能を付けるべきなんじゃないかと提案しました。この機能を付けるべきかいろいろ試行錯誤した結果、確かに付けたほうがいいと僕は判断しました(.g01の場合は先頭に付ける、COM64plusの場合は末尾に付ける)。またコマンドライン取得APIの仕様が勘違いで間違っていたことに気付いて修正したところ、このAPIが更に使いやすくなりました。これでまたサイズがかなり減っています。なおneriさん自身はまだCALL(EBP);の自動付加オプションをやるという決断にはいたっていないようです(でもきっとあとでやるとは思う)。helloが18バイトで書けるということは、ついにバッチファイルともタイだということです。ちなみにechoの13バイトはバッチファイルで"@echo %1 %2 %3"って書くだけで14バイトなので、すでにバッチファイルにも十分に勝っていると思います。
--以下にここまでの成果(多分これが限界でもあると思う)を書いておきます。[2008.12.22更新+-(12.24追記)CALL(EBP);をやめてCALL([ESI]);にすることにしました。これだとEBPがあくので好きなことができます。アセンブラ版のバイト数は変わりません。でもC言語版のバイト数は1バイトくらい減らせそうです。・・・さらにCOM64plusのマネをしてレジスタの初期値ロード機能をオプションでつけました。これでcharsが16から14になりました。COM64plusに追いついた! 
-|          |hello      |hello-c    |chars      |echo       |echo-c      | +-以下にここまでの成果(多分これが限界でもあると思う)を書いておきます。[2009.01.02更新
-|abcdw006用 |RIGHT:27    |RIGHT:86    |RIGHT:33    |RIGHT:?   |RIGHT:156  | +|          |hello      |hello-c    |chars      |echo       |echo-c      |cpy        |cpy-c        |makefont-c  |sjisconv-c
-|abcdw007用 |RIGHT:''18''|RIGHT:''70''|RIGHT:16   |RIGHT:''13''|RIGHT:''72''| +|abcdw006用 |RIGHT:27    |RIGHT:86    |RIGHT:33    |RIGHT:?   |RIGHT:156  |RIGHT:?    |RIGHT:612    |RIGHT:691    |RIGHT:912
-|COM64plus用|RIGHT:20    |検討中?    |RIGHT:''14''|RIGHT:?    |RIGHT:?    | +|abcdw007用 |RIGHT:18    |RIGHT:69    |RIGHT:14    |RIGHT:13  |RIGHT:71    |RIGHT:?    |RIGHT:342    |RIGHT:347    |RIGHT:507| 
-|DOS用      |RIGHT:22    |RIGHT:?    |RIGHT:17    |RIGHT:19    |RIGHT:?    |+|abcdw008用 |RIGHT:18    |RIGHT:69    |RIGHT:14    |RIGHT:''6''|RIGHT:51    |RIGHT:''45''|RIGHT:138   |RIGHT:207    |RIGHT:395| 
 +|abcdw009用 |RIGHT:''17''|RIGHT:''68''|RIGHT:''13''|RIGHT:''6''|RIGHT:''50''|RIGHT:''45''|RIGHT:''134''|RIGHT:''203''|RIGHT:''389''| 
 +|COM64plus用|RIGHT:18?  |検討中?    |RIGHT:14   |RIGHT:?  |RIGHT:?    |RIGHT:?    |RIGHT:?    |RIGHT:?    |RIGHT:?
 +|DOS用      |RIGHT:22    |RIGHT:?    |RIGHT:17    |RIGHT:19   |RIGHT:?   |RIGHT:?    |RIGHT:?    |RIGHT:?    |RIGHT:?|
--(註)echoはargv[0]が見えても見えなくてもよい。 --(註)echoはargv[0]が見えても見えなくてもよい。
---echoはもちろんジャンクAPIで実現しているが、ジャンクAPIはジャンクであるというマークがついている分だけ実行ファイルが長くなる傾向がある。もし他の部分は一切変えずに本仕様に昇格させれば、それだけでechoもecho-cも2バイトは縮むだろう。+--echoはもちろんジャンクAPIで実現しているが、ジャンクAPIはジャンクであるというマークがついている分だけ実行ファイルが長くなる傾向がある。もし他の部分は一切変えずに本仕様に昇格させれば、それだけでechoもecho-cも2バイトは縮むだろう。・・・というのはabcdw007までの仕様でのことで、abcdw008以降については本仕様級の仕様なので、ここから減ることはない。
-abcdw006→abcdw007の仕様変更はかなり大きなもので、基本的にバイナリ互換はありません。ソース互換すらほどほどしかありません。大規模改造なので僕も非常に苦労しています(アプリの移植はそれほどでもないけど、efg01の改造が大変)。 -abcdw006→abcdw007の仕様変更はかなり大きなもので、基本的にバイナリ互換はありません。ソース互換すらほどほどしかありません。大規模改造なので僕も非常に苦労しています(アプリの移植はそれほどでもないけど、efg01の改造が大変)。
-これはまさに「乾いた雑巾を絞る」レベルの改良で、その中にあってcharsが半減したり、echo-cが半減したりと、ちょっとありえない劇的な進歩になっています。それもこれもみんなneriさんの協力のおかげです。・・・neriさんなしで一人でやっていたらこの設計に到達するまでに1年間はかかったと思います(その後の改良のペースもすごいのでトータルで2年分くらいは進んでいる気がする)。あとやっぱりabcdw006までで小さいアプリをたくさん作ってきて、ボトルネックというか、「こんな仕様だったらいいのに」を実感していたのもあると思います。 -これはまさに「乾いた雑巾を絞る」レベルの改良で、その中にあってcharsが半減したり、echo-cが半減したりと、ちょっとありえない劇的な進歩になっています。それもこれもみんなneriさんの協力のおかげです。・・・neriさんなしで一人でやっていたらこの設計に到達するまでに1年間はかかったと思います(その後の改良のペースもすごいのでトータルで2年分くらいは進んでいる気がする)。あとやっぱりabcdw006までで小さいアプリをたくさん作ってきて、ボトルネックというか、「こんな仕様だったらいいのに」を実感していたのもあると思います。
--それにhello-cも static char s[18] = "\x35\x01\x24\x8d" "hello, world\n" "\x23"; なんていういかにも「うさんくさい」「こんなの普通書くわけない」といった方法での86バイトだったのが、 g01_putstr0("hello, world"); という普通の書き方で70バイトになるようになっています(12.21:バイト数更新)。汚く書いたらもう少し小さくなるかもしれませんがまああまり変わらないでしょう。+-それにhello-cも static char s[18] = "\x35\x01\x24\x8d" "hello, world\n" "\x23"; なんていういかにも「うさんくさい」「こんなの普通書くわけない」といった方法での86バイトだったのが、 g01_putstr0("hello, world"); という普通の書き方で69バイトになるようになっています(12.24:バイト数更新)。汚く書いたらもう少し小さくなるかもしれませんがまああまり変わらないでしょう。
-という劇的な大進歩なので、互換性がちょっと不足気味だったりリリースにてこずったりしても、どうか大目にみてください。 -という劇的な大進歩なので、互換性がちょっと不足気味だったりリリースにてこずったりしても、どうか大目にみてください。
-「こんな互換性に問題の出るバージョンアップが繰り返されたら安心してアプリを作れないじゃないか!」というのはもっともです。「いったいいつになったら落ち着くんだ?」といいたくなるでしょう。しかしこれは永遠に続くわけではないのです。というのはたとえばhelloは文字列だけで13バイトあって、しかも.g01のシグネチャだけで2バイトあるのですから、これだけでも最低15バイトは必要です。これより小さくなることはありえません(一般的なAPIとして不適切な設計にしない限り)。もちろんテキストファイルじゃないので他にも書かなければいけない何らかの情報やプログラムがあるわけですから、本当の限界はもっと大きい値でしょう。どのアプリもAPIを改良すればどこまでも小さくなるわけではないのです。限界があるのです。その限界に達してしまえば、それ以上どんなにいじってもより小さくなることはないので、仕様のバージョンアップが起きることはないはずです。 -「こんな互換性に問題の出るバージョンアップが繰り返されたら安心してアプリを作れないじゃないか!」というのはもっともです。「いったいいつになったら落ち着くんだ?」といいたくなるでしょう。しかしこれは永遠に続くわけではないのです。というのはたとえばhelloは文字列だけで13バイトあって、しかも.g01のシグネチャだけで2バイトあるのですから、これだけでも最低15バイトは必要です。これより小さくなることはありえません(一般的なAPIとして不適切な設計にしない限り)。もちろんテキストファイルじゃないので他にも書かなければいけない何らかの情報やプログラムがあるわけですから、本当の限界はもっと大きい値でしょう。どのアプリもAPIを改良すればどこまでも小さくなるわけではないのです。限界があるのです。その限界に達してしまえば、それ以上どんなにいじってもより小さくなることはないので、仕様のバージョンアップが起きることはないはずです。
--現状を見てください。なんかもうひどく限界に近い気がしませんか?まあ僕だってabcdw006の段階で既に限界だと思っていました。だからそういう「感じ」が必ずしもあてになるわけではないのですが、しかし大いに参考になる目安だとは思います。・・・早く限界に近づかせる方法は、このサイズを追求する人がさらに増えて、この分野の研究が進むことしかないでしょう。 +-現状を見てください。なんかもうひどく限界に近い気がしませんか?まあ僕だってabcdw006の段階で既に限界だと思っていました。だからそういう「感じ」が必ずしもあてになるわけではないのですが、しかし大いに参考になる目安だとは思います。・・・早く限界に近づかせる方法は、サイズを追求する人がさらに増えて、この分野の研究が進むことしかないでしょう。 
-|          |pi      |calc      | +-以下にabcdw006との比較を書いておきます(全部C言語のみ)。[2008.12.24更新] 
-|abcdw006用|RIGHT:241|RIGHT:1583| +|          |pi      |calc      |cpy      |makefont |bim2hrb  |sjisconv |gas2nask  |nask     
-|abcdw007用|RIGHT:206|RIGHT:1520+|abcdw006用|RIGHT:241|RIGHT:1583|RIGHT:612|RIGHT:691|RIGHT:987|RIGHT:912|RIGHT:(5114)    |RIGHT:23314
---(註)piは.hrb版の229バイトに対して逆転に成功。 +|abcdw007用|RIGHT:205|RIGHT:1521|RIGHT:386|RIGHT:439|RIGHT:766|RIGHT:644|RIGHT:5001|RIGHT:23040
---calcはこのサイズより小さくCで書く方法がないということではない。オリジナルのhrb版のソースにできるだけ近いソースを使わなければいけない(コマンドラインバッファをより長くすることだけは許される)。その制約を自ら科しているためにこのサイズに留まっている。 +--(註)piは.hrb版の229バイトに対して逆転に成功。参考までに書いておくとcalc.hrbは1668バイト。 
-* こめんと欄+--calcはこのサイズより小さくCで書く方法がないということではない。オリジナルのhrb版のソースにできるだけ近いソースを使わなければいけないという制約を自ら科しているためにこのサイズに留まっている(コマンドラインバッファをより長くすることだけは許される)。 
 +|          |obj2bim  |bim2g01    |bin2obj  |naskcnv0  |aksa      |golib00  | 
 +|abcdw006用|RIGHT:7211|RIGHT:(1956)|RIGHT:983|RIGHT:2050|RIGHT:5311|RIGHT:2749| 
 +|abcdw007用|RIGHT:6903|RIGHT:1792  |RIGHT:729|RIGHT:1778|RIGHT:5079|RIGHT:2476| 
 +-(12.25追記)昨日とりあえずabcdw007をアップロードしたのですが、一日たってぼんやり眺めていると、なんかcpyが386バイトやmakefontが439バイトと、どちらも512バイト未満に収まっているのに対して、sjisconvが644バイトに留まっているのがなんか気にいりません。そんなに複雑な処理をしているわけでもないのに・・・。で、数十分ほどいじっていたらなんとか減量に成功して507バイトになりました。うんうん、こうでなくっちゃ。で、sjisconvの減量に成功してみると、今度はcpyやmakefontも小さくしてやろうかなという気になりました。どちらも10分くらいでそれなりに小さくなりました。ということで、その成果を。・・・いやあやっぱり、APIが使いやすいと減量も簡単です(というかabcdw007版がとにかく新efg01で動けばいいやで手抜き過ぎた?)。たぶん他のアプリも手入れすればそれぞれ100バイトくらい減量できそうですが、時間もないしめんどくさいのでいつか気が向いたときにします。 
 +|          |sjisconv |cpy      |makefont | 
 +|abcdw007版|RIGHT:644|RIGHT:386|RIGHT:439| 
 +|改良版    |RIGHT:507|RIGHT:342|RIGHT:347| 
 +-(12.26追記)しばらく開発しないといっておきながら、突発的にcpyをnaskで書いたら何バイトになるのかが気になって(たぶん禁断症状)、それで作ってみました(実際はASKAで書きました)。abcdw008で実装予定の(つまりまだ未実装の)APIを勝手に使って書いたところ、cpyは51バイトで書けることが分かりました。うおおおぉー。これはすごい。やっぱりアセンブラは偉大だー。あとはこの51バイトを使いたくてしょうがなくなったらabcdw008を作ることにします(笑)。ちなみにこのAPIを使うとechoは11バイトになります。他のアプリもみんな100バイトくらいは減るんじゃないかなあ。もちろん上記で減量に成功したsjisconvやmakefontも。 
 +-(12.27追記)コマンドライン周りの設計中(本仕様級)。以前は数ヶ月かけてもできなかったのに、今だと数日でこんなにはかどる。でも時間がないので比較的ゆっくり。ちなみに昨日のcpyのASKA版は更に見直しで45バイトになり、echoも9バイトになりました。 
 +-(12.28追記)abcdw008向けのmakefont-c(現在207バイト)をASKAで書いたら72バイトになった。やっぱりアセンブラは偉大だー。 
 +-(01.02追記)アイデアを思いついた!ので現在効果を見積もり中(abcdw009)。とりあえずバイナリ互換はなくなります。・・・アプリを丁寧に作るとそれだけ小さくなってくれるので、すごく気持ちがいいです。やりがい一杯、手ごたえ一杯。やっぱりこうでないと! 
 +* こめんと欄 [#fa2e7236] 
 +- 現在abcdw007の今週中のリリースを目指してがんばり中。 -- [[K]] &new{2008-12-22 (月) 20:33:28}; 
 +- とりあえずリリースしました。MLへは後日投稿します。 -- ''K'' &new{2008-12-24 (水) 20:10:07}; 
 +- abcdw008ができましたー。 http://osask.jp/files/ 6バイトのechoや45バイトのcpyなど、こんなので本当にちゃんと動くの?といいたくなるサイズのアプリが一杯です。MLへは後日投稿します。 -- ''K'' &new{2009-01-01 (木) 21:14:50}; 
 +- abcdw009ができましたー。 http://osask.jp/files/ abcdw009があればabcdw008はいらないようになっています(というか以前のバージョンは全部なくても大丈夫)。MLへは後日投稿します。 -- ''K'' &new{2009-01-03 (土) 19:39:07}; 
#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コミュニティによって管理・運営されています。