こんにちは、川合です。
毎度のbim2binのバージョンアップです。だいぶ完成度が上がってき
ました。が、申し訳ないことにまたフォーマット変更です。今後はフォ
ーマット変更はしないつもりですが、それを言ったら今までだってフォ
ーマット変更をしないつもりだったので、それほど確たるものではあり
ません（苦笑）。
とにかくもうtek1では当初予定していた圧縮方法を一通り実装しまし
た。tek2では効果の小さそうな改善点一つを残すのみです（これは既に
フォーマットに組み込み済みで、単に圧縮ルーチンがこれを活用してい
ないだけ）。もうそろそろ仕様を固定してもいいと思っているのですが
、またいきなり何かをひらめく可能性もあるので断言はできません。
bim2bin4fからのバージョンアップ点は次のとおりです。
(1)UC0のパラメータ最適化ルーチンを強化して、さらにデフォルトが
強くなった。
(2)符号寿命を導入。これによりでかいファイルは圧縮パラメータを
時々切り替えるようになる。この機能によりkdun00bやosaskgoでの
圧縮率が大きく改善。しかしhellok1やhelloc9などの小さなファイ
ルでは、寿命情報のせいで圧縮率改悪。
(3)符号寿命の効果が予想を越えていた上に、全てのパラメータを一度
に変更しないで部分的に切り替えていくほうが、圧縮率がよくなる
らしい。ということで部分ごとに独立した符号寿命をサポート。こ
れによりさらに圧縮率は改善したが、bim2bin4fとのフォーマット
互換はなくなった。またこれでさらに小さいファイルは不利になっ
た。
(4)tek1のフォーマットがややこしくなってきたので、圧縮データが
1バイト増えるのを許容してフォーマット再編。これにより小さい
tek1ファイルは、今までの改悪（？）が積もってtek0並みの圧縮率
にまで低下した。tek2でも旧tek1くらいになっていた。
(5)OSASKアプリのほとんどは「小さいファイル」に相当するため、こ
れがtek0・旧tek1程度にしか圧縮できないというのは、非常に悲し
い。そこでどうにかならないかと思い悩んでいたところ、パラメー
タの動的変化を思いついた。これは大きいファイルにも小さいファ
イルにも効くが、ファイルの最初の部分と最後の部分に一定の割合
で効いてくるものなので（真ん中の部分では効かない）、相対的に
小さいファイルで大きな成果をあげ、(2)〜(3)の損失は取り戻した
。
(6)tek1/tek2のデコードルーチンだけちょっと清書。edimgへ持ってい
く準備。
http://k.hideyosi.com/bim2bi4g.lzh (42.0KB)
圧縮比較表は次のように更新されました。ブロックサイズはすべて
2MBにしてあります。clvの指定はしていません。全てデフォルトです。
clvを指定すればもうちょっと小さくなると思います。
符号寿命をサポートしたので、bsizをいじるほうが高圧縮になる、と
いうケースはなくなりました。ブロックに分けないほうが圧縮率は高く
なります。KHBIOSなどでのランダムアクセス性能を担保したいときと、
ただひたすらに圧縮率がほしいときなどで、自由に使い分けてください
。
org tek0 tek1 tek2 bz2 rk
hellok1 272 128 127 125 166 208
zero4k 4096 27 26 25 43 100
zero64k 65536 28 28 27 43 108
bim2binc 53792 15091 14472 14062 12903 11608
kdun00b 655360 46246 44682 43841 47306 36736
osaskgo 1973741 1149662 1134957 1122852 1047411 909824
org tek0 tek1 tek2 bz2 rk
hellok1 217.6 102.4 101.6 100.0 132.8 166.4
zero4k 16384 108.0 103.7 100.0 172.0 400.0
zero64k 242726 103.7 107.4 100.0 159.3 400.0
bim2binc 463.4 130.0 124.7 121.1 111.2 100.0
kdun00b 1784.0 125.9 121.6 119.3 128.8 100.0
osaskgo 216.9 126.4 124.7 123.4 115.1 100.0
ええと、tek1ではhellok1、zero4k、zero64kの結果が1バイトずつ増
えています。これが(4)の影響です。
今回の見どころを分かりやすくするために、前回の結果を引用しまし
ょう。
Hidemi KAWAI は 2004/05/25 22:40:51 の「[osask 6963] bim2bin4f.
」で書きました：
> tek1 tek2 lh5 lh7 bz2 rk
> bim2binc 125.4 121.9 129.9 121.5 111.2 100.0
> kdun00b 124.3 121.0 127.8 123.7 128.8 100.0
> osaskgo 125.4 124.2 125.0 120.8 115.1 100.0
tek1の最悪値は125.4→124.7に改善しています。これはlh5のベスト
値よりもいいので、lh5よりもいいといえると思います。たぶん展開速
度の点からも、tek1のほうが優勢だと思います。
tek2については、最悪値が124.2→123.4に改善しています。tek2とラ
イバルたちを見やすく並べるとこうなります。
tek0 tek1 tek2 lh7 bz2 rk
bim2binc 130.0 124.7 121.1 121.5 111.2 100.0
kdun00b 125.9 121.6 119.3 123.7 128.8 100.0
osaskgo 126.4 124.7 123.4 120.8 115.1 100.0
とりあえずtek2 vs lh7なら、この範囲では2勝1敗ということになり
ます。しかしこの中で一番大きいのはosaskgoであって、それで大きく
負けた以上は、結局トータルでの敗北を意味するような気もします。
対bz2ではまだまだ勝負なっていません。しかし密かに思ったのです
が、tek2はbz2の苦手なところに強いようなので、ブロックソートと
tek2を併用するようなアルゴリズムを作れば、最強になれそうな気がし
ました（いやrkの存在を差し置いて最強などと軽々しく言ってはいけま
せんでした）。
毎度のOSASKアプリです。これらは小さいので適当にclvを指定してい
ます。指定値は前回と同じです。
tek0 tek1 tek2 tek0→tek2での改善率
helloc4 497 493 489 1.61%
helloc9 176 176 172 2.27%
bballc0 628 618 618 1.59%
bballc2 295 293 291 1.36%
invader2 1699 1674 1675 1.41%
invader5 1258 1240 1235 1.83%
全体としてみると、tek1ではbim2bin4fと比べてあちこち増減してい
ます。でも合計を取るとそんなに変わってない感じです。一方tek2のほ
うは、invader5を除いてほぼ増減なしです。しかしinvader5ではやって
くれました。ついに1235バイトです。1240バイトの壁を越えたのはうれ
しいです。
他に補足することはというと、・・・ああ、圧縮速度についてですが
、結局改善していません。さぼりです。
---
ええと今この時期になぜtek1/tek2の開発・改良に専念するのかの理
解が、十分でなさそうな意見がよそで見られたので、ついでに詳しく説
明しておきます。
僕はKHBIOSを作りたいのです。KHBIOSではデバイスのサポートもさる
ことながら、圧縮のサポートも欠かせません。KHBIOSが初期の頃から圧
縮をサポートしていれば、KHBIOS対応OSはなんのためらいもなく最初か
ら圧縮機能を前提にして記述されるでしょう。バージョン○○以降が必
要です、みたいなやつだと、クリティカルなもの以外はあまり関心をひ
かないと思います。HDDサポートやUSBサポートはクリティカルといえる
ので、あとからサポートしてもKHBIOSをバージョンアップしてもらえる
と思いますが、圧縮くらいならなくてもいいや、という風潮になる可能
性があります。それは、OSASKファンやUPXファン以外のユーザが圧縮の
重要性をあまり理解していないせいです。そしてそうなると、OS側もあ
てにできない圧縮機能の利用に対し消極的になります。
僕としては圧縮したディスクイメージをサポートするのは非常に重要
で、しかも部分的に非圧縮にもできるようなものであればベストなので
す。OSASKやMonaのKHBIOSパーティションイメージ（要するにディスク
イメージ）をダウンロードして、まあこれが仮に圧縮した状態で1MBだ
としますが、これを16MBのSDカードに書いたら15MBの空きできてそのま
ま使えたら便利ではありませんか、展開して2MBとか3MBになって、空き
を14MBとか13MBにされるよりも。OS部分はライトプロテクトがかかった
圧縮セクタで、非圧縮部分が普通のセクタになります。またKHBIOSはFD
やCFなどもパーティションを好きなだけ切れますので1FDに圧縮して3つ
のOSを入れるとか、小容量のCFに10個くらいいれるとか、活用の道はい
くらでもあります。
圧縮してサイズが半分になるというのは、つまり容量が2倍になるこ
とに等しいのです。またtek1なら展開速度がかなり速いので、もはや
HDDアクセスであってもトータルではアクセス時間が短縮できると思わ
れます（まあCPU負荷の面ではDMAとくらべれば損ですが）。あまり速く
ないメモリカード（Proでないメモリースティックとか128MB以下のSD
カードとか）ではアクセス速度も体感できるほど速くなるでしょう。
ということで、KHBIOSの初期から圧縮をサポートして一人でも多くの
人に圧縮展開がOSやBIOSレベルでサポートされる重要性を理解してもら
えるようになりたいわけです。そしてそう考えると、tek0はふさわしく
ないわけです、ブロックごとに区切って圧縮・非圧縮を選ぶことはでき
ませんし、部分展開もできませんから。
そんなわけでtek1を作る必要に迫られました。逆にいうとKHBIOSでは
tek0はサポートされません。サポートする意義がないからです。一方
OSASKではtek0は「ぐいぐい00」とセットなので、今後もサポートされ
ます。
そしてどうせtek1を作るのなら、現時点でのベストをすべて叩き込ん
でおきたいと考えるのはまあ普通の発想です。あとからバージョンアッ
プすると、KHBIOSは旧版のサポートにも追われて肥大化の恐れがありま
すので、めったなことでは新しい圧縮形式を追加できません（KHBIOSは
エミュレータOSではないので自分自身の過去との互換性をばっさりと切
り捨てるわけにはいかないでしょう）。そうであれば、時間をかけてで
も真剣に設計したくなるのはなおさらです。
tek2は、tek1に80行ほど書き足しただけで展開できるようになるので
それでこれくらい圧縮率が変わるなら、サポートに付け加えておくべき
だと思いました。それで同時に開発しているわけです。
・・・ということでtek1/tek2はおもにKHBIOSのために作っているの
であってOSASKのために作っているわけではないのです。だからOSASKに
どういう利益があるかだけでtek1/tek2を捉えると、どうしてtek1/tek2
の改良に時間をかけるのか理解しにくいでしょう。・・・いやもちろん
OSASKのためではないとはいえ、OSASKでの利用も想定しています。せっ
かくいいものがあるのに使わない理由はないので。というかtek1/tek2
に関してはかなり汎用的な用途を想定していて、広い分野で活用できた
らいいと思っています（展開ルーチンがDLL化するにはもったいないほ
ど単純で短くて、しかも展開が速いから）。これはobj2bimでtek0にお
いて既に実現していますが、たとえばライブラリファイルを圧縮したま
までもリンクできるとかそういうことです（もし僕がwin32のグラフィ
ックツールを作る立場だったら、tek1/tek2に関しては圧縮したままで
も見られるように作るでしょう。編集して保存すると非圧縮形式になっ
てしまいますが）。そんな感じです。
それでは。
--
川合 秀実(KAWAI Hidemi)
OSASK計画代表 / システム設計開発担当
E-mail:kawai !Atmark! osask.jp
Homepage http://osask.jp/