tek1​/tek5_eopt :: OSASK計画

tek5/stk5における、eoptの簡単な見極め方 ^[1]

• (by K^[2], 2004.07.23)

• 初めに注意
  • OSASKアプリのMakefileを眺めたことがある人は分かると思いますが、OSASKアプリを生成する場合にbim2binは2度使われます。これを区別してeoptを使い分けるのがコツです。
    • 1回目は、bim→orgのとき
    • 2回目は、org→binのとき

• ええと、以下のことは1バイトでも小さくしたい、というとき以外は気にすることはありません。デフォルトではベストではないにしても、たいていのものにそれなりにマッチするようになっていて、十分に小さくなります。
• もっと小さくしたいなんていうときに、じゃあtek0を試してみようとか、プログラムをちょっと書き換えてやろうとか、そういう風に考えることがあるかと思いますが、そんなときあれこれ試す前に、以下のeoptやrjcを使えば簡単に（ちょっとは）改善できますよ、ということです。ここまでやらなきゃ恥だとか、試すことが推奨されるとか、そんなわけじゃありません。
  • 時間をかけて自動でそこまでやることもあるまい、ということで手動オプションになっているくらいなのですから。

OSASKアプリ編 ^[3]

• bim→org
  • eoptをつけなくてもたいていベストの結果になります。だからいじる必要なしです。
  • tek0時代のアプリを再makeする場合は、bim2binのデフォルトがtek5になっているので、-tek0をつけて強制的にtek0にするか、もしくはobj2bimでのスタックが36k以上になっていることを確認してください（tek5を利用する場合にかきり、最小スタックは4kではなく36kです）。
  • さらに40例以上のOSASKアプリで研究したところ、デフォルトよりも、eopt:-pb0_-lc0のほうがいい場合が結構あることが判明。ちなみに-pb0_-lc0限定なら、スタックは16kで足ります（もちろん36kにしてもいいです）。

• org→binのとき
  • 超小さいアプリ：　　（eoptなしで圧縮したときに500バイト以下）

    rjc:0 eopt:-pb0_-lc0

    • 実は3KBくらいでも、-pb0_-lc0のほうがいい場合も結構あるようでした。
  • 小さいアプリ：　　（eoptなしで圧縮したときに10KB以下）

    eopt:-pb0_-lc2

  • 大きいアプリ：　　（eoptなしで圧縮したときに100KB以下）

    eopt:-pb0_-lc4

  • 超大きいアプリ：　　（eoptなしで圧縮したときに100KB以上）

    eopt:-pb0_-lc8

データ編 ^[4]

• sarやSF16アーカイブの場合は、その中身を構成するファイルのうちで、一番影響がありそうなものを想定して、それにあわせてパラメータを選ぶといいでしょう。
  • 普通のテキストファイルや、16色もしくは256色BMP、もしくは実行コード。つまり基本的に1バイト単位か、もしくはファイル構造に明確な周期が存在しないもの（以下のどれにも該当しない周期の場合もこれにするのが良さそう）。

    eopt:-pb0

  • テキストファイルだが、全部全角でしかも改行コードがCRLF（WindowsやMS-DOSでの標準改行コード）で、TABなどを一切使っていないもの。もしくは16ビットカラーのBMP。つまり基本的に2バイト単位でデータが構成されているもの。

    eopt:-pb1

  • バイナリデータなどで、データ構造が4バイト単位になっているもの。

    eopt:-pb2

  • バイナリデータなどで、データ構造が8バイト単位になっているもの。

    eopt:-pb3

  • バイナリデータなどで、データ構造が16バイト単位になっているもの（例：JPN16V00.FNTとか）。

    eopt:-pb4

こめんと欄 ^[5]

• 100KBで超おおきいって・・・・ちゃんとMB、GB級のアプリにも対応できる仕様なのかな -- 名無しさん^[6] 2004-07-23 (金) 08:44:21
• もちろん！10MBとかなら eopt:-pb0_-lc8 にすればいいだけですよ（つまり100KB以上と同じ）。・・・理論的にもっともアプリに適したオプションは eopt:-pb0_-lc8 なのですが、圧縮対象が統計的な処理が有効になるほどの大きさに満たない場合は、そのスケールにあわせているだけです。 -- K^[2] 2004-07-23 (金) 11:21:39